From ivan.gerasimov at oracle.com Mon Jun 2 00:57:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 02 Jun 2014 04:57:21 +0400 Subject: RFR [8037866] Replace the Fun class in tests with lambdas Message-ID: <538BCBF1.90800@oracle.com> Hello! Would you please help review the fix, which replaces the auxiliary Fun class with the same named functional interface? The anonymous classes instantiations are replaced with lambdas. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8037866 WEBREV: http://cr.openjdk.java.net/~igerasim/8037866/0/webrev/ Sincerely yours, Ivan From me at sandipan.net Mon Jun 2 02:55:42 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Sun, 1 Jun 2014 22:55:42 -0400 Subject: RFR for 8043740 (Doubles with large exponents overflow to Infinity incorrectly) Message-ID: Hi Brian/all, Fix for the above-mentioned bug is complete. If you (or anyone else as appropriate) could please review the changes and let me know of your comments that would be great! Link for the webrev: http://www.sandipan.net/public/webrevs/8043740/webrev.00/ The patch is inlined below my signature. Cheers, SR --- old/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 22:33:34.947651253 -0400 +++ new/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 22:33:34.827651251 -0400 @@ -1992,7 +1992,10 @@ break expLoop; // stop parsing exponent. } } - int expLimit = BIG_DECIMAL_EXPONENT+nDigits+nTrailZero; + + int expLimit = BIG_DECIMAL_EXPONENT + nDigits + nTrailZero + - (nLeadZero - decPt); + if ( expOverflow || ( expVal > expLimit ) ){ // // The intent here is to end up with --- /dev/null 2014-05-28 21:22:08.061671015 -0400 +++ new/test/java/lang/Double/Bug8043740.java 2014-06-01 22:33:35.227651260 -0400 @@ -0,0 +1,40 @@ +/* + * 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * 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. + */ + +/* + * @test + * @bug 8043740 + * @summary Test for Double.parseDouble incorrect normalization of exponent. + */ +public class Bug8043740 { + + public static void main(String[] args) { + String text326 = "00.000000000000000001e326"; // expect 1e308 + double value326 = Double.parseDouble(text326); + if (Double.isInfinite(value326)) { + throw new RuntimeException("String [" + text326 + + "] was incorrectly parsed to Infinity."); + } + } + +} From david.holmes at oracle.com Mon Jun 2 03:07:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Jun 2014 13:07:23 +1000 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> Message-ID: <538BEA6B.10900@oracle.com> Hi Andrej, Sorry for the delay getting back to you. On 29/05/2014 10:24 PM, Andrej Golovnin wrote: > Hi David, > >>> >>> The valueOf calls may also allocate a new object so you can't just >>> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you >>> can't tell whether a new object was allocated or not. It is only for the >>> smaller primitive types that any kind of Object caching is mandated. >> >> It is only for the smaller values (-128 to +127) of the integer primitives types (plus boolean) that caching is mandated. Float.valueOf and Double.valueOf always create objects. >> > > You are right, that #valueOf call may allocate an object. > But as far as I understand currently the JvmtiExport::post_vm_object_alloc call > is only needed, because today the native code itself allocates an object > by calling java_lang_boxing_object::create(type, value, CHECK_NULL);. Right, sorry - I was misunderstanding the purpose of the post_vm_object_alloc call: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#VMObjectAlloc So from the perspective that you are diverting this back to Java code the hotspot changes look okay to me. The more general question, for the core-libs folk, is whether changing everything to use valueOf is overkill (given the limits of the required caching mechanisms) or good to do from a consistency perspective. I'm slightly on the overkill side of things but not enough to reject things. On the performance/benefit side, if I read things correctly you only see the 9GB of Boolean objects because you disable reflection-inflation - is that right? In that case, as Joel states, the gains are not really general, but on the other hand I don't see anything wrong with trying to improve the general efficiency here even if the greatest benefit comes from a "non-mainstream" usecase. David ----- > My code changes this behavior and delegates object allocation back to Java > by calling > > JavaCalls::call_static(&boxed_value, > klass_handle, > vmSymbols::valueOf_name(), > valueOf_signature, > &args, > THREAD); > > But maybe I misunderstood the implementation of JavaCalls. > > Best regards, > Andrej Golovnin > From martinrb at google.com Mon Jun 2 04:36:52 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 1 Jun 2014 21:36:52 -0700 Subject: RFR [8037866] Replace the Fun class in tests with lambdas In-Reply-To: <538BCBF1.90800@oracle.com> References: <538BCBF1.90800@oracle.com> Message-ID: Thanks! Looks good. There might be more common infrastructure to take advantage of later. @FunctionalInterface is not really in the spirit of my super-compact stylistically odd test code, but OK. On Sun, Jun 1, 2014 at 5:57 PM, Ivan Gerasimov wrote: > Hello! > > Would you please help review the fix, which replaces the auxiliary Fun > class with the same named functional interface? > The anonymous classes instantiations are replaced with lambdas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8037866 > WEBREV: http://cr.openjdk.java.net/~igerasim/8037866/0/webrev/ > > Sincerely yours, > Ivan > From tobias.hartmann at oracle.com Mon Jun 2 06:04:02 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 02 Jun 2014 08:04:02 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <5385BF06.5090808@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com> Message-ID: <538C13D2.5000400@oracle.com> On 28.05.2014 12:48, Vladimir Ivanov wrote: > Looks good. > > It should be safe to sync on MTF instance since it's not accessible > outside (MTF and MT.form() are package-private). > > Best regards, > Vladimir Ivanov Thank you, Vladimir. Could someone please push the patch? Thanks, Tobias > > On 5/28/14 1:49 PM, Tobias Hartmann wrote: >> Hi, >> >> thanks everyone for the feedback! >> >> @Remi: I agree with Paul. This is not a problem because if the normal >> read sees an outdated null value, a new LambdaForm is created and >> setCachedLambdaForm(...) is executed. This will guarantee that the >> non-null value is seen and used. The unnecessary creation of a new >> LamdaForm is not a problem either. >> >> @John: I added the code that you suggested to simulate CAS. Please find >> the new webrev at: >> >> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ >> >> Sorry for the delay, I was on vacation. >> >> Thanks, >> Tobias >> >> On 19.05.2014 20:31, John Rose wrote: >>> On May 16, 2014, at 4:56 AM, Tobias Hartmann >>> wrote: >>> >>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>> Yes, that is how I see it. The fast path is a racy non-volatile read >>> of a safely-published structure. >>> >>> (If safe publication via arrays were broken, java.lang.String would be >>> broken. But the JMM is carefully designed to support safe publication >>> of array elements, and through array elements.) >>> >>> ? John >> From ivan.gerasimov at oracle.com Mon Jun 2 07:27:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 02 Jun 2014 11:27:21 +0400 Subject: RFR [8037866] Replace the Fun class in tests with lambdas In-Reply-To: References: <538BCBF1.90800@oracle.com> Message-ID: <538C2759.7090603@oracle.com> Thank you Martin for review! On 02.06.2014 8:36, Martin Buchholz wrote: > Thanks! Looks good. > There might be more common infrastructure to take advantage of later. > @FunctionalInterface is not really in the spirit of my super-compact > stylistically odd test code, but OK. > I'll remove the annotation to keep the spirit :) Sincerely yours, Ivan > > > On Sun, Jun 1, 2014 at 5:57 PM, Ivan Gerasimov > > wrote: > > Hello! > > Would you please help review the fix, which replaces the auxiliary > Fun class with the same named functional interface? > The anonymous classes instantiations are replaced with lambdas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8037866 > WEBREV: http://cr.openjdk.java.net/~igerasim/8037866/0/webrev/ > > > Sincerely yours, > Ivan > > From andrej.golovnin at gmail.com Mon Jun 2 09:19:52 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 2 Jun 2014 11:19:52 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <538BEA6B.10900@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> <538BEA6B.10900@oracle.com> Message-ID: Hi David, > Right, sorry - I was misunderstanding the purpose of the > post_vm_object_alloc call: > > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti. > html#VMObjectAlloc > > So from the perspective that you are diverting this back to Java code the > hotspot changes look okay to me. > I'm glad to hear that. > > The more general question, for the core-libs folk, is whether changing > everything to use valueOf is overkill (given the limits of the required > caching mechanisms) or good to do from a consistency perspective. I'm > slightly on the overkill side of things but not enough to reject things. > In case my vote counts, I'm for consistency. :-) > > On the performance/benefit side, if I read things correctly you only see > the 9GB of Boolean objects because you disable reflection-inflation - is > that right? No. The most of those objects are allocated by calls to java.lang.reflect.Field.get(). I disable reflection-inflation only on the server side just to save a little bit more memory. On the client side I'm still using reflection-inflation, because here is the startup time more important. > In that case, as Joel states, the gains are not really general, but on the > other hand I don't see anything wrong with trying to improve the general > efficiency here even if the greatest benefit comes from a "non-mainstream" > usecase. > I would not call what we do a "non-mainstream" use case. We have a classic JEE application which make use of nearly all JEE APIs. All of those Boolean objects are allocated by a very famous JPA implementation, which use Reflection API to set/get properties of our domain objects. We have the same problem with Integer objects too. I brought the example with Boolean objects just because at least in the theory we should have per JVM only two instances of Boolean class. But in the reality we have to many of them. Best regards, Andrej Golovnin From forax at univ-mlv.fr Mon Jun 2 10:46:00 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 02 Jun 2014 12:46:00 +0200 Subject: RFR [8037866] Replace the Fun class in tests with lambdas In-Reply-To: References: <538BCBF1.90800@oracle.com> Message-ID: <538C55E8.80405@univ-mlv.fr> On 06/02/2014 06:36 AM, Martin Buchholz wrote: > Thanks! Looks good. > There might be more common infrastructure to take advantage of later. > @FunctionalInterface is not really in the spirit of my super-compact > stylistically odd test code, but OK. Another question is why not to use a functional interface with one parameter (Fun2?) or keep Fun and introduce Fun2. //interface Fun {void f() throws Throwable;} interface Fun2 {void f(T value) throws Throwable;} THROWS(BrokenBarrierException.class, barrier, x ->x.await(100, MILISECOND)); THROWS(IllegalStateException.class, it, Iterator::remove); with the nice advantage that most of the time the lambda will be constant (a lambda that's not capture value from the outer context). R?mi > > > > > On Sun, Jun 1, 2014 at 5:57 PM, Ivan Gerasimov > wrote: > >> Hello! >> >> Would you please help review the fix, which replaces the auxiliary Fun >> class with the same named functional interface? >> The anonymous classes instantiations are replaced with lambdas. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8037866 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8037866/0/webrev/ >> >> Sincerely yours, >> Ivan >> From ivan.gerasimov at oracle.com Mon Jun 2 11:58:07 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 02 Jun 2014 15:58:07 +0400 Subject: RFR [8037866] Replace the Fun class in tests with lambdas In-Reply-To: <538C55E8.80405@univ-mlv.fr> References: <538BCBF1.90800@oracle.com> <538C55E8.80405@univ-mlv.fr> Message-ID: <538C66CF.6070806@oracle.com> Hi Remi! On 02.06.2014 14:46, Remi Forax wrote: > > On 06/02/2014 06:36 AM, Martin Buchholz wrote: >> Thanks! Looks good. >> There might be more common infrastructure to take advantage of later. >> @FunctionalInterface is not really in the spirit of my super-compact >> stylistically odd test code, but OK. > > Another question is why not to use a functional interface with one > parameter (Fun2?) > or keep Fun and introduce Fun2. > //interface Fun {void f() throws Throwable;} > interface Fun2 {void f(T value) throws Throwable;} > THROWS(BrokenBarrierException.class, barrier, x ->x.await(100, > MILISECOND)); > THROWS(IllegalStateException.class, it, Iterator::remove); > THROWS accepts an array of Funs. Personally, I find more handy and less error-prone than providing pairs argument + lambda: If we have only one pair, we'll need to repeat THROWS several times, If we accept even-sized array, it can be messed up. > with the nice advantage that most of the time the lambda will be constant > (a lambda that's not capture value from the outer context). > In case it's needed, some helper class that transforms Fun2 into Fun could be used: class Fun2Impl implements Fun { final T val; Fun2 fun2; public Fun2Impl(T val, Fun2 fun2) { this.val = val; this.fun2 = fun2; } public void f() { fun2.f(val); } } ... THROWS(BrokenBarrierException.class, new Fun2Impl(barrier, x ->x.await(100, MILISECOND))); THROWS(IllegalStateException.class, new Fun2Impl(it, Iterator::remove)); It can be slightly beautified, of course. However, I don't think there would be much use of it, as it can already be achieved through Fun, making 'x' and 'it' final. Sincerely yours, Ivan > R?mi > >> >> >> >> >> On Sun, Jun 1, 2014 at 5:57 PM, Ivan Gerasimov >> >> wrote: >> >>> Hello! >>> >>> Would you please help review the fix, which replaces the auxiliary Fun >>> class with the same named functional interface? >>> The anonymous classes instantiations are replaced with lambdas. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8037866 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8037866/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> > > > From vladimir.x.ivanov at oracle.com Mon Jun 2 13:29:07 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 02 Jun 2014 17:29:07 +0400 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <538C13D2.5000400@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com> <538C13D2.5000400@oracle.com> Message-ID: <538C7C23.90901@oracle.com> Tobias, I'll take care of it. Best regards, Vladimir Ivanov On 6/2/14 10:04 AM, Tobias Hartmann wrote: > > On 28.05.2014 12:48, Vladimir Ivanov wrote: >> Looks good. >> >> It should be safe to sync on MTF instance since it's not accessible >> outside (MTF and MT.form() are package-private). >> >> Best regards, >> Vladimir Ivanov > > Thank you, Vladimir. > > Could someone please push the patch? > > Thanks, > Tobias > >> >> On 5/28/14 1:49 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> thanks everyone for the feedback! >>> >>> @Remi: I agree with Paul. This is not a problem because if the normal >>> read sees an outdated null value, a new LambdaForm is created and >>> setCachedLambdaForm(...) is executed. This will guarantee that the >>> non-null value is seen and used. The unnecessary creation of a new >>> LamdaForm is not a problem either. >>> >>> @John: I added the code that you suggested to simulate CAS. Please find >>> the new webrev at: >>> >>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ >>> >>> Sorry for the delay, I was on vacation. >>> >>> Thanks, >>> Tobias >>> >>> On 19.05.2014 20:31, John Rose wrote: >>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann >>>> wrote: >>>> >>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>>> Yes, that is how I see it. The fast path is a racy non-volatile read >>>> of a safely-published structure. >>>> >>>> (If safe publication via arrays were broken, java.lang.String would be >>>> broken. But the JMM is carefully designed to support safe publication >>>> of array elements, and through array elements.) >>>> >>>> ? John >>> > From Alan.Bateman at oracle.com Mon Jun 2 13:33:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Jun 2014 14:33:43 +0100 Subject: RFR: JDK-8044343 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions In-Reply-To: <538A0448.70905@oracle.com> References: <538A0448.70905@oracle.com> Message-ID: <538C7D37.1040307@oracle.com> On 31/05/2014 17:33, Mark Sheppard wrote: > Hi, > please oblige and review the following change > http://cr.openjdk.java.net/~msheppar/8044343/webrev/ > > which addresses issue > https://bugs.openjdk.java.net/browse/JDK-8044343 > > which is a backport of > https://bugs.openjdk.java.net/browse/JDK-8036603 > > the original changeset didn't apply cleanly and was applied manually > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/323b64a9dede This looks okay to me and should have the 8u version the same as 9 (except for the additional blank lines in the 9 version). -Alan From Alan.Bateman at oracle.com Mon Jun 2 13:37:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Jun 2014 14:37:09 +0100 Subject: RFR: 8041602 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <538A517F.6090808@oracle.com> References: <538A517F.6090808@oracle.com> Message-ID: <538C7E05.6010606@oracle.com> On 31/05/2014 23:02, Mark Sheppard wrote: > Hi, > please oblige and review the following change > http://cr.openjdk.java.net/~msheppar/8041602/webrev/ > > which addresses the issue > https://bugs.openjdk.java.net/browse/JDK-8041602 > > which is a backport of > https://bugs.openjdk.java.net/browse/JDK-8035340 > > the original changeset didn't apply cleanly and was applied manually > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/740ffd98e35a > This looks okay to me, I'm curious as whether it was just the new location in the jdk9/jdk tree that caused the issue or another change. A minor comment on L48 where it could be "if (result .." to be consistent. -Alan From me at sandipan.net Mon Jun 2 14:08:06 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Mon, 2 Jun 2014 10:08:06 -0400 Subject: RFR for 8043740 (Doubles with large exponents overflow to Infinity incorrectly) In-Reply-To: References: Message-ID: Hi all - I've made a quick revision to that last patch. Please find inline the latest link + patch. http://www.sandipan.net/public/webrevs/8043740/webrev.01/ Cheers, SR --- old/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-02 09:32:20.000000000 -0400 +++ new/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-02 09:32:19.000000000 -0400 @@ -1994,19 +1994,29 @@ } int expLimit = BIG_DECIMAL_EXPONENT+nDigits+nTrailZero; if ( expOverflow || ( expVal > expLimit ) ){ - // - // The intent here is to end up with - // infinity or zero, as appropriate. - // The reason for yielding such a small decExponent, - // rather than something intuitive such as - // expSign*Integer.MAX_VALUE, is that this value - // is subject to further manipulation in - // doubleValue() and floatValue(), and I don't want - // it to be able to cause overflow there! - // (The only way we can get into trouble here is for - // really outrageous nDigits+nTrailZero, such as 2 billion. ) - // - decExp = expSign*expLimit; + // There is still a chance that the exponent will be + // safe to use: if it would eventually decrease + // due to a negative decExp, and that number is below the limit. + // We check for that here. + if ( ( expSign == 1 && decExp < 0 ) + && ( expVal + decExp ) < expLimit ) { + // Cannot overflow - adding a positive and negative number. + decExp = expVal + decExp; + } else { + // + // The intent here is to end up with + // infinity or zero, as appropriate. + // The reason for yielding such a small decExponent, + // rather than something intuitive such as + // expSign*Integer.MAX_VALUE, is that this value + // is subject to further manipulation in + // doubleValue() and floatValue(), and I don't want + // it to be able to cause overflow there! + // (The only way we can get into trouble here is for + // really outrageous nDigits+nTrailZero, such as 2 billion. ) + // + decExp = expSign*expLimit; + } } else { // this should not overflow, since we tested // for expVal > (MAX+N), where N >= abs(decExp) --- /dev/null 2014-06-02 09:32:21.000000000 -0400 +++ new/test/java/lang/Double/Bug8043740.java 2014-06-02 09:32:20.000000000 -0400 @@ -0,0 +1,41 @@ +/* + * 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * 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. + */ + +/* + * @test + * @bug 8043740 + * @summary Test for Double.parseDouble incorrect normalization of exponent. + */ +public class Bug8043740 { + + public static void main(String[] args) { + String text = "00.000000000000000001e326"; + double expected = Double.parseDouble("1e308"); + double value = Double.parseDouble(text); + if (Double.compare(expected, value) != 0) { + throw new RuntimeException("String [" + text + + "] was incorrectly parsed to [" + value + "]"); + } + } + +} Sandipan Razzaque | www.sandipan.net On Sun, Jun 1, 2014 at 10:55 PM, Sandipan Razzaque wrote: > Hi Brian/all, > > Fix for the above-mentioned bug is complete. If you (or anyone else as > appropriate) could please review the changes and let me know of your > comments that would be great! > > Link for the webrev: > > http://www.sandipan.net/public/webrevs/8043740/webrev.00/ > > The patch is inlined below my signature. > > Cheers, > SR > > > --- old/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 > 22:33:34.947651253 -0400 > +++ new/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 > 22:33:34.827651251 -0400 > @@ -1992,7 +1992,10 @@ > break expLoop; // stop parsing exponent. > } > } > - int expLimit = BIG_DECIMAL_EXPONENT+nDigits+nTrailZero; > + > + int expLimit = BIG_DECIMAL_EXPONENT + nDigits + nTrailZero > + - (nLeadZero - decPt); > + > if ( expOverflow || ( expVal > expLimit ) ){ > // > // The intent here is to end up with > --- /dev/null 2014-05-28 21:22:08.061671015 -0400 > +++ new/test/java/lang/Double/Bug8043740.java 2014-06-01 22:33:35.227651260 > -0400 > @@ -0,0 +1,40 @@ > +/* > + * 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 > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * 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. > + */ > + > +/* > + * @test > + * @bug 8043740 > + * @summary Test for Double.parseDouble incorrect normalization of > exponent. > + */ > +public class Bug8043740 { > + > + public static void main(String[] args) { > + String text326 = "00.000000000000000001e326"; // expect 1e308 > + double value326 = Double.parseDouble(text326); > + if (Double.isInfinite(value326)) { > + throw new RuntimeException("String [" + text326 + > + "] was incorrectly parsed to Infinity."); > + } > + } > + > +} > > From roger.riggs at oracle.com Mon Jun 2 14:15:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 02 Jun 2014 10:15:29 -0400 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <538BEA6B.10900@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> <538BEA6B.10900@oracle.com> Message-ID: <538C8701.3030501@oracle.com> Hi David, et.al. I would let the compiler do auto-boxing where necessary. (Assuming object identity is not necessary). If type disambiguation is necessary then use a cast to the target type and let the compiler do the rest. It keeps the source code simple and readable. But I don't think it is worth a proactive pervasive change. The gain is overshadowed by the overhead of the reviews. $.02, Roger On 6/1/2014 11:07 PM, David Holmes wrote: > Hi Andrej, > > Sorry for the delay getting back to you. > > On 29/05/2014 10:24 PM, Andrej Golovnin wrote: >> Hi David, >> >>>> >>>> The valueOf calls may also allocate a new object so you can't just >>>> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you >>>> can't tell whether a new object was allocated or not. It is only >>>> for the >>>> smaller primitive types that any kind of Object caching is mandated. >>> >>> It is only for the smaller values (-128 to +127) of the integer >>> primitives types (plus boolean) that caching is mandated. >>> Float.valueOf and Double.valueOf always create objects. >>> >> >> You are right, that #valueOf call may allocate an object. >> But as far as I understand currently the >> JvmtiExport::post_vm_object_alloc call >> is only needed, because today the native code itself allocates an object >> by calling java_lang_boxing_object::create(type, value, CHECK_NULL);. > > Right, sorry - I was misunderstanding the purpose of the > post_vm_object_alloc call: > > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#VMObjectAlloc > > > So from the perspective that you are diverting this back to Java code > the hotspot changes look okay to me. > > The more general question, for the core-libs folk, is whether changing > everything to use valueOf is overkill (given the limits of the > required caching mechanisms) or good to do from a consistency > perspective. I'm slightly on the overkill side of things but not > enough to reject things. > > On the performance/benefit side, if I read things correctly you only > see the 9GB of Boolean objects because you disable > reflection-inflation - is that right? In that case, as Joel states, > the gains are not really general, but on the other hand I don't see > anything wrong with trying to improve the general efficiency here even > if the greatest benefit comes from a "non-mainstream" usecase. > > David > ----- > >> My code changes this behavior and delegates object allocation back to >> Java >> by calling >> >> JavaCalls::call_static(&boxed_value, >> klass_handle, >> vmSymbols::valueOf_name(), >> valueOf_signature, >> &args, >> THREAD); >> >> But maybe I misunderstood the implementation of JavaCalls. >> >> Best regards, >> Andrej Golovnin >> From mark.sheppard at oracle.com Mon Jun 2 15:15:45 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 02 Jun 2014 16:15:45 +0100 Subject: RFR: 8041602 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions In-Reply-To: <538C7E05.6010606@oracle.com> References: <538A517F.6090808@oracle.com> <538C7E05.6010606@oracle.com> Message-ID: <538C9521.7090307@oracle.com> Hi Alan, yes the differences in location was an issue and the jdk8 CoreLibraries.gmk had a clash regards Mark On 02/06/2014 14:37, Alan Bateman wrote: > On 31/05/2014 23:02, Mark Sheppard wrote: >> Hi, >> please oblige and review the following change >> http://cr.openjdk.java.net/~msheppar/8041602/webrev/ >> >> which addresses the issue >> https://bugs.openjdk.java.net/browse/JDK-8041602 >> >> which is a backport of >> https://bugs.openjdk.java.net/browse/JDK-8035340 >> >> the original changeset didn't apply cleanly and was applied manually >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/740ffd98e35a >> > This looks okay to me, I'm curious as whether it was just the new > location in the jdk9/jdk tree that caused the issue or another change. > A minor comment on L48 where it could be "if (result .." to be > consistent. > > -Alan > > > From christian.thalinger at oracle.com Mon Jun 2 17:23:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 Jun 2014 10:23:28 -0700 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <538C7C23.90901@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com> <538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com> Message-ID: <361D0F73-1993-494F-A000-62D729963D06@oracle.com> On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov wrote: > Tobias, I'll take care of it. Are you also taking care of the backports? > > Best regards, > Vladimir Ivanov > > On 6/2/14 10:04 AM, Tobias Hartmann wrote: >> >> On 28.05.2014 12:48, Vladimir Ivanov wrote: >>> Looks good. >>> >>> It should be safe to sync on MTF instance since it's not accessible >>> outside (MTF and MT.form() are package-private). >>> >>> Best regards, >>> Vladimir Ivanov >> >> Thank you, Vladimir. >> >> Could someone please push the patch? >> >> Thanks, >> Tobias >> >>> >>> On 5/28/14 1:49 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> thanks everyone for the feedback! >>>> >>>> @Remi: I agree with Paul. This is not a problem because if the normal >>>> read sees an outdated null value, a new LambdaForm is created and >>>> setCachedLambdaForm(...) is executed. This will guarantee that the >>>> non-null value is seen and used. The unnecessary creation of a new >>>> LamdaForm is not a problem either. >>>> >>>> @John: I added the code that you suggested to simulate CAS. Please find >>>> the new webrev at: >>>> >>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ >>>> >>>> Sorry for the delay, I was on vacation. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 19.05.2014 20:31, John Rose wrote: >>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann >>>>> wrote: >>>>> >>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>>>> Yes, that is how I see it. The fast path is a racy non-volatile read >>>>> of a safely-published structure. >>>>> >>>>> (If safe publication via arrays were broken, java.lang.String would be >>>>> broken. But the JMM is carefully designed to support safe publication >>>>> of array elements, and through array elements.) >>>>> >>>>> ? John >>>> >> From alexander.zuev at oracle.com Mon Jun 2 17:24:06 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 02 Jun 2014 21:24:06 +0400 Subject: RFR: JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method Message-ID: <538CB336.2090303@oracle.com> Hello, please, review my fix for the issue JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method Link to the issue: https://bugs.openjdk.java.net/browse/JDK-8044206 Webrev: http://cr.openjdk.java.net/~kizune/8044206/webrev.00 The fix is trivial, the JavaDoc for the LambdaMetafactory.altMetafactory() stated that it's more advanced version of the more streamlined method and linked itself instead of the method LambdaMetafactory.metafactory() /Alex From brian.goetz at oracle.com Mon Jun 2 17:25:43 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 2 Jun 2014 13:25:43 -0400 Subject: RFR: JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method In-Reply-To: <538CB336.2090303@oracle.com> References: <538CB336.2090303@oracle.com> Message-ID: +1 On Jun 2, 2014, at 1:24 PM, Alexander Zuev wrote: > Hello, > > please, review my fix for the issue > JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method > > Link to the issue: https://bugs.openjdk.java.net/browse/JDK-8044206 > Webrev: http://cr.openjdk.java.net/~kizune/8044206/webrev.00 > > The fix is trivial, the JavaDoc for the LambdaMetafactory.altMetafactory() stated that it's more advanced version > of the more streamlined method and linked itself instead of the method LambdaMetafactory.metafactory() > > /Alex From vladimir.x.ivanov at oracle.com Mon Jun 2 17:38:21 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 02 Jun 2014 21:38:21 +0400 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <361D0F73-1993-494F-A000-62D729963D06@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com> <538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com> <361D0F73-1993-494F-A000-62D729963D06@oracle.com> Message-ID: <538CB68D.6050701@oracle.com> On 6/2/14 9:23 PM, Christian Thalinger wrote: > > On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov wrote: > >> Tobias, I'll take care of it. > > Are you also taking care of the backports? Yes. I'll backport into 8u myself and for 7 I'll ask help from Sustaining. Best regards, Vladimir Ivanov > >> >> Best regards, >> Vladimir Ivanov >> >> On 6/2/14 10:04 AM, Tobias Hartmann wrote: >>> >>> On 28.05.2014 12:48, Vladimir Ivanov wrote: >>>> Looks good. >>>> >>>> It should be safe to sync on MTF instance since it's not accessible >>>> outside (MTF and MT.form() are package-private). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >>> Thank you, Vladimir. >>> >>> Could someone please push the patch? >>> >>> Thanks, >>> Tobias >>> >>>> >>>> On 5/28/14 1:49 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> thanks everyone for the feedback! >>>>> >>>>> @Remi: I agree with Paul. This is not a problem because if the normal >>>>> read sees an outdated null value, a new LambdaForm is created and >>>>> setCachedLambdaForm(...) is executed. This will guarantee that the >>>>> non-null value is seen and used. The unnecessary creation of a new >>>>> LamdaForm is not a problem either. >>>>> >>>>> @John: I added the code that you suggested to simulate CAS. Please find >>>>> the new webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ >>>>> >>>>> Sorry for the delay, I was on vacation. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 19.05.2014 20:31, John Rose wrote: >>>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann >>>>>> wrote: >>>>>> >>>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>>>>> Yes, that is how I see it. The fast path is a racy non-volatile read >>>>>> of a safely-published structure. >>>>>> >>>>>> (If safe publication via arrays were broken, java.lang.String would be >>>>>> broken. But the JMM is carefully designed to support safe publication >>>>>> of array elements, and through array elements.) >>>>>> >>>>>> ? John >>>>> >>> > From david.holmes at oracle.com Tue Jun 3 02:19:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Jun 2014 12:19:37 +1000 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <538C8701.3030501@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> <538BEA6B.10900@oracle.com> <538C8701.3030501@oracle.com> Message-ID: <538D30B9.4030002@oracle.com> Hi Roger, On 3/06/2014 12:15 AM, roger riggs wrote: > Hi David, et.al. > > I would let the compiler do auto-boxing where necessary. (Assuming > object identity is not necessary). I don't see where the compiler comes into this one. ??? David ----- > If type disambiguation is necessary then use a cast to the target type and > let the compiler do the rest. It keeps the source code simple and readable. > > But I don't think it is worth a proactive pervasive change. > The gain is overshadowed by the overhead of the reviews. > > $.02, Roger > > > > On 6/1/2014 11:07 PM, David Holmes wrote: >> Hi Andrej, >> >> Sorry for the delay getting back to you. >> >> On 29/05/2014 10:24 PM, Andrej Golovnin wrote: >>> Hi David, >>> >>>>> >>>>> The valueOf calls may also allocate a new object so you can't just >>>>> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you >>>>> can't tell whether a new object was allocated or not. It is only >>>>> for the >>>>> smaller primitive types that any kind of Object caching is mandated. >>>> >>>> It is only for the smaller values (-128 to +127) of the integer >>>> primitives types (plus boolean) that caching is mandated. >>>> Float.valueOf and Double.valueOf always create objects. >>>> >>> >>> You are right, that #valueOf call may allocate an object. >>> But as far as I understand currently the >>> JvmtiExport::post_vm_object_alloc call >>> is only needed, because today the native code itself allocates an object >>> by calling java_lang_boxing_object::create(type, value, CHECK_NULL);. >> >> Right, sorry - I was misunderstanding the purpose of the >> post_vm_object_alloc call: >> >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#VMObjectAlloc >> >> >> So from the perspective that you are diverting this back to Java code >> the hotspot changes look okay to me. >> >> The more general question, for the core-libs folk, is whether changing >> everything to use valueOf is overkill (given the limits of the >> required caching mechanisms) or good to do from a consistency >> perspective. I'm slightly on the overkill side of things but not >> enough to reject things. >> >> On the performance/benefit side, if I read things correctly you only >> see the 9GB of Boolean objects because you disable >> reflection-inflation - is that right? In that case, as Joel states, >> the gains are not really general, but on the other hand I don't see >> anything wrong with trying to improve the general efficiency here even >> if the greatest benefit comes from a "non-mainstream" usecase. >> >> David >> ----- >> >>> My code changes this behavior and delegates object allocation back to >>> Java >>> by calling >>> >>> JavaCalls::call_static(&boxed_value, >>> klass_handle, >>> vmSymbols::valueOf_name(), >>> valueOf_signature, >>> &args, >>> THREAD); >>> >>> But maybe I misunderstood the implementation of JavaCalls. >>> >>> Best regards, >>> Andrej Golovnin >>> > From tobias.hartmann at oracle.com Tue Jun 3 05:54:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 03 Jun 2014 07:54:00 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <538CB68D.6050701@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com> <538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com> <361D0F73-1993-494F-A000-62D729963D06@oracle.com> <538CB68D.6050701@oracle.com> Message-ID: <538D62F8.8020105@oracle.com> Hi Vladimir, On 02.06.2014 19:38, Vladimir Ivanov wrote: > On 6/2/14 9:23 PM, Christian Thalinger wrote: >> >> On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov >> wrote: >> >>> Tobias, I'll take care of it. >> >> Are you also taking care of the backports? > Yes. I'll backport into 8u myself and for 7 I'll ask help from > Sustaining. Thank you! Best, Tobias > > Best regards, > Vladimir Ivanov >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 6/2/14 10:04 AM, Tobias Hartmann wrote: >>>> >>>> On 28.05.2014 12:48, Vladimir Ivanov wrote: >>>>> Looks good. >>>>> >>>>> It should be safe to sync on MTF instance since it's not accessible >>>>> outside (MTF and MT.form() are package-private). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> >>>> Thank you, Vladimir. >>>> >>>> Could someone please push the patch? >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> On 5/28/14 1:49 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> thanks everyone for the feedback! >>>>>> >>>>>> @Remi: I agree with Paul. This is not a problem because if the >>>>>> normal >>>>>> read sees an outdated null value, a new LambdaForm is created and >>>>>> setCachedLambdaForm(...) is executed. This will guarantee that the >>>>>> non-null value is seen and used. The unnecessary creation of a new >>>>>> LamdaForm is not a problem either. >>>>>> >>>>>> @John: I added the code that you suggested to simulate CAS. >>>>>> Please find >>>>>> the new webrev at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ >>>>>> >>>>>> Sorry for the delay, I was on vacation. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> On 19.05.2014 20:31, John Rose wrote: >>>>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann >>>>>>> wrote: >>>>>>> >>>>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>>>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>>>>>> Yes, that is how I see it. The fast path is a racy non-volatile >>>>>>> read >>>>>>> of a safely-published structure. >>>>>>> >>>>>>> (If safe publication via arrays were broken, java.lang.String >>>>>>> would be >>>>>>> broken. But the JMM is carefully designed to support safe >>>>>>> publication >>>>>>> of array elements, and through array elements.) >>>>>>> >>>>>>> ? John >>>>>> >>>> >> From luchsh at linux.vnet.ibm.com Tue Jun 3 09:51:02 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 3 Jun 2014 17:51:02 +0800 Subject: RFR 8043954: Fix behavior difference of connect() for AIX Message-ID: Hello, Could I have following patch reviewed for bug 8034954 ? http://cr.openjdk.java.net/~luchsh/JDK-8043954/ The patch is to fix a behavior difference of connect() API for AIX platform, according to the documentation, http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/connect.htm?lang=en On AIX, when connect() got interrupted by signal, the underlying connection will be made asynchronously, "EINTR The attempt to establish a connection was interrupted by delivery of a signal that was caught; the connection will be established asynchronously." This fix tries to poll() for successfully established connection or error in the similar way as NET_Timeout(). Thanks Jonathan From joel.franck at oracle.com Tue Jun 3 11:48:36 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 3 Jun 2014 13:48:36 +0200 Subject: RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type Message-ID: Hi Can I get a review for this small fix for https://bugs.openjdk.java.net/browse/JDK-8039916 Webrev here: http://cr.openjdk.java.net/~jfranck/8039916/webrev.01/ Since this is the second issue like this found recently I created a rather large test to see if there are any more lurking issues. I found one more, see: https://bugs.openjdk.java.net/browse/JDK-8044629 .I need to figure out what the right behavior for the new issue, is so I need to delay that fix. cheers /Joel From volker.simonis at gmail.com Tue Jun 3 12:48:32 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Jun 2014 14:48:32 +0200 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: Message-ID: Hi Jonathan, thanks for fixing this! I've looked at the change and it looks good to me (but I'm not a reviewer). The only minor flaw I found is that you declare the helper variable 'int rc = -1' but never assign it. Instead you could just return '-1' directly where you currently return 'rc' and remove 'rc' altogether. I'm currently still doing test build and I'll run some tests. I'll let you know if I should see any problems. By the way - does this change fix a real problem or is it just an improvement of the current implementation (just curious)? Thank you and best regards, Volker On Tue, Jun 3, 2014 at 11:51 AM, Jonathan Lu wrote: > Hello, > > Could I have following patch reviewed for bug 8034954 ? > > http://cr.openjdk.java.net/~luchsh/JDK-8043954/ > > The patch is to fix a behavior difference of connect() API for AIX platform, > according to the documentation, > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/connect.htm?lang=en > > On AIX, when connect() got interrupted by signal, the underlying connection > will be made asynchronously, > > "EINTR The attempt to establish a connection was interrupted by delivery of > a signal that was caught; the connection will be established > asynchronously." > > This fix tries to poll() for successfully established connection or error > in the similar way as NET_Timeout(). > > Thanks > Jonathan From roger.riggs at oracle.com Tue Jun 3 13:13:24 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 03 Jun 2014 09:13:24 -0400 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <538D30B9.4030002@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> <538BEA6B.10900@oracle.com> <538C8701.3030501@oracle.com> <538D30B9.4030002@oracle.com> Message-ID: <538DC9F4.9070000@oracle.com> Hi David, Sorry, crossed some email threads, in hotspot the compiler has no involvement. Changes to remove explicit wrapper types are being proposed in the libraries where the compiler can handle the boxing. Roger On 6/2/2014 10:19 PM, David Holmes wrote: > Hi Roger, > > On 3/06/2014 12:15 AM, roger riggs wrote: >> Hi David, et.al. >> >> I would let the compiler do auto-boxing where necessary. (Assuming >> object identity is not necessary). > > I don't see where the compiler comes into this one. ??? > > David > ----- > >> If type disambiguation is necessary then use a cast to the target >> type and >> let the compiler do the rest. It keeps the source code simple and >> readable. >> >> But I don't think it is worth a proactive pervasive change. >> The gain is overshadowed by the overhead of the reviews. >> >> $.02, Roger >> >> >> >> On 6/1/2014 11:07 PM, David Holmes wrote: >>> Hi Andrej, >>> >>> Sorry for the delay getting back to you. >>> >>> On 29/05/2014 10:24 PM, Andrej Golovnin wrote: >>>> Hi David, >>>> >>>>>> >>>>>> The valueOf calls may also allocate a new object so you can't just >>>>>> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you >>>>>> can't tell whether a new object was allocated or not. It is only >>>>>> for the >>>>>> smaller primitive types that any kind of Object caching is mandated. >>>>> >>>>> It is only for the smaller values (-128 to +127) of the integer >>>>> primitives types (plus boolean) that caching is mandated. >>>>> Float.valueOf and Double.valueOf always create objects. >>>>> >>>> >>>> You are right, that #valueOf call may allocate an object. >>>> But as far as I understand currently the >>>> JvmtiExport::post_vm_object_alloc call >>>> is only needed, because today the native code itself allocates an >>>> object >>>> by calling java_lang_boxing_object::create(type, value, CHECK_NULL);. >>> >>> Right, sorry - I was misunderstanding the purpose of the >>> post_vm_object_alloc call: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#VMObjectAlloc >>> >>> >>> >>> So from the perspective that you are diverting this back to Java code >>> the hotspot changes look okay to me. >>> >>> The more general question, for the core-libs folk, is whether changing >>> everything to use valueOf is overkill (given the limits of the >>> required caching mechanisms) or good to do from a consistency >>> perspective. I'm slightly on the overkill side of things but not >>> enough to reject things. >>> >>> On the performance/benefit side, if I read things correctly you only >>> see the 9GB of Boolean objects because you disable >>> reflection-inflation - is that right? In that case, as Joel states, >>> the gains are not really general, but on the other hand I don't see >>> anything wrong with trying to improve the general efficiency here even >>> if the greatest benefit comes from a "non-mainstream" usecase. >>> >>> David >>> ----- >>> >>>> My code changes this behavior and delegates object allocation back to >>>> Java >>>> by calling >>>> >>>> JavaCalls::call_static(&boxed_value, >>>> klass_handle, >>>> vmSymbols::valueOf_name(), >>>> valueOf_signature, >>>> &args, >>>> THREAD); >>>> >>>> But maybe I misunderstood the implementation of JavaCalls. >>>> >>>> Best regards, >>>> Andrej Golovnin >>>> >> From aleksej.efimov at oracle.com Tue Jun 3 13:49:12 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 03 Jun 2014 17:49:12 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> Message-ID: <538DD258.8020002@oracle.com> Staffan, David, Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ To abort the process the 'exitTransportWithError' function was utilized. Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. Best Regards, Aleksej On 05/15/2014 01:11 PM, Staffan Larsen wrote: > On 15 maj 2014, at 03:48, David Holmes wrote: > >> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>> David, Vitaly, >>> >>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>> and code in shmemBase.c (the usage of enterMutex() function for >>> sending/receiving bytes through shared memory connection) illustrates on >>> how the connection shutdown event is used as a "cancellation token". >> Thanks for clarifying that. >> >> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >> >> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >> >> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >> >> 204 /* If the mutex is abandoned we want to return an error >> 205 * and also release the mutex so that we don't cause >> 206 * other threads to be blocked. If a mutex was abandoned >> 207 * we are in scary state. Data may be corrupted or inconsistent >> 208 * but it is still better to let other threads run (and possibly >> 209 * crash) than having them blocked (on the premise that a crash >> 210 * is always easier to debug than a hang). >> >> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >> >> But I'll let the serviceability folk chime in here. > I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) > > I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. > > /Staffan > > >> Thanks, >> David >> >> >>> Thank you, >>> -Aleksej >>> >>> >>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>> functions, one of them employed in the code in question. If >>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>> current thread has ownership now. >>>> Yes I understand the basic mechanics :) >>>> >>>>> It's also common to use multi wait functions where the event is a >>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>> wanted to throw this out there in the meantime :). >>>> Ah I see - yes cancellable lock acquisition would make sense. >>>> >>>> Thanks, >>>> David >>>> >>>>> Sent from my phone >>>>> >>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>> > wrote: >>>>> >>>>> Hi Aleksej, >>>>> >>>>> Thanks for the doc references regarding abandonment. >>>>> >>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>> when this function is called? >>>>> >>>>> David >>>>> >>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>> >>>>> David, >>>>> >>>>> The Windows has a different terminology for mutex objects (much >>>>> differs >>>>> from the POSIX one). This one link gave me some understanding of >>>>> it [1]. >>>>> >>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>> " If a thread terminates without releasing its ownership of a >>>>> mutex >>>>> object, the mutex object is considered to be abandoned. A >>>>> waiting thread >>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>> object is >>>>> abandoned. An abandoned mutex object indicates that an error has >>>>> occurred and that any shared resource being protected by the >>>>> mutex >>>>> object is in an undefined state. If the thread proceeds as >>>>> though the >>>>> mutex object had not been abandoned, it is no longer considered >>>>> abandoned after the thread releases its ownership. This restores >>>>> normal >>>>> behavior if a handle to the mutex object is subsequently >>>>> specified in a >>>>> wait function." >>>>> >>>>> >>>>> What does it mean to wait on mutex and ownership of the mutex >>>>> object: >>>>> "Any thread with a handle to a mutex object can use one of >>>>> thewait >>>>> functions >>>>> >>>> >to >>>>> request ownership of the mutex object. If the mutex object is >>>>> owned by >>>>> another thread, the wait function blocks the requesting thread >>>>> until the >>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>> >>>> >__function." >>>>> >>>>> How we can release mutex and wait on already owned mutex: >>>>> " After a thread obtains ownership of a mutex, it can specify >>>>> the same >>>>> mutex in repeated calls to the wait-functions >>>>> >>>> >__without >>>>> blocking its execution. This prevents a thread from deadlocking >>>>> itself >>>>> while waiting for a mutex that it already owns. To release its >>>>> ownership >>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>> >>>> >__once >>>>> for each time that the mutex satisfied the conditions of a wait >>>>> function." >>>>> >>>>> [1] >>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>> >>>>> >>>>> -Aleksej >>>>> >>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>> >>>>> I don't understand this one at all. What is an "abandoned >>>>> mutex"? For >>>>> that matter why does the code wait on a mutex and an event? >>>>> Do we >>>>> already own the mutex? If so what does it mean to wait on >>>>> it? If not >>>>> then how can we release it? >>>>> >>>>> ??? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>> >>>>> >>>>> This is debugger's shared memory transport so cc'ing >>>>> serviceability-dev >>>>> as that is there this code is maintained. >>>>> >>>>> Is there a test case or any outline of the conditions >>>>> that cause this? I >>>>> think that would be useful to understand the issue >>>>> further. >>>>> >>>>> -Alan >>>>> >>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>> >>>>> Hi, >>>>> >>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>> There is a possible >>>>> case when 'WaitForMultipleObjects' function can >>>>> return the >>>>> WAIT_ABANDONED_0 [3] error value. >>>>> In such case it's better to release the mutex and >>>>> return error value. >>>>> This will prevent other threads to be blocked on >>>>> abandoned mutex. >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] >>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>> >>>>> [3] >>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>> >>>>> >>>>> >>>>> >>>>> From yiming.wang at oracle.com Tue Jun 3 13:51:19 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 03 Jun 2014 21:51:19 +0800 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> Message-ID: <538DD2D7.1050706@oracle.com> Hi Martin, Glad to know you are the original author and thank you to rewrite the test using modern way. I have some concerns about the limit of elapsed time (DELAY_MS / 2 = 50000ms) which is much higher than the old value (500ms). The reason is that i checked the nightly failure histories, there are dozens of failures which are caused by exception thrown at the call "check(latch.getCount() > 0)" in the run method of TimerTask. it is actually caused by the the task scheduled with fixed rate is not cancelled after latch reaches zero. None of the test failed due to the elapsed time larger than 500 ms. Sorry that I should paste the failure to clarify the problem: http://cr.openjdk.java.net/~ewang/JDK-8004807/failure.txt So are you OK that i adopt your test with 2 small changes: http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.01/ 1. keep the limit of elapsed time 500ms as it was. 2. cancel the task when latch reached zero. Thanks, Eric On 2014/5/31 4:26, Martin Buchholz wrote: > HI Eric, > > Thanks for working on my old dusty tests. > > I can't view the bug report - I get Permission Violation. > > It does look like you're making the test more robust, but at the cost > of throwing away much of what the test is testing, which is not so good. > > This test hardcodes 1 second as the period - it assumes all 13 task > invocations can be performed in 500ms, which may be a little > over-optimistic. Nevertheless, this failure should be very rare, eh? > But bump the period to a much higher number and we should be OK. > > I think making this an othervm test is overkill. Better to make the > test itself more robust. > > I propose instead this major rewrite: > > > > public class Args { > static final long DELAY_MS = 100 * 1000L; > > void schedule(final Timer t, final TimerTask task, final Date d) { > t.schedule(task, d); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d)); > } > > void schedule(final Timer t, final TimerTask task, final Date d, > final long period) { > t.schedule(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d, period)); > } > > void scheduleAtFixedRate(final Timer t, final TimerTask task, > final Date d, final long period) { > t.scheduleAtFixedRate(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.scheduleAtFixedRate(task, d, period)); > } > > TimerTask counter(final CountDownLatch latch) { > return new TimerTask() { public void run() { > check(latch.getCount() > 0); > latch.countDown(); > }}; > } > > TimerTask nop() { > return new TimerTask() { public void run() { }}; > } > > void test(String[] args) throws Throwable { > final Timer t = new Timer(); > try { > test(t); > } finally { > // Ensure this test doesn't interfere with subsequent > // tests even in case of failure. > t.cancel(); > } > > // Attempts to schedule tasks on a cancelled Timer result in ISE. > > final Date past = new Date(System.currentTimeMillis() - DELAY_MS); > final Date future = new Date(System.currentTimeMillis() + > DELAY_MS); > assertThrows > (IllegalStateException.class, > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), past), > () -> t.schedule(nop(), 42, 42), > () -> t.schedule(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), 42, 42), > () -> t.scheduleAtFixedRate(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), future, 42)); > } > > void test(Timer t) throws Throwable { > final TimerTask x = new TimerTask() { public void run() {}}; > assertThrows > (IllegalArgumentException.class, > () -> t.schedule(x, -42), > () -> t.schedule(x, new Date(-42)), > > () -> t.schedule(x, Long.MAX_VALUE), > () -> t.schedule(x, -42, 42), > () -> t.schedule(x, new Date(-42), 42), > () -> t.schedule(x, Long.MAX_VALUE, 42), > () -> t.schedule(x, 42, 0), > () -> t.schedule(x, new Date(42), 0), > () -> t.schedule(x, 42, -42), > () -> t.schedule(x, new Date(42), -42), > > () -> t.scheduleAtFixedRate(x, -42, 42), > () -> t.scheduleAtFixedRate(x, new Date(-42), 42), > () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), > () -> t.scheduleAtFixedRate(x, 42, 0), > () -> t.scheduleAtFixedRate(x, new Date(42), 0), > () -> t.scheduleAtFixedRate(x, 42, -42), > () -> t.scheduleAtFixedRate(x, new Date(42), -42)); > > assertThrows > (NullPointerException.class, > () -> t.schedule(null, 42), > () -> t.schedule(x, (Date)null), > > () -> t.schedule(null, 42, 42), > () -> t.schedule(x, (Date)null, 42), > > () -> t.scheduleAtFixedRate(null, 42, 42), > () -> t.scheduleAtFixedRate(x, (Date)null, 42)); > > final CountDownLatch y1 = new CountDownLatch(1); > final CountDownLatch y2 = new CountDownLatch(1); > final CountDownLatch y3 = new CountDownLatch(11); > final long start = System.currentTimeMillis(); > final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / > 2)); > > schedule( t, counter(y1), past); > schedule( t, counter(y2), past, DELAY_MS); > scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); > y3.await(); > y1.await(); > y2.await(); > > final long elapsed = System.currentTimeMillis() - start; > if (elapsed >= DELAY_MS / 2) > fail(String.format("Test took too long: elapsed=%d%n", > elapsed)); > } > > //--------------------- Infrastructure --------------------------- > volatile int passed = 0, failed = 0; > void pass() {passed++;} > void fail() {failed++; Thread.dumpStack();} > void fail(String msg) {System.err.println(msg); fail();} > void unexpected(Throwable t) {failed++; t.printStackTrace();} > void check(boolean cond) {if (cond) pass(); else fail();} > void equal(Object x, Object y) { > if (x == null ? y == null : x.equals(y)) pass(); > else fail(x + " not equal to " + y);} > public static void main(String[] args) throws Throwable { > new Args().instanceMain(args);} > void instanceMain(String[] args) throws Throwable { > try {test(args);} catch (Throwable t) {unexpected(t);} > System.out.printf("%nPassed = %d, failed = %d%n%n", passed, > failed); > if (failed > 0) throw new AssertionError("Some tests failed");} > interface F { void f() throws Throwable; } > void assertThrows(Class k, F... fs) { > for (F f : fs) > try {f.f(); fail("Expected " + k.getName() + " not thrown");} > catch (Throwable t) { > if (k.isAssignableFrom(t.getClass())) pass(); > else unexpected(t);}} > } > > > > On Fri, May 30, 2014 at 12:27 AM, Eric Wang > wrote: > > Hi, > > Please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8004807 as below: > http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ > > > The root cause of the failure is if Timer.cancel() is not called > in time, the recurring timer task keeps running which cause the > the assertion "check(latch.getCount() > 0)" failed. > > The fix includes: > 1. As the purpose of the assertion "check(latch.getCount() > 0)" > in timer task is used to check if the unrepeatable task is > executed repeatedly and this assertion is meaningless for a > repeatable task. it can be replaced by other way, see the webrev. > 2. The timer thread should be terminated ASAP once all tasks are > finished to avoid time spent on thread switch. > 3. The test should be executed in othervm mode to avoid time spent > on thread switch. > > Thanks, > Eric > > From sundararajan.athijegannathan at oracle.com Tue Jun 3 15:26:32 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 03 Jun 2014 20:56:32 +0530 Subject: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output Message-ID: <538DE928.7090903@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8044647/ Thanks, -Sundar From marcus.lagergren at oracle.com Tue Jun 3 15:30:32 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 3 Jun 2014 17:30:32 +0200 Subject: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output In-Reply-To: <538DE928.7090903@oracle.com> References: <538DE928.7090903@oracle.com> Message-ID: +1 On 03 Jun 2014, at 17:26, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044647/ > > Thanks, > -Sundar From james.laskey at oracle.com Tue Jun 3 15:31:41 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 3 Jun 2014 12:31:41 -0300 Subject: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output In-Reply-To: <538DE928.7090903@oracle.com> References: <538DE928.7090903@oracle.com> Message-ID: <3AE83045-20AC-4C58-B4C7-E11E6A225BA4@oracle.com> +1 On Jun 3, 2014, at 12:26 PM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044647/ > > Thanks, > -Sundar From kumar.x.srinivasan at oracle.com Tue Jun 3 15:49:15 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 03 Jun 2014 08:49:15 -0700 Subject: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output In-Reply-To: <538DE928.7090903@oracle.com> References: <538DE928.7090903@oracle.com> Message-ID: <538DEE7B.3070904@oracle.com> Looks good. Kumar On 6/3/2014 8:26 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044647/ > > Thanks, > -Sundar From kumar.x.srinivasan at oracle.com Tue Jun 3 15:50:34 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 03 Jun 2014 08:50:34 -0700 Subject: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output In-Reply-To: <538DEE7B.3070904@oracle.com> References: <538DE928.7090903@oracle.com> <538DEE7B.3070904@oracle.com> Message-ID: <538DEECA.5060909@oracle.com> don't forget to mark the bug with noreg-self. Kumar On 6/3/2014 8:49 AM, Kumar Srinivasan wrote: > Looks good. > > Kumar > > On 6/3/2014 8:26 AM, A. Sundararajan wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8044647/ >> >> Thanks, >> -Sundar > From martinrb at google.com Tue Jun 3 17:48:10 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Jun 2014 10:48:10 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538DD2D7.1050706@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> Message-ID: We can compromise and set the DELAY_MS to 10 seconds instead of 100 seconds. Note that the test is supposed to run quickly and should never actually hit DELAY_MS, so making it large is not a problem. I continue to not understand why you would need to cancel the task when the count reaches zero. Checking that the tasks are run the expected number of times, and no more .... ===> IS THE WHOLE POINT OF THIS TEST. <=== Maybe there's actually a bug in Timer that this test has discovered. Or perhaps there's a misunderstanding on my part about how many task scheduling is supposed to work. Please explain. On Tue, Jun 3, 2014 at 6:51 AM, Eric Wang wrote: > Hi Martin, > > Glad to know you are the original author and thank you to rewrite the test > using modern way. > > I have some concerns about the limit of elapsed time (DELAY_MS / 2 = > 50000ms) which is much higher than the old value (500ms). > The reason is that i checked the nightly failure histories, there are > dozens of failures which are caused by exception thrown at the call > "check(latch.getCount() > 0)" in the run method of TimerTask. it is > actually caused by the the task scheduled with fixed rate is not cancelled > after latch reaches zero. None of the test failed due to the elapsed time > larger than 500 ms. > > Sorry that I should paste the failure to clarify the problem: > http://cr.openjdk.java.net/~ewang/JDK-8004807/failure.txt > > So are you OK that i adopt your test with 2 small changes: > http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.01/ > 1. keep the limit of elapsed time 500ms as it was. > 2. cancel the task when latch reached zero. > > Thanks, > Eric > > > On 2014/5/31 4:26, Martin Buchholz wrote: > > HI Eric, > > Thanks for working on my old dusty tests. > > I can't view the bug report - I get Permission Violation. > > It does look like you're making the test more robust, but at the cost of > throwing away much of what the test is testing, which is not so good. > > This test hardcodes 1 second as the period - it assumes all 13 task > invocations can be performed in 500ms, which may be a little > over-optimistic. Nevertheless, this failure should be very rare, eh? But > bump the period to a much higher number and we should be OK. > > I think making this an othervm test is overkill. Better to make the > test itself more robust. > > I propose instead this major rewrite: > > > > public class Args { > static final long DELAY_MS = 100 * 1000L; > > void schedule(final Timer t, final TimerTask task, final Date d) { > t.schedule(task, d); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d)); > } > > void schedule(final Timer t, final TimerTask task, final Date d, > final long period) { > t.schedule(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d, period)); > } > > void scheduleAtFixedRate(final Timer t, final TimerTask task, final > Date d, final long period) { > t.scheduleAtFixedRate(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.scheduleAtFixedRate(task, d, period)); > } > > TimerTask counter(final CountDownLatch latch) { > return new TimerTask() { public void run() { > check(latch.getCount() > 0); > latch.countDown(); > }}; > } > > TimerTask nop() { > return new TimerTask() { public void run() { }}; > } > > void test(String[] args) throws Throwable { > final Timer t = new Timer(); > try { > test(t); > } finally { > // Ensure this test doesn't interfere with subsequent > // tests even in case of failure. > t.cancel(); > } > > // Attempts to schedule tasks on a cancelled Timer result in ISE. > > final Date past = new Date(System.currentTimeMillis() - > DELAY_MS); > final Date future = new Date(System.currentTimeMillis() + > DELAY_MS); > assertThrows > (IllegalStateException.class, > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), past), > () -> t.schedule(nop(), 42, 42), > () -> t.schedule(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), 42, 42), > () -> t.scheduleAtFixedRate(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), future, 42)); > } > > void test(Timer t) throws Throwable { > final TimerTask x = new TimerTask() { public void run() {}}; > assertThrows > (IllegalArgumentException.class, > () -> t.schedule(x, -42), > () -> t.schedule(x, new Date(-42)), > > () -> t.schedule(x, Long.MAX_VALUE), > () -> t.schedule(x, -42, 42), > () -> t.schedule(x, new Date(-42), 42), > () -> t.schedule(x, Long.MAX_VALUE, 42), > () -> t.schedule(x, 42, 0), > () -> t.schedule(x, new Date(42), 0), > () -> t.schedule(x, 42, -42), > () -> t.schedule(x, new Date(42), -42), > > () -> t.scheduleAtFixedRate(x, -42, 42), > () -> t.scheduleAtFixedRate(x, new Date(-42), 42), > () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), > () -> t.scheduleAtFixedRate(x, 42, 0), > () -> t.scheduleAtFixedRate(x, new Date(42), 0), > () -> t.scheduleAtFixedRate(x, 42, -42), > () -> t.scheduleAtFixedRate(x, new Date(42), -42)); > > assertThrows > (NullPointerException.class, > () -> t.schedule(null, 42), > () -> t.schedule(x, (Date)null), > > () -> t.schedule(null, 42, 42), > () -> t.schedule(x, (Date)null, 42), > > () -> t.scheduleAtFixedRate(null, 42, 42), > () -> t.scheduleAtFixedRate(x, (Date)null, 42)); > > final CountDownLatch y1 = new CountDownLatch(1); > final CountDownLatch y2 = new CountDownLatch(1); > final CountDownLatch y3 = new CountDownLatch(11); > final long start = System.currentTimeMillis(); > final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); > > schedule( t, counter(y1), past); > schedule( t, counter(y2), past, DELAY_MS); > scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); > y3.await(); > y1.await(); > y2.await(); > > final long elapsed = System.currentTimeMillis() - start; > if (elapsed >= DELAY_MS / 2) > fail(String.format("Test took too long: elapsed=%d%n", > elapsed)); > } > > //--------------------- Infrastructure --------------------------- > volatile int passed = 0, failed = 0; > void pass() {passed++;} > void fail() {failed++; Thread.dumpStack();} > void fail(String msg) {System.err.println(msg); fail();} > void unexpected(Throwable t) {failed++; t.printStackTrace();} > void check(boolean cond) {if (cond) pass(); else fail();} > void equal(Object x, Object y) { > if (x == null ? y == null : x.equals(y)) pass(); > else fail(x + " not equal to " + y);} > public static void main(String[] args) throws Throwable { > new Args().instanceMain(args);} > void instanceMain(String[] args) throws Throwable { > try {test(args);} catch (Throwable t) {unexpected(t);} > System.out.printf("%nPassed = %d, failed = %d%n%n", passed, > failed); > if (failed > 0) throw new AssertionError("Some tests failed");} > interface F { void f() throws Throwable; } > void assertThrows(Class k, F... fs) { > for (F f : fs) > try {f.f(); fail("Expected " + k.getName() + " not thrown");} > catch (Throwable t) { > if (k.isAssignableFrom(t.getClass())) pass(); > else unexpected(t);}} > } > > > > On Fri, May 30, 2014 at 12:27 AM, Eric Wang > wrote: > >> Hi, >> >> Please help to review the fix for bug >> https://bugs.openjdk.java.net/browse/JDK-8004807 as below: >> http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ >> >> The root cause of the failure is if Timer.cancel() is not called in time, >> the recurring timer task keeps running which cause the the assertion >> "check(latch.getCount() > 0)" failed. >> >> The fix includes: >> 1. As the purpose of the assertion "check(latch.getCount() > 0)" in timer >> task is used to check if the unrepeatable task is executed repeatedly and >> this assertion is meaningless for a repeatable task. it can be replaced by >> other way, see the webrev. >> 2. The timer thread should be terminated ASAP once all tasks are finished >> to avoid time spent on thread switch. >> 3. The test should be executed in othervm mode to avoid time spent on >> thread switch. >> >> Thanks, >> Eric >> > > > From roger.riggs at oracle.com Tue Jun 3 18:12:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 03 Jun 2014 14:12:29 -0400 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> Message-ID: <538E100D.90105@oracle.com> Hi Martin, Is it possible that the main thread takes too long to go from y3.await() to the t.cancel() that the fixed rate timer (y3) gets called again? It seems unlikely, but with the printf, its not just compute time. Canceling the timer before the printf would likely reduce the failures. Another alternative is to increase the period to allow more time for the main thread to respond. From the error, its not clear which timer was called an extra time. Roger On 6/3/2014 1:48 PM, Martin Buchholz wrote: > We can compromise and set the DELAY_MS to 10 seconds instead of 100 seconds. > Note that the test is supposed to run quickly and should never actually hit > DELAY_MS, so making it large is not a problem. > > I continue to not understand why you would need to cancel the task when the > count reaches zero. Checking that the tasks are run the expected number of > times, and no more .... > > ===> IS THE WHOLE POINT OF THIS TEST. <=== > > Maybe there's actually a bug in Timer that this test has discovered. Or > perhaps there's a misunderstanding on my part about how many task > scheduling is supposed to work. Please explain. > > > > On Tue, Jun 3, 2014 at 6:51 AM, Eric Wang wrote: > >> Hi Martin, >> >> Glad to know you are the original author and thank you to rewrite the test >> using modern way. >> >> I have some concerns about the limit of elapsed time (DELAY_MS / 2 = >> 50000ms) which is much higher than the old value (500ms). >> The reason is that i checked the nightly failure histories, there are >> dozens of failures which are caused by exception thrown at the call >> "check(latch.getCount() > 0)" in the run method of TimerTask. it is >> actually caused by the the task scheduled with fixed rate is not cancelled >> after latch reaches zero. None of the test failed due to the elapsed time >> larger than 500 ms. >> >> Sorry that I should paste the failure to clarify the problem: >> http://cr.openjdk.java.net/~ewang/JDK-8004807/failure.txt >> >> So are you OK that i adopt your test with 2 small changes: >> http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.01/ >> 1. keep the limit of elapsed time 500ms as it was. >> 2. cancel the task when latch reached zero. >> >> Thanks, >> Eric >> >> >> On 2014/5/31 4:26, Martin Buchholz wrote: >> >> HI Eric, >> >> Thanks for working on my old dusty tests. >> >> I can't view the bug report - I get Permission Violation. >> >> It does look like you're making the test more robust, but at the cost of >> throwing away much of what the test is testing, which is not so good. >> >> This test hardcodes 1 second as the period - it assumes all 13 task >> invocations can be performed in 500ms, which may be a little >> over-optimistic. Nevertheless, this failure should be very rare, eh? But >> bump the period to a much higher number and we should be OK. >> >> I think making this an othervm test is overkill. Better to make the >> test itself more robust. >> >> I propose instead this major rewrite: >> >> >> >> public class Args { >> static final long DELAY_MS = 100 * 1000L; >> >> void schedule(final Timer t, final TimerTask task, final Date d) { >> t.schedule(task, d); >> assertThrows >> (IllegalStateException.class, >> () -> t.schedule(task, d)); >> } >> >> void schedule(final Timer t, final TimerTask task, final Date d, >> final long period) { >> t.schedule(task, d, period); >> assertThrows >> (IllegalStateException.class, >> () -> t.schedule(task, d, period)); >> } >> >> void scheduleAtFixedRate(final Timer t, final TimerTask task, final >> Date d, final long period) { >> t.scheduleAtFixedRate(task, d, period); >> assertThrows >> (IllegalStateException.class, >> () -> t.scheduleAtFixedRate(task, d, period)); >> } >> >> TimerTask counter(final CountDownLatch latch) { >> return new TimerTask() { public void run() { >> check(latch.getCount() > 0); >> latch.countDown(); >> }}; >> } >> >> TimerTask nop() { >> return new TimerTask() { public void run() { }}; >> } >> >> void test(String[] args) throws Throwable { >> final Timer t = new Timer(); >> try { >> test(t); >> } finally { >> // Ensure this test doesn't interfere with subsequent >> // tests even in case of failure. >> t.cancel(); >> } >> >> // Attempts to schedule tasks on a cancelled Timer result in ISE. >> >> final Date past = new Date(System.currentTimeMillis() - >> DELAY_MS); >> final Date future = new Date(System.currentTimeMillis() + >> DELAY_MS); >> assertThrows >> (IllegalStateException.class, >> () -> t.schedule(nop(), 42), >> () -> t.schedule(nop(), 42), >> () -> t.schedule(nop(), past), >> () -> t.schedule(nop(), 42, 42), >> () -> t.schedule(nop(), past, 42), >> () -> t.scheduleAtFixedRate(nop(), 42, 42), >> () -> t.scheduleAtFixedRate(nop(), past, 42), >> () -> t.scheduleAtFixedRate(nop(), future, 42)); >> } >> >> void test(Timer t) throws Throwable { >> final TimerTask x = new TimerTask() { public void run() {}}; >> assertThrows >> (IllegalArgumentException.class, >> () -> t.schedule(x, -42), >> () -> t.schedule(x, new Date(-42)), >> >> () -> t.schedule(x, Long.MAX_VALUE), >> () -> t.schedule(x, -42, 42), >> () -> t.schedule(x, new Date(-42), 42), >> () -> t.schedule(x, Long.MAX_VALUE, 42), >> () -> t.schedule(x, 42, 0), >> () -> t.schedule(x, new Date(42), 0), >> () -> t.schedule(x, 42, -42), >> () -> t.schedule(x, new Date(42), -42), >> >> () -> t.scheduleAtFixedRate(x, -42, 42), >> () -> t.scheduleAtFixedRate(x, new Date(-42), 42), >> () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), >> () -> t.scheduleAtFixedRate(x, 42, 0), >> () -> t.scheduleAtFixedRate(x, new Date(42), 0), >> () -> t.scheduleAtFixedRate(x, 42, -42), >> () -> t.scheduleAtFixedRate(x, new Date(42), -42)); >> >> assertThrows >> (NullPointerException.class, >> () -> t.schedule(null, 42), >> () -> t.schedule(x, (Date)null), >> >> () -> t.schedule(null, 42, 42), >> () -> t.schedule(x, (Date)null, 42), >> >> () -> t.scheduleAtFixedRate(null, 42, 42), >> () -> t.scheduleAtFixedRate(x, (Date)null, 42)); >> >> final CountDownLatch y1 = new CountDownLatch(1); >> final CountDownLatch y2 = new CountDownLatch(1); >> final CountDownLatch y3 = new CountDownLatch(11); >> final long start = System.currentTimeMillis(); >> final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); >> >> schedule( t, counter(y1), past); >> schedule( t, counter(y2), past, DELAY_MS); >> scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); >> y3.await(); >> y1.await(); >> y2.await(); >> >> final long elapsed = System.currentTimeMillis() - start; >> if (elapsed >= DELAY_MS / 2) >> fail(String.format("Test took too long: elapsed=%d%n", >> elapsed)); >> } >> >> //--------------------- Infrastructure --------------------------- >> volatile int passed = 0, failed = 0; >> void pass() {passed++;} >> void fail() {failed++; Thread.dumpStack();} >> void fail(String msg) {System.err.println(msg); fail();} >> void unexpected(Throwable t) {failed++; t.printStackTrace();} >> void check(boolean cond) {if (cond) pass(); else fail();} >> void equal(Object x, Object y) { >> if (x == null ? y == null : x.equals(y)) pass(); >> else fail(x + " not equal to " + y);} >> public static void main(String[] args) throws Throwable { >> new Args().instanceMain(args);} >> void instanceMain(String[] args) throws Throwable { >> try {test(args);} catch (Throwable t) {unexpected(t);} >> System.out.printf("%nPassed = %d, failed = %d%n%n", passed, >> failed); >> if (failed > 0) throw new AssertionError("Some tests failed");} >> interface F { void f() throws Throwable; } >> void assertThrows(Class k, F... fs) { >> for (F f : fs) >> try {f.f(); fail("Expected " + k.getName() + " not thrown");} >> catch (Throwable t) { >> if (k.isAssignableFrom(t.getClass())) pass(); >> else unexpected(t);}} >> } >> >> >> >> On Fri, May 30, 2014 at 12:27 AM, Eric Wang >> wrote: >> >>> Hi, >>> >>> Please help to review the fix for bug >>> https://bugs.openjdk.java.net/browse/JDK-8004807 as below: >>> http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ >>> >>> The root cause of the failure is if Timer.cancel() is not called in time, >>> the recurring timer task keeps running which cause the the assertion >>> "check(latch.getCount() > 0)" failed. >>> >>> The fix includes: >>> 1. As the purpose of the assertion "check(latch.getCount() > 0)" in timer >>> task is used to check if the unrepeatable task is executed repeatedly and >>> this assertion is meaningless for a repeatable task. it can be replaced by >>> other way, see the webrev. >>> 2. The timer thread should be terminated ASAP once all tasks are finished >>> to avoid time spent on thread switch. >>> 3. The test should be executed in othervm mode to avoid time spent on >>> thread switch. >>> >>> Thanks, >>> Eric >>> >> >> From xueming.shen at oracle.com Tue Jun 3 22:34:19 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 03 Jun 2014 15:34:19 -0700 Subject: RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files Message-ID: <538E4D6B.1040004@oracle.com> Hi, Please help review the change to upgrade the zlib bundled with jdk/jre from 1.2.5 to 1.2.8. This is mainly to address the bug fix mentioned in 1.2.8's release at zlib.net. "Version 1.2.8 fixes a very rare bug in decompression. All users are encouraged to upgrade immediately..." http://cr.openjdk.java.net/~sherman/8044725/webrev thanks! -Sherman From iris.clark at oracle.com Wed Jun 4 00:01:18 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 3 Jun 2014 17:01:18 -0700 (PDT) Subject: RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files In-Reply-To: <538E4D6B.1040004@oracle.com> References: <538E4D6B.1040004@oracle.com> Message-ID: <5bb63f0b-2146-42e4-8836-8294ec054773@default> Hi, Sherman. http://cr.openjdk.java.net/~sherman/8044725/webrev I took a look at the legal notices in the new files and they all seem fine to me. Thanks, iris -----Original Message----- From: Xueming Shen Sent: Tuesday, June 03, 2014 3:34 PM To: core-libs-dev Subject: RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files Hi, Please help review the change to upgrade the zlib bundled with jdk/jre from 1.2.5 to 1.2.8. This is mainly to address the bug fix mentioned in 1.2.8's release at zlib.net. "Version 1.2.8 fixes a very rare bug in decompression. All users are encouraged to upgrade immediately..." http://cr.openjdk.java.net/~sherman/8044725/webrev thanks! -Sherman From martinrb at google.com Wed Jun 4 00:33:57 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Jun 2014 17:33:57 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538E100D.90105@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> Message-ID: On Tue, Jun 3, 2014 at 11:12 AM, roger riggs wrote: > Hi Martin, > > Is it possible that the main thread takes too long to go from y3.await() > to the t.cancel() that the fixed rate timer (y3) gets called again? > > If that was true, adding a sleep(1000) after the awaits in my version would cause consistent failures, but I don't see any. > It seems unlikely, but with the printf, its not just compute time. > Canceling the timer before the printf would likely reduce the failures. > Again, we need to understand the failures independently. I have never seen this test fail. Is there some environmental thing? > Another alternative is to increase the period to allow more time for the > main thread to respond. > I agree that this would make the test more robust, and that's one thing my version does. > From the error, its not clear which timer was called an extra time. > > True. My updated version tries to fix that problem. Hopefully you can report which task is being scheduled too often. import java.util.*; import java.util.concurrent.*; public class Args { static final long DELAY_MS = 10 * 1000L; void schedule(final Timer t, final TimerTask task, final Date d) { t.schedule(task, d); assertThrows (IllegalStateException.class, () -> t.schedule(task, d)); } void schedule(final Timer t, final TimerTask task, final Date d, final long period) { t.schedule(task, d, period); assertThrows (IllegalStateException.class, () -> t.schedule(task, d, period)); } void scheduleAtFixedRate(final Timer t, final TimerTask task, final Date d, final long period) { t.scheduleAtFixedRate(task, d, period); assertThrows (IllegalStateException.class, () -> t.scheduleAtFixedRate(task, d, period)); } TimerTask counter(final CountDownLatch latch) { return new TimerTask() { public void run() { if (latch.getCount() == 0) fail(String.format("Latch counted down too many times: " + latch)); latch.countDown(); }}; } TimerTask nop() { return new TimerTask() { public void run() { }}; } void test(String[] args) throws Throwable { final Timer t = new Timer(); try { test(t); } finally { // Ensure this test doesn't interfere with subsequent // tests even in case of failure. t.cancel(); } // Attempts to schedule tasks on a cancelled Timer result in ISE. final Date past = new Date(System.currentTimeMillis() - DELAY_MS); final Date future = new Date(System.currentTimeMillis() + DELAY_MS); assertThrows (IllegalStateException.class, () -> t.schedule(nop(), 42), () -> t.schedule(nop(), 42), () -> t.schedule(nop(), past), () -> t.schedule(nop(), 42, 42), () -> t.schedule(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), 42, 42), () -> t.scheduleAtFixedRate(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), future, 42)); } void test(Timer t) throws Throwable { final TimerTask x = new TimerTask() { public void run() {}}; assertThrows (IllegalArgumentException.class, () -> t.schedule(x, -42), () -> t.schedule(x, new Date(-42)), () -> t.schedule(x, Long.MAX_VALUE), () -> t.schedule(x, -42, 42), () -> t.schedule(x, new Date(-42), 42), () -> t.schedule(x, Long.MAX_VALUE, 42), () -> t.schedule(x, 42, 0), () -> t.schedule(x, new Date(42), 0), () -> t.schedule(x, 42, -42), () -> t.schedule(x, new Date(42), -42), () -> t.scheduleAtFixedRate(x, -42, 42), () -> t.scheduleAtFixedRate(x, new Date(-42), 42), () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), () -> t.scheduleAtFixedRate(x, 42, 0), () -> t.scheduleAtFixedRate(x, new Date(42), 0), () -> t.scheduleAtFixedRate(x, 42, -42), () -> t.scheduleAtFixedRate(x, new Date(42), -42)); assertThrows (NullPointerException.class, () -> t.schedule(null, 42), () -> t.schedule(x, (Date)null), () -> t.schedule(null, 42, 42), () -> t.schedule(x, (Date)null, 42), () -> t.scheduleAtFixedRate(null, 42, 42), () -> t.scheduleAtFixedRate(x, (Date)null, 42)); // Create local classes for clearer diagnostics in case of failure class OneShotLatch extends CountDownLatch { OneShotLatch() { super(1); } } class FixedRateLatch extends CountDownLatch { FixedRateLatch() { super(11); } } class FixedDelayLatch extends CountDownLatch { FixedDelayLatch() { super(1); } } final CountDownLatch y1 = new OneShotLatch(); final CountDownLatch y2 = new FixedDelayLatch(); final CountDownLatch y3 = new FixedRateLatch(); final long start = System.currentTimeMillis(); final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); schedule( t, counter(y1), past); schedule( t, counter(y2), past, DELAY_MS); scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); y1.await(); y2.await(); y3.await(); final long elapsed = System.currentTimeMillis() - start; if (elapsed >= DELAY_MS / 2) fail(String.format("Test took too long: elapsed=%d%n", elapsed)); } //--------------------- Infrastructure --------------------------- volatile int passed = 0, failed = 0; void pass() {passed++;} void fail() {failed++; Thread.dumpStack();} void fail(String msg) {System.err.println(msg); fail();} void unexpected(Throwable t) {failed++; t.printStackTrace();} void check(boolean cond) {if (cond) pass(); else fail();} void equal(Object x, Object y) { if (x == null ? y == null : x.equals(y)) pass(); else fail(x + " not equal to " + y);} public static void main(String[] args) throws Throwable { new Args().instanceMain(args);} void instanceMain(String[] args) throws Throwable { try {test(args);} catch (Throwable t) {unexpected(t);} System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); if (failed > 0) throw new AssertionError("Some tests failed");} interface F { void f() throws Throwable; } void assertThrows(Class k, F... fs) { for (F f : fs) try {f.f(); fail("Expected " + k.getName() + " not thrown");} catch (Throwable t) { if (k.isAssignableFrom(t.getClass())) pass(); else unexpected(t);}} } From yiming.wang at oracle.com Wed Jun 4 01:12:26 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 04 Jun 2014 09:12:26 +0800 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> Message-ID: <538E727A.5020507@oracle.com> Hi Martin, To sleep(1000) is not enough to reproduce the failure, because it is much lower than the period DELAY_MS (10*1000) of the repeated task created by "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". Try sleep(DELAY_MS), the failure can be reproduced. Thanks, Eric On 2014/6/4 8:33, Martin Buchholz wrote: > On Tue, Jun 3, 2014 at 11:12 AM, roger riggs wrote: > >> Hi Martin, >> >> Is it possible that the main thread takes too long to go from y3.await() >> to the t.cancel() that the fixed rate timer (y3) gets called again? >> >> > If that was true, adding a sleep(1000) after the awaits in my version would > cause consistent failures, but I don't see any. > > >> It seems unlikely, but with the printf, its not just compute time. >> Canceling the timer before the printf would likely reduce the failures. >> > Again, we need to understand the failures independently. I have never seen > this test fail. Is there some environmental thing? > > >> Another alternative is to increase the period to allow more time for the >> main thread to respond. >> > I agree that this would make the test more robust, and that's one thing my > version does. > > >> From the error, its not clear which timer was called an extra time. >> >> > True. > My updated version tries to fix that problem. > Hopefully you can report which task is being scheduled too often. > > > import java.util.*; > import java.util.concurrent.*; > > public class Args { > static final long DELAY_MS = 10 * 1000L; > > void schedule(final Timer t, final TimerTask task, final Date d) { > t.schedule(task, d); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d)); > } > > void schedule(final Timer t, final TimerTask task, final Date d, final > long period) { > t.schedule(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.schedule(task, d, period)); > } > > void scheduleAtFixedRate(final Timer t, final TimerTask task, final > Date d, final long period) { > t.scheduleAtFixedRate(task, d, period); > assertThrows > (IllegalStateException.class, > () -> t.scheduleAtFixedRate(task, d, period)); > } > > TimerTask counter(final CountDownLatch latch) { > return new TimerTask() { public void run() { > if (latch.getCount() == 0) > fail(String.format("Latch counted down too many times: " + > latch)); > latch.countDown(); > }}; > } > > TimerTask nop() { > return new TimerTask() { public void run() { }}; > } > > void test(String[] args) throws Throwable { > final Timer t = new Timer(); > try { > test(t); > } finally { > // Ensure this test doesn't interfere with subsequent > // tests even in case of failure. > t.cancel(); > } > > // Attempts to schedule tasks on a cancelled Timer result in ISE. > > final Date past = new Date(System.currentTimeMillis() - DELAY_MS); > final Date future = new Date(System.currentTimeMillis() + DELAY_MS); > assertThrows > (IllegalStateException.class, > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), 42), > () -> t.schedule(nop(), past), > () -> t.schedule(nop(), 42, 42), > () -> t.schedule(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), 42, 42), > () -> t.scheduleAtFixedRate(nop(), past, 42), > () -> t.scheduleAtFixedRate(nop(), future, 42)); > } > > void test(Timer t) throws Throwable { > final TimerTask x = new TimerTask() { public void run() {}}; > assertThrows > (IllegalArgumentException.class, > () -> t.schedule(x, -42), > () -> t.schedule(x, new Date(-42)), > > () -> t.schedule(x, Long.MAX_VALUE), > () -> t.schedule(x, -42, 42), > () -> t.schedule(x, new Date(-42), 42), > () -> t.schedule(x, Long.MAX_VALUE, 42), > () -> t.schedule(x, 42, 0), > () -> t.schedule(x, new Date(42), 0), > () -> t.schedule(x, 42, -42), > () -> t.schedule(x, new Date(42), -42), > > () -> t.scheduleAtFixedRate(x, -42, 42), > () -> t.scheduleAtFixedRate(x, new Date(-42), 42), > () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), > () -> t.scheduleAtFixedRate(x, 42, 0), > () -> t.scheduleAtFixedRate(x, new Date(42), 0), > () -> t.scheduleAtFixedRate(x, 42, -42), > () -> t.scheduleAtFixedRate(x, new Date(42), -42)); > > assertThrows > (NullPointerException.class, > () -> t.schedule(null, 42), > () -> t.schedule(x, (Date)null), > > () -> t.schedule(null, 42, 42), > () -> t.schedule(x, (Date)null, 42), > > () -> t.scheduleAtFixedRate(null, 42, 42), > () -> t.scheduleAtFixedRate(x, (Date)null, 42)); > > // Create local classes for clearer diagnostics in case of failure > class OneShotLatch extends CountDownLatch { > OneShotLatch() { super(1); } > } > class FixedRateLatch extends CountDownLatch { > FixedRateLatch() { super(11); } > } > class FixedDelayLatch extends CountDownLatch { > FixedDelayLatch() { super(1); } > } > final CountDownLatch y1 = new OneShotLatch(); > final CountDownLatch y2 = new FixedDelayLatch(); > final CountDownLatch y3 = new FixedRateLatch(); > final long start = System.currentTimeMillis(); > final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); > > schedule( t, counter(y1), past); > schedule( t, counter(y2), past, DELAY_MS); > scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); > y1.await(); > y2.await(); > y3.await(); > > final long elapsed = System.currentTimeMillis() - start; > if (elapsed >= DELAY_MS / 2) > fail(String.format("Test took too long: elapsed=%d%n", > elapsed)); > } > > //--------------------- Infrastructure --------------------------- > volatile int passed = 0, failed = 0; > void pass() {passed++;} > void fail() {failed++; Thread.dumpStack();} > void fail(String msg) {System.err.println(msg); fail();} > void unexpected(Throwable t) {failed++; t.printStackTrace();} > void check(boolean cond) {if (cond) pass(); else fail();} > void equal(Object x, Object y) { > if (x == null ? y == null : x.equals(y)) pass(); > else fail(x + " not equal to " + y);} > public static void main(String[] args) throws Throwable { > new Args().instanceMain(args);} > void instanceMain(String[] args) throws Throwable { > try {test(args);} catch (Throwable t) {unexpected(t);} > System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); > if (failed > 0) throw new AssertionError("Some tests failed");} > interface F { void f() throws Throwable; } > void assertThrows(Class k, F... fs) { > for (F f : fs) > try {f.f(); fail("Expected " + k.getName() + " not thrown");} > catch (Throwable t) { > if (k.isAssignableFrom(t.getClass())) pass(); > else unexpected(t);}} > } From martinrb at google.com Wed Jun 4 01:16:50 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Jun 2014 18:16:50 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538E727A.5020507@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> Message-ID: On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang wrote: > Hi Martin, > > To sleep(1000) is not enough to reproduce the failure, because it is much > lower than the period DELAY_MS (10*1000) of the repeated task created by > "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". > > Try sleep(DELAY_MS), the failure can be reproduced. > Well sure, then the task is rescheduled, so I expect it to fail in this case. But in my version I had set DELAY_MS to 100 seconds. The point of extending the DELAY_MS is to prevent flaky failure on a slow machine. Again, how do we know that this test hasn't found a Timer bug? I still can't reproduce it. From henry.jen at oracle.com Wed Jun 4 01:22:00 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 03 Jun 2014 18:22:00 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo Message-ID: <538E74B8.20603@oracle.com> Hi, In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions. The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information. Some public APIs are using @since format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE. There are APIs without @since information, separate webrevs will be coming to complete those information. Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 The webrev can be found at http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev but it's probably easier just look into the raw diff, http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset Cheers, Henry From mike.duigou at oracle.com Wed Jun 4 03:17:10 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Jun 2014 20:17:10 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> You will need to include awt-dev and security-dev since this patch touches those areas as well. Other impacted groups I missed? I would like to see this all go back in one changeset to dev repo though as it would be a lot cleaner that way. I am concerned a bit that if we retain standard names for non-jdk standards it may be sometimes confusing or lacking in context to see a raw version number. Consistency is trumps all, but I would prefer to see JDK#.#[.#] used to be unambiguous. I don't see any missteps in the changeset but wouldn't want mine to be the only review. Mike On Jun 3 2014, at 18:22 , Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. > > So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions. > > The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry From pbenedict at apache.org Wed Jun 4 03:38:54 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 3 Jun 2014 22:38:54 -0500 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> References: <538E74B8.20603@oracle.com> <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> Message-ID: I like seeing "JDK" as well... primarily because IDEs have the ability to show javadoc snippets when hovering over an element. It's good to see what product the version comes relates to. Yet, on the other hand, these Oracle APIs are not published under "JDK" branding but under the title "Java SE". Shouldn't that be used instead? Cheers, Paul On Tue, Jun 3, 2014 at 10:17 PM, Mike Duigou wrote: > You will need to include awt-dev and security-dev since this patch touches > those areas as well. Other impacted groups I missed? > > I would like to see this all go back in one changeset to dev repo though > as it would be a lot cleaner that way. > > I am concerned a bit that if we retain standard names for non-jdk > standards it may be sometimes confusing or lacking in context to see a raw > version number. Consistency is trumps all, but I would prefer to see > JDK#.#[.#] used to be unambiguous. > > I don't see any missteps in the changeset but wouldn't want mine to be the > only review. > > Mike > > On Jun 3 2014, at 18:22 , Henry Jen wrote: > > > Hi, > > > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > > > So started with the most obvious ones, where we have various expression > for JDK version, this webrev make sure we use @since 1.n[.n] for JDK > versions. > > > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > > > Some public APIs are using @since format, > they are also preserved for now, but I think it worth discussion whether we > want to change to the version as included in J2SE. > > > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > > The webrev can be found at > > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > > > but it's probably easier just look into the raw diff, > > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > > > Cheers, > > Henry > > From philip.race at oracle.com Wed Jun 4 05:16:39 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 03 Jun 2014 22:16:39 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> References: <538E74B8.20603@oracle.com> <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> Message-ID: <538EABB7.7050900@oracle.com> On 6/3/14 8:17 PM, Mike Duigou wrote: > You will need to include awt-dev and security-dev since this patch touches those areas as well. Other impacted groups I missed? awt-dev is not all. This patch touches 2D and Swing code also. so awt-dev, 2d-dev & swing-dev. Those need to be pushed to 9/client and reviewed there. I wonder if @since on the implementation classes is even worth it or whether there is a policy there. No one should be reading that part of the doc. Did you just blindly change everything or did you consider what is really API ? Its probably inconsistently applied too. Maybe they should be @Override instead 0- where applicable - else removed. > > I would like to see this all go back in one changeset to dev repo though as it would be a lot cleaner that way. > > I am concerned a bit that if we retain standard names for non-jdk standards it may be sometimes confusing or lacking in context to see a raw version number. Consistency is trumps all, but I would prefer to see JDK#.#[.#] used to be unambiguous. That is a high order bit. If anything is to be touched, the result had better be what is wanted long term. -phil. > > I don't see any missteps in the changeset but wouldn't want mine to be the only review. > > Mike > > On Jun 3 2014, at 18:22 , Henry Jen wrote: > >> Hi, >> >> In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. >> >> So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions. >> >> The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information. >> >> Some public APIs are using @since format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE. >> >> There are APIs without @since information, separate webrevs will be coming to complete those information. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 >> The webrev can be found at >> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev >> >> but it's probably easier just look into the raw diff, >> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset >> >> Cheers, >> Henry From yiming.wang at oracle.com Wed Jun 4 06:28:35 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 04 Jun 2014 14:28:35 +0800 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> Message-ID: <538EBC93.4080409@oracle.com> Hi Martin, Thanks for explanation, now I can understand why you set the DELAY_MS to 100 seconds, it is true that it prevents failure on a slow host, however, i still have some concerns. Because the test tests to schedule tasks at the time in the past, so all 13 tasks should be executed immediately and finished within a short time. If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that the timer have plenty of time to finish tasks, so whether it causes above test point lost. Back to the original test, i think it should be a test stabilization issue, because the original test assumes that the timer should be cancelled within < 1 second before the 14th task is called. this assumption may not be guaranteed due to 2 reasons: 1. if test is executed in jtreg concurrent mode on a slow host. 2. the system clock of virtual machine may not be accurate (maybe faster than physical). To support the point, i changed the test as attached to print the execution time to see whether the timer behaves expected as the API document described. the result is as expected. The unrepeated task executed immediately: [1401855509336] The repeated task executed immediately and repeated per 1 second: [1401855509337, 1401855510337, 1401855511338] The fixed-rate task executed immediately and catch up the delay: [1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509836, 1401855510836] Thanks, Eric On 2014/6/4 9:16, Martin Buchholz wrote: > > > > On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang > wrote: > > Hi Martin, > > To sleep(1000) is not enough to reproduce the failure, because it > is much lower than the period DELAY_MS (10*1000) of the repeated > task created by "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". > > Try sleep(DELAY_MS), the failure can be reproduced. > > > Well sure, then the task is rescheduled, so I expect it to fail in > this case. > > But in my version I had set DELAY_MS to 100 seconds. The point of > extending the DELAY_MS is to prevent flaky failure on a slow machine. > > Again, how do we know that this test hasn't found a Timer bug? > > I still can't reproduce it. -------------- next part -------------- diff -r a02731d3f739 test/java/util/Timer/Args.java --- a/test/java/util/Timer/Args.java Thu May 29 22:32:11 2014 -0700 +++ b/test/java/util/Timer/Args.java Wed Jun 04 14:17:57 2014 +0800 @@ -49,9 +49,9 @@ new F(){void f(){ t.scheduleAtFixedRate(task, d, period); }}); } - TimerTask counter(final CountDownLatch latch) { + TimerTask counter(final CountDownLatch latch, final ArrayList list) { return new TimerTask() { public void run() { - check(latch.getCount() > 0); + list.add(System.currentTimeMillis()); latch.countDown(); }}; } @@ -97,10 +97,12 @@ final CountDownLatch y3 = new CountDownLatch(11); final long start = System.currentTimeMillis(); final Date past = new Date(start - 10500); - - schedule( t, counter(y1), past); - schedule( t, counter(y2), past, 1000); - scheduleAtFixedRate(t, counter(y3), past, 1000); + ArrayList l1 = new ArrayList<>(); + ArrayList l2 = new ArrayList<>(); + ArrayList l3 = new ArrayList<>(); + schedule( t, counter(y1, l1), past); + schedule( t, counter(y2, l2), past, 1000); + scheduleAtFixedRate(t, counter(y3, l3), past, 1000); y3.await(); y1.await(); y2.await(); @@ -108,9 +110,11 @@ final long elapsed = System.currentTimeMillis() - start; System.out.printf("elapsed=%d%n", elapsed); check(elapsed < 500); - + Thread.sleep(2000); t.cancel(); - + System.out.println("l1 " + Objects.toString(l1)); + System.out.println("l2 " + Objects.toString(l2)); + System.out.println("l3 " + Objects.toString(l3)); THROWS(IllegalStateException.class, new F(){void f(){ t.schedule(x, 42); }}, new F(){void f(){ t.schedule(x, past); }}, From luchsh at linux.vnet.ibm.com Wed Jun 4 06:31:37 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 4 Jun 2014 14:31:37 +0800 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: Message-ID: Hi Volker, Thanks for your comment! an updated webrev was made at http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/ On Tue, Jun 3, 2014 at 8:48 PM, Volker Simonis wrote: > Hi Jonathan, > > thanks for fixing this! I've looked at the change and it looks good to > me (but I'm not a reviewer). > The only minor flaw I found is that you declare the helper variable > 'int rc = -1' but never assign it. Instead you could just return '-1' > directly where you currently return 'rc' and remove 'rc' altogether. > The new patch contains this change and another formatting change. > > I'm currently still doing test build and I'll run some tests. I'll let > you know if I should see any problems. > > By the way - does this change fix a real problem or is it just an > improvement of the current implementation (just curious)? > The change is now an improvement. > > Thank you and best regards, > Volker > > > On Tue, Jun 3, 2014 at 11:51 AM, Jonathan Lu > wrote: > > Hello, > > > > Could I have following patch reviewed for bug 8034954 ? > > > > http://cr.openjdk.java.net/~luchsh/JDK-8043954/ > > > > The patch is to fix a behavior difference of connect() API for AIX > platform, > > according to the documentation, > > > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/connect.htm?lang=en > > > > On AIX, when connect() got interrupted by signal, the underlying > connection > > will be made asynchronously, > > > > "EINTR The attempt to establish a connection was interrupted by delivery > of > > a signal that was caught; the connection will be established > > asynchronously." > > > > This fix tries to poll() for successfully established connection or error > > in the similar way as NET_Timeout(). > > > > Thanks > > Jonathan > Thank you and best regards Jonathan From Alan.Bateman at oracle.com Wed Jun 4 06:57:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Jun 2014 07:57:35 +0100 Subject: RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files In-Reply-To: <538E4D6B.1040004@oracle.com> References: <538E4D6B.1040004@oracle.com> Message-ID: <538EC35F.8000401@oracle.com> On 03/06/2014 23:34, Xueming Shen wrote: > Hi, > > Please help review the change to upgrade the zlib bundled with jdk/jre > from 1.2.5 to 1.2.8. > > This is mainly to address the bug fix mentioned in 1.2.8's release at > zlib.net. > "Version 1.2.8 fixes a very rare bug in decompression. All users are > encouraged to upgrade immediately..." > > http://cr.openjdk.java.net/~sherman/8044725/webrev This looks good to me. The issue is remainder that we should consider switching the default to --with-zlib=system from bundled, at least for Linux and Solaris (already done on OS X, not feasible on Windows). -Alan From staffan.larsen at oracle.com Wed Jun 4 07:23:22 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Jun 2014 09:23:22 +0200 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <538DD258.8020002@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> Message-ID: <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> Looks ok to me. /Staffan On 3 jun 2014, at 15:49, Aleksej Efimov wrote: > Staffan, David, > > Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: > Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). > I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ > To abort the process the 'exitTransportWithError' function was utilized. > Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. > > Best Regards, > Aleksej > > On 05/15/2014 01:11 PM, Staffan Larsen wrote: >> On 15 maj 2014, at 03:48, David Holmes wrote: >> >>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>> David, Vitaly, >>>> >>>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>>> and code in shmemBase.c (the usage of enterMutex() function for >>>> sending/receiving bytes through shared memory connection) illustrates on >>>> how the connection shutdown event is used as a "cancellation token". >>> Thanks for clarifying that. >>> >>> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >>> >>> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >>> >>> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >>> >>> 204 /* If the mutex is abandoned we want to return an error >>> 205 * and also release the mutex so that we don't cause >>> 206 * other threads to be blocked. If a mutex was abandoned >>> 207 * we are in scary state. Data may be corrupted or inconsistent >>> 208 * but it is still better to let other threads run (and possibly >>> 209 * crash) than having them blocked (on the premise that a crash >>> 210 * is always easier to debug than a hang). >>> >>> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >>> >>> But I'll let the serviceability folk chime in here. >> I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) >> >> I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. >> >> /Staffan >> >> >>> Thanks, >>> David >>> >>> >>>> Thank you, >>>> -Aleksej >>>> >>>> >>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>>> functions, one of them employed in the code in question. If >>>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>>> current thread has ownership now. >>>>> Yes I understand the basic mechanics :) >>>>> >>>>>> It's also common to use multi wait functions where the event is a >>>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>>> wanted to throw this out there in the meantime :). >>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>> > wrote: >>>>>> >>>>>> Hi Aleksej, >>>>>> >>>>>> Thanks for the doc references regarding abandonment. >>>>>> >>>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>>> when this function is called? >>>>>> >>>>>> David >>>>>> >>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> The Windows has a different terminology for mutex objects (much >>>>>> differs >>>>>> from the POSIX one). This one link gave me some understanding of >>>>>> it [1]. >>>>>> >>>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>>> " If a thread terminates without releasing its ownership of a >>>>>> mutex >>>>>> object, the mutex object is considered to be abandoned. A >>>>>> waiting thread >>>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>>> object is >>>>>> abandoned. An abandoned mutex object indicates that an error has >>>>>> occurred and that any shared resource being protected by the >>>>>> mutex >>>>>> object is in an undefined state. If the thread proceeds as >>>>>> though the >>>>>> mutex object had not been abandoned, it is no longer considered >>>>>> abandoned after the thread releases its ownership. This restores >>>>>> normal >>>>>> behavior if a handle to the mutex object is subsequently >>>>>> specified in a >>>>>> wait function." >>>>>> >>>>>> >>>>>> What does it mean to wait on mutex and ownership of the mutex >>>>>> object: >>>>>> "Any thread with a handle to a mutex object can use one of >>>>>> thewait >>>>>> functions >>>>>> >>>>> >to >>>>>> request ownership of the mutex object. If the mutex object is >>>>>> owned by >>>>>> another thread, the wait function blocks the requesting thread >>>>>> until the >>>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>>> >>>>> >__function." >>>>>> >>>>>> How we can release mutex and wait on already owned mutex: >>>>>> " After a thread obtains ownership of a mutex, it can specify >>>>>> the same >>>>>> mutex in repeated calls to the wait-functions >>>>>> >>>>> >__without >>>>>> blocking its execution. This prevents a thread from deadlocking >>>>>> itself >>>>>> while waiting for a mutex that it already owns. To release its >>>>>> ownership >>>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>>> >>>>> >__once >>>>>> for each time that the mutex satisfied the conditions of a wait >>>>>> function." >>>>>> >>>>>> [1] >>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>> >>>>>> >>>>>> -Aleksej >>>>>> >>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>> >>>>>> I don't understand this one at all. What is an "abandoned >>>>>> mutex"? For >>>>>> that matter why does the code wait on a mutex and an event? >>>>>> Do we >>>>>> already own the mutex? If so what does it mean to wait on >>>>>> it? If not >>>>>> then how can we release it? >>>>>> >>>>>> ??? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> This is debugger's shared memory transport so cc'ing >>>>>> serviceability-dev >>>>>> as that is there this code is maintained. >>>>>> >>>>>> Is there a test case or any outline of the conditions >>>>>> that cause this? I >>>>>> think that would be useful to understand the issue >>>>>> further. >>>>>> >>>>>> -Alan >>>>>> >>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>>> There is a possible >>>>>> case when 'WaitForMultipleObjects' function can >>>>>> return the >>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>> In such case it's better to release the mutex and >>>>>> return error value. >>>>>> This will prevent other threads to be blocked on >>>>>> abandoned mutex. >>>>>> >>>>>> Thank you, >>>>>> Aleksej >>>>>> >>>>>> [1] >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>> >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>> >>>>>> [3] >>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > From david.holmes at oracle.com Wed Jun 4 09:46:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Jun 2014 19:46:53 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> Message-ID: <538EEB0D.1070704@oracle.com> Me too. Thanks, David On 4/06/2014 5:23 PM, Staffan Larsen wrote: > Looks ok to me. > > /Staffan > > On 3 jun 2014, at 15:49, Aleksej Efimov wrote: > >> Staffan, David, >> >> Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: >> Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). >> I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ >> To abort the process the 'exitTransportWithError' function was utilized. >> Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. >> >> Best Regards, >> Aleksej >> >> On 05/15/2014 01:11 PM, Staffan Larsen wrote: >>> On 15 maj 2014, at 03:48, David Holmes wrote: >>> >>>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>>> David, Vitaly, >>>>> >>>>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>>>> and code in shmemBase.c (the usage of enterMutex() function for >>>>> sending/receiving bytes through shared memory connection) illustrates on >>>>> how the connection shutdown event is used as a "cancellation token". >>>> Thanks for clarifying that. >>>> >>>> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >>>> >>>> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >>>> >>>> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >>>> >>>> 204 /* If the mutex is abandoned we want to return an error >>>> 205 * and also release the mutex so that we don't cause >>>> 206 * other threads to be blocked. If a mutex was abandoned >>>> 207 * we are in scary state. Data may be corrupted or inconsistent >>>> 208 * but it is still better to let other threads run (and possibly >>>> 209 * crash) than having them blocked (on the premise that a crash >>>> 210 * is always easier to debug than a hang). >>>> >>>> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >>>> >>>> But I'll let the serviceability folk chime in here. >>> I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) >>> >>> I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. >>> >>> /Staffan >>> >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thank you, >>>>> -Aleksej >>>>> >>>>> >>>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>>>> functions, one of them employed in the code in question. If >>>>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>>>> current thread has ownership now. >>>>>> Yes I understand the basic mechanics :) >>>>>> >>>>>>> It's also common to use multi wait functions where the event is a >>>>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>>>> wanted to throw this out there in the meantime :). >>>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>>> > wrote: >>>>>>> >>>>>>> Hi Aleksej, >>>>>>> >>>>>>> Thanks for the doc references regarding abandonment. >>>>>>> >>>>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>>>> when this function is called? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> The Windows has a different terminology for mutex objects (much >>>>>>> differs >>>>>>> from the POSIX one). This one link gave me some understanding of >>>>>>> it [1]. >>>>>>> >>>>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>>>> " If a thread terminates without releasing its ownership of a >>>>>>> mutex >>>>>>> object, the mutex object is considered to be abandoned. A >>>>>>> waiting thread >>>>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>>>> object is >>>>>>> abandoned. An abandoned mutex object indicates that an error has >>>>>>> occurred and that any shared resource being protected by the >>>>>>> mutex >>>>>>> object is in an undefined state. If the thread proceeds as >>>>>>> though the >>>>>>> mutex object had not been abandoned, it is no longer considered >>>>>>> abandoned after the thread releases its ownership. This restores >>>>>>> normal >>>>>>> behavior if a handle to the mutex object is subsequently >>>>>>> specified in a >>>>>>> wait function." >>>>>>> >>>>>>> >>>>>>> What does it mean to wait on mutex and ownership of the mutex >>>>>>> object: >>>>>>> "Any thread with a handle to a mutex object can use one of >>>>>>> thewait >>>>>>> functions >>>>>>> >>>>>> >to >>>>>>> request ownership of the mutex object. If the mutex object is >>>>>>> owned by >>>>>>> another thread, the wait function blocks the requesting thread >>>>>>> until the >>>>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>>>> >>>>>> >__function." >>>>>>> >>>>>>> How we can release mutex and wait on already owned mutex: >>>>>>> " After a thread obtains ownership of a mutex, it can specify >>>>>>> the same >>>>>>> mutex in repeated calls to the wait-functions >>>>>>> >>>>>> >__without >>>>>>> blocking its execution. This prevents a thread from deadlocking >>>>>>> itself >>>>>>> while waiting for a mutex that it already owns. To release its >>>>>>> ownership >>>>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>>>> >>>>>> >__once >>>>>>> for each time that the mutex satisfied the conditions of a wait >>>>>>> function." >>>>>>> >>>>>>> [1] >>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>>> >>>>>>> >>>>>>> -Aleksej >>>>>>> >>>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>>> >>>>>>> I don't understand this one at all. What is an "abandoned >>>>>>> mutex"? For >>>>>>> that matter why does the code wait on a mutex and an event? >>>>>>> Do we >>>>>>> already own the mutex? If so what does it mean to wait on >>>>>>> it? If not >>>>>>> then how can we release it? >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> This is debugger's shared memory transport so cc'ing >>>>>>> serviceability-dev >>>>>>> as that is there this code is maintained. >>>>>>> >>>>>>> Is there a test case or any outline of the conditions >>>>>>> that cause this? I >>>>>>> think that would be useful to understand the issue >>>>>>> further. >>>>>>> >>>>>>> -Alan >>>>>>> >>>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>>>> There is a possible >>>>>>> case when 'WaitForMultipleObjects' function can >>>>>>> return the >>>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>>> In such case it's better to release the mutex and >>>>>>> return error value. >>>>>>> This will prevent other threads to be blocked on >>>>>>> abandoned mutex. >>>>>>> >>>>>>> Thank you, >>>>>>> Aleksej >>>>>>> >>>>>>> [1] >>>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>>> >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>>> >>>>>>> [3] >>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> > From david.holmes at oracle.com Wed Jun 4 09:55:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Jun 2014 19:55:28 +1000 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: References: <538E74B8.20603@oracle.com> <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com> Message-ID: <538EED10.5030805@oracle.com> On 4/06/2014 1:38 PM, Paul Benedict wrote: > I like seeing "JDK" as well... primarily because IDEs have the ability to > show javadoc snippets when hovering over an element. It's good to see what > product the version comes relates to. > > Yet, on the other hand, these Oracle APIs are not published under "JDK" > branding but under the title "Java SE". Shouldn't that be used instead? The "naming documents" eg: http://www.oracle.com/technetwork/java/javase/jdk7-naming-418744.html indicate using the version string on @since tags ie 1.7, 1.8 David > > Cheers, > Paul > > > On Tue, Jun 3, 2014 at 10:17 PM, Mike Duigou wrote: > >> You will need to include awt-dev and security-dev since this patch touches >> those areas as well. Other impacted groups I missed? >> >> I would like to see this all go back in one changeset to dev repo though >> as it would be a lot cleaner that way. >> >> I am concerned a bit that if we retain standard names for non-jdk >> standards it may be sometimes confusing or lacking in context to see a raw >> version number. Consistency is trumps all, but I would prefer to see >> JDK#.#[.#] used to be unambiguous. >> >> I don't see any missteps in the changeset but wouldn't want mine to be the >> only review. >> >> Mike >> >> On Jun 3 2014, at 18:22 , Henry Jen wrote: >> >>> Hi, >>> >>> In an effort to determine APIs availability in a given version, it >> became obvious that a consistent way to express @since tag would be >> beneficial. >>> >>> So started with the most obvious ones, where we have various expression >> for JDK version, this webrev make sure we use @since 1.n[.n] for JDK >> versions. >>> >>> The main focus is on public APIs, private ones are taken care if it is >> straightforward, otherwise, we try to keep the information. >>> >>> Some public APIs are using @since format, >> they are also preserved for now, but I think it worth discussion whether we >> want to change to the version as included in J2SE. >>> >>> There are APIs without @since information, separate webrevs will be >> coming to complete those information. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 >>> The webrev can be found at >>> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev >>> >>> but it's probably easier just look into the raw diff, >>> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset >>> >>> Cheers, >>> Henry >> >> From paul.sandoz at oracle.com Wed Jun 4 10:25:29 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Jun 2014 12:25:29 +0200 Subject: RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type In-Reply-To: References: Message-ID: <10DED4CF-1440-48B9-842F-45E67A8107E0@oracle.com> On Jun 3, 2014, at 1:48 PM, Joel Borggr?n-Franck wrote: > Hi > > Can I get a review for this small fix for https://bugs.openjdk.java.net/browse/JDK-8039916 > > Webrev here: http://cr.openjdk.java.net/~jfranck/8039916/webrev.01/ > > Since this is the second issue like this found recently I created a rather large test to see if there are any more lurking issues. I found one more, see: https://bugs.openjdk.java.net/browse/JDK-8044629 .I need to figure out what the right behavior for the new issue, is so I need to delay that fix. > Looks good. You might consider the following a more streamy way, not tested! up to you :-) private static Object[][] provider() { Stream s = filterData(Test.class.getMethods(), null); s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); return streamToArray(s); } private static Stream filterData(Executable[] es, Class c) { return Stream.of(es).filter(m -> m.getDeclaringClass() == c); } private static Object[][] streamToArray(Stream s) { return s.map(e -> Stream.of(e).toArray()).toArray(Object[][]::new); } Paul. From paul.sandoz at oracle.com Wed Jun 4 10:34:56 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Jun 2014 12:34:56 +0200 Subject: RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type In-Reply-To: <10DED4CF-1440-48B9-842F-45E67A8107E0@oracle.com> References: <10DED4CF-1440-48B9-842F-45E67A8107E0@oracle.com> Message-ID: On Jun 4, 2014, at 12:25 PM, Paul Sandoz wrote: > > You might consider the following a more streamy way, not tested! up to you :-) > > private static Object[][] provider() { > Stream s = filterData(Test.class.getMethods(), null); > s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); > s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); > return streamToArray(s); > } > > private static Stream filterData(Executable[] es, Class c) { > return Stream.of(es).filter(m -> m.getDeclaringClass() == c); > } Plus you can drop the "? extends" bit of "? extends Executable", that was a hangover from some other mini experiment. Paul. From aleksej.efimov at oracle.com Wed Jun 4 11:43:05 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 04 Jun 2014 15:43:05 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <538EEB0D.1070704@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> <538EEB0D.1070704@oracle.com> Message-ID: <538F0649.5000706@oracle.com> Thank you David. Thank you Staffan. On 06/04/2014 01:46 PM, David Holmes wrote: > Me too. > > Thanks, > David > > On 4/06/2014 5:23 PM, Staffan Larsen wrote: >> Looks ok to me. >> >> /Staffan >> >> On 3 jun 2014, at 15:49, Aleksej Efimov >> wrote: >> >>> Staffan, David, >>> >>> Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED >>> discussions: >>> Thank you for your comments and remarks. I can't disagree with >>> motivation that it's better to have a fatal error during the >>> incorrect mutex handling then data corruption (the consequence of >>> the previous fix). In case of such error it'll be much more easier >>> to debug/catch it (but as Staffan said - we have tried to check all >>> call paths and don't think that we'll encounter such behavior). >>> I have modified the discussed code according to your suggestions: >>> http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ >>> To abort the process the 'exitTransportWithError' function was >>> utilized. >>> Also I have tried to check that behavior isn't changed by running >>> "svc" regression tests set. There was no related test failures >>> observed. >>> >>> Best Regards, >>> Aleksej >>> >>> On 05/15/2014 01:11 PM, Staffan Larsen wrote: >>>> On 15 maj 2014, at 03:48, David Holmes >>>> wrote: >>>> >>>>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>>>> David, Vitaly, >>>>>> >>>>>> I totally agree with Vitaly's explanation (Vitaly - thank you for >>>>>> that) >>>>>> and code in shmemBase.c (the usage of enterMutex() function for >>>>>> sending/receiving bytes through shared memory connection) >>>>>> illustrates on >>>>>> how the connection shutdown event is used as a "cancellation token". >>>>> Thanks for clarifying that. >>>>> >>>>> So if we were to encounter an abandoned mutex the code would >>>>> presently have acquired the mutex but return an error, thus >>>>> preventing a subsequent release, and preventing other threads from >>>>> acquiring (but allowing current thread to recurisevely acquire. So >>>>> this could both hang and cause data corruption. >>>>> >>>>> The new code will still return an error but release the mutex. So >>>>> no more hangs (other than by conditions caused by data corruption) >>>>> but more opportunity for data corruption. >>>>> >>>>> Obviously it depends on exactly what happens in the critical >>>>> sections guarded by this mutex, but in general I don't agree with >>>>> this rationale for making the change: >>>>> >>>>> 204 /* If the mutex is abandoned we want to return an error >>>>> 205 * and also release the mutex so that we don't cause >>>>> 206 * other threads to be blocked. If a mutex was abandoned >>>>> 207 * we are in scary state. Data may be corrupted or >>>>> inconsistent >>>>> 208 * but it is still better to let other threads run (and >>>>> possibly >>>>> 209 * crash) than having them blocked (on the premise that a >>>>> crash >>>>> 210 * is always easier to debug than a hang). >>>>> >>>>> Considering something has to have gone drastically wrong for the >>>>> mutex to become abandoned, I'm more inclined to consider this a >>>>> fatal error and abort. >>>>> >>>>> But I'll let the serviceability folk chime in here. >>>> I was involved in fixing this and writing the comment, so obviously >>>> I thought it a good solution :-) >>>> >>>> I do agree that it would probably be a good idea to consider this a >>>> fatal error and abort. At that point in the code we don?t have any >>>> really nice ways of doing that, though. We could just print an >>>> error and call abort(). What we are doing now is returning an error >>>> from sysIPMutexEnter() and delegating the error handling to the >>>> caller. We have tried to check all call paths to verify that they >>>> do ?the right thing? in the face of an error. It is obviously hard >>>> to verify, but it looks like they all terminate the connection with >>>> some kind of error message. >>>> >>>> /Staffan >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Thank you, >>>>>> -Aleksej >>>>>> >>>>>> >>>>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>>>> In windows, you acquire a mutex by waiting on it using one of >>>>>>>> the wait >>>>>>>> functions, one of them employed in the code in question. If >>>>>>>> WaitForMultipleObjects succeeds and returns the index of the >>>>>>>> mutex, >>>>>>>> current thread has ownership now. >>>>>>> Yes I understand the basic mechanics :) >>>>>>> >>>>>>>> It's also common to use multi wait functions where the event is a >>>>>>>> "cancelation token", e.g. manual reset event; this allows >>>>>>>> someone to >>>>>>>> cancel waiting on mutex acquisition and return from the wait >>>>>>>> function. >>>>>>>> Presumably that's the case here, but I'll let Aleksej confirm; >>>>>>>> just >>>>>>>> wanted to throw this out there in the meantime :). >>>>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Sent from my phone >>>>>>>> >>>>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Aleksej, >>>>>>>> >>>>>>>> Thanks for the doc references regarding abandonment. >>>>>>>> >>>>>>>> Let me rephrase my question. What is this logic trying to >>>>>>>> achieve by >>>>>>>> waiting on both a mutex and an event? Do we already own the >>>>>>>> mutex >>>>>>>> when this function is called? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> The Windows has a different terminology for mutex >>>>>>>> objects (much >>>>>>>> differs >>>>>>>> from the POSIX one). This one link gave me some >>>>>>>> understanding of >>>>>>>> it [1]. >>>>>>>> >>>>>>>> Here is the MSDN [1] description of what "abandoned >>>>>>>> mutex" is: >>>>>>>> " If a thread terminates without releasing its >>>>>>>> ownership of a >>>>>>>> mutex >>>>>>>> object, the mutex object is considered to be abandoned. A >>>>>>>> waiting thread >>>>>>>> can acquire ownership of an abandoned mutex object, but >>>>>>>> the wait >>>>>>>> function will return*WAIT_ABANDONED*to indicate that >>>>>>>> the mutex >>>>>>>> object is >>>>>>>> abandoned. An abandoned mutex object indicates that an >>>>>>>> error has >>>>>>>> occurred and that any shared resource being protected >>>>>>>> by the >>>>>>>> mutex >>>>>>>> object is in an undefined state. If the thread proceeds as >>>>>>>> though the >>>>>>>> mutex object had not been abandoned, it is no longer >>>>>>>> considered >>>>>>>> abandoned after the thread releases its ownership. This >>>>>>>> restores >>>>>>>> normal >>>>>>>> behavior if a handle to the mutex object is subsequently >>>>>>>> specified in a >>>>>>>> wait function." >>>>>>>> >>>>>>>> >>>>>>>> What does it mean to wait on mutex and ownership of the >>>>>>>> mutex >>>>>>>> object: >>>>>>>> "Any thread with a handle to a mutex object can use one of >>>>>>>> thewait >>>>>>>> functions >>>>>>>> >>>>>>> >>>>>>>> >to >>>>>>>> >>>>>>>> request ownership of the mutex object. If the mutex >>>>>>>> object is >>>>>>>> owned by >>>>>>>> another thread, the wait function blocks the requesting >>>>>>>> thread >>>>>>>> until the >>>>>>>> owning thread releases the mutex object using >>>>>>>> the*ReleaseMutex* >>>>>>>> >>>>>>> >>>>>>>> >__function." >>>>>>>> >>>>>>>> >>>>>>>> How we can release mutex and wait on already owned mutex: >>>>>>>> " After a thread obtains ownership of a mutex, it can >>>>>>>> specify >>>>>>>> the same >>>>>>>> mutex in repeated calls to the wait-functions >>>>>>>> >>>>>>> >>>>>>>> >__without >>>>>>>> >>>>>>>> blocking its execution. This prevents a thread from >>>>>>>> deadlocking >>>>>>>> itself >>>>>>>> while waiting for a mutex that it already owns. To >>>>>>>> release its >>>>>>>> ownership >>>>>>>> under such circumstances, the thread must >>>>>>>> call*ReleaseMutex* >>>>>>>> >>>>>>> >>>>>>>> >__once >>>>>>>> >>>>>>>> for each time that the mutex satisfied the conditions >>>>>>>> of a wait >>>>>>>> function." >>>>>>>> >>>>>>>> [1] >>>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Aleksej >>>>>>>> >>>>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>>>> >>>>>>>> I don't understand this one at all. What is an >>>>>>>> "abandoned >>>>>>>> mutex"? For >>>>>>>> that matter why does the code wait on a mutex and >>>>>>>> an event? >>>>>>>> Do we >>>>>>>> already own the mutex? If so what does it mean to >>>>>>>> wait on >>>>>>>> it? If not >>>>>>>> then how can we release it? >>>>>>>> >>>>>>>> ??? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> This is debugger's shared memory transport so >>>>>>>> cc'ing >>>>>>>> serviceability-dev >>>>>>>> as that is there this code is maintained. >>>>>>>> >>>>>>>> Is there a test case or any outline of the >>>>>>>> conditions >>>>>>>> that cause this? I >>>>>>>> think that would be useful to understand the issue >>>>>>>> further. >>>>>>>> >>>>>>>> -Alan >>>>>>>> >>>>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Can I have a review for 8032901 bug [1] fix >>>>>>>> [2]. >>>>>>>> There is a possible >>>>>>>> case when 'WaitForMultipleObjects' function >>>>>>>> can >>>>>>>> return the >>>>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>>>> In such case it's better to release the >>>>>>>> mutex and >>>>>>>> return error value. >>>>>>>> This will prevent other threads to be >>>>>>>> blocked on >>>>>>>> abandoned mutex. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Aleksej >>>>>>>> >>>>>>>> [1] >>>>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>>>> >>>>>>>> [2] >>>>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>>>> >>>>>>>> [3] >>>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >> From Lance.Andersen at oracle.com Wed Jun 4 12:06:26 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 4 Jun 2014 08:06:26 -0400 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: Hi Henry, I know you already have some feedback on the change. The RowSet Impl changes are fine Best Lance On Jun 3, 2014, at 9:22 PM, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. > > So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions. > > The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry 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 Wed Jun 4 13:03:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Jun 2014 14:03:00 +0100 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <538F1904.6060807@oracle.com> On 04/06/2014 02:22, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > So started with the most obvious ones, where we have various > expression for JDK version, this webrev make sure we use @since > 1.n[.n] for JDK versions. > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since > format, they are also preserved for now, but I think it worth > discussion whether we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > I skimmed through the patch and it looks okay to me. It's good to get consistency as it was always odd to have a mix of JDK1.x vs. 1.x in the javadoc. From what I can tell, there was a mix of JDK1.x vs. 1.x in the early releases but it's much more consistent in the last few major releases (there are no JDK1.6 or JDK1.7 to replace for example, and the only "JDK1.8" are in the JSR-310 classes). I see you've changed a number of implementation classes, I guess they aren't too interesting as the javadoc is typically not generated/published for those. One thing that isn't clear is the changes to several package.html files where the change is not obvious. Are these just white spaces? Maybe a side effect of a script? I see Phil has asked that this be split up for jdk9/dev and jdk9/client but it hardly seems worth it for this patch. It might be simpler to just push and then sync up jdk9/client. -Alan. From sean.mullan at oracle.com Wed Jun 4 13:14:13 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 04 Jun 2014 09:14:13 -0400 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <538F1BA5.3040107@oracle.com> The security specific files look fine to me. --Sean On 06/03/2014 09:22 PM, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > So started with the most obvious ones, where we have various expression > for JDK version, this webrev make sure we use @since 1.n[.n] for JDK > versions. > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, > they are also preserved for now, but I think it worth discussion whether > we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry From Alan.Bateman at oracle.com Wed Jun 4 13:16:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Jun 2014 14:16:11 +0100 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: Message-ID: <538F1C1B.3040702@oracle.com> On 04/06/2014 07:31, Jonathan Lu wrote: > Hi Volker, > > Thanks for your comment! an updated webrev was made at > http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/ > Would it make sense to set errno to sockopt_arg for the case that getsockopt(SO_ERROR) returns an error? Otherwise it looks okay to me. -Alan. From joel.franck at oracle.com Wed Jun 4 14:22:56 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 4 Jun 2014 16:22:56 +0200 Subject: RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type In-Reply-To: References: <10DED4CF-1440-48B9-842F-45E67A8107E0@oracle.com> Message-ID: <7C8AE289-3C71-4B42-8177-BFA6C3DF82A6@oracle.com> Thanks for the review Paul! I pushed the original, but I?ll experiment with your suggestion for the next set of tests. cheers /Joel On 4 jun 2014, at 12:34, Paul Sandoz wrote: > On Jun 4, 2014, at 12:25 PM, Paul Sandoz wrote: >> >> You might consider the following a more streamy way, not tested! up to you :-) >> >> private static Object[][] provider() { >> Stream s = filterData(Test.class.getMethods(), null); >> s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); >> s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); >> return streamToArray(s); >> } >> >> private static Stream filterData(Executable[] es, Class c) { >> return Stream.of(es).filter(m -> m.getDeclaringClass() == c); >> } > > Plus you can drop the "? extends" bit of "? extends Executable", that was a hangover from some other mini experiment. > > Paul. > > From forax at univ-mlv.fr Wed Jun 4 15:06:48 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 04 Jun 2014 17:06:48 +0200 Subject: RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type In-Reply-To: References: <10DED4CF-1440-48B9-842F-45E67A8107E0@oracle.com> Message-ID: <538F3608.2000907@univ-mlv.fr> On 06/04/2014 12:34 PM, Paul Sandoz wrote: > On Jun 4, 2014, at 12:25 PM, Paul Sandoz wrote: >> You might consider the following a more streamy way, not tested! up to you :-) >> >> private static Object[][] provider() { >> Stream s = filterData(Test.class.getMethods(), null); >> s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); >> s = Stream.concat(s, filterData(Test.class.getConstructors(), null)); >> return streamToArray(s); >> } >> >> private static Stream filterData(Executable[] es, Class c) { >> return Stream.of(es).filter(m -> m.getDeclaringClass() == c); >> } > Plus you can drop the "? extends" bit of "? extends Executable", that was a hangover from some other mini experiment. returning a Foo is usually a design error (apart from covariant return type in case of overriding but usually it's because the API was designed before the introduction of generics), because all client codes will have to declare a Foo. Here, it's better to introduce a type variable private static Stream filterData(E[] es, Class c) { return Stream.of(es).filter(m -> m.getDeclaringClass() == c); } > > Paul. > > regards, R?mi From vladimir.x.ivanov at oracle.com Wed Jun 4 15:25:28 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 04 Jun 2014 19:25:28 +0400 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method Message-ID: <538F3A68.3010905@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8032400 http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/ Consider the following hierarchy: class T1 { int m() { return 1; }} class T2 extends T1 { static int m() { return 2; }} class T3 extends T2 { int m() { return 3; }} T3 has a method, which does the following using method handles: T3::test { invokespecial T1.m() T3 } T1.m lookup attempt from T3 ends up as T2.m lookup, but it fails since T2 has static method with the same signature. Lookup.getDirectMethodCommon doesn't expect such failure and throws InternalError. JVMS specification states the following: // JVMS 6.5: invokespecial // ... 2. Otherwise, if C is a class and has a superclass, a search // for a declaration of an instance method with the same name and // descriptor as the resolved method is performed, starting with the // direct superclass of C and continuing with the direct superclass // of that class, and so forth, until a match is found or no further // superclasses exist. If a match is found, then it is the method to // be invoked. The fix is to comply with the spec and search upper in the class hierarchy if lookup attempt fails. Testing: regression test, jdk/test/java/lang/invoke, tests on access checks. Thanks! Best regards, Vladimir Ivanov From henry.jen at oracle.com Wed Jun 4 17:52:08 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 04 Jun 2014 10:52:08 -0700 Subject: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo In-Reply-To: <538E74B8.20603@oracle.com> References: <538E74B8.20603@oracle.com> Message-ID: <538F5CC8.3050702@oracle.com> Thanks for all reviewing and feedbacks on core-libs-dev[1], I tried to respond to feedbacks with this email and send off to other mailing lists. I am wondering if jdk9-dev is the appropriate list for such a trivious but broad change, so that we can have one instead of many lists, and we still probably miss another. Lets follow up this thread on jdk9-dev. Regarding to whether we should keep JDK, the later convention is 1.#, and as David pointed out the document also list @since that way, I think we should settle on that. For other standards such as SAX or JCE, I propose to convert them to the version of JDK those APIs are included. To retain that information, we can introduce a custom tag, perhaps @standard or @conformingTo? @conformingTo [, ]* For example, @conformingTo SAX 2.0. Repo wise, I think it's best if I can commit to jdk9/dev as a single commit instead of scattering to dev and client. But I can cope if this is absolutely necessary. Some changes to implementation classes, as I mentioned, only when it is straightforward. Essentially, I did a s/(@since *)JDK(.*)/\1\2 against all files. Some changes not obvious are simply remove tailing space, a (positive) side effect of the tools I use so I kept them. Cheers, Henry [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027113.html On 06/03/2014 06:22 PM, Henry Jen wrote: > Hi, > > In an effort to determine APIs availability in a given version, it > became obvious that a consistent way to express @since tag would be > beneficial. > > So started with the most obvious ones, where we have various expression > for JDK version, this webrev make sure we use @since 1.n[.n] for JDK > versions. > > The main focus is on public APIs, private ones are taken care if it is > straightforward, otherwise, we try to keep the information. > > Some public APIs are using @since format, > they are also preserved for now, but I think it worth discussion whether > we want to change to the version as included in J2SE. > > There are APIs without @since information, separate webrevs will be > coming to complete those information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 > The webrev can be found at > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev > > but it's probably easier just look into the raw diff, > http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset > > Cheers, > Henry From david.x.li at oracle.com Wed Jun 4 18:35:09 2014 From: david.x.li at oracle.com (David Li) Date: Wed, 04 Jun 2014 11:35:09 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan Message-ID: <538F66DD.1050905@oracle.com> Hi, This is an update to JAXP serialization from Apache Xalan. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8041523. Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ Summary of changes. * Changes from the Apache bug referenced in JDK-8041523 * Update ToStream.setCdataSectionElements to a newer version from the most recent Apache ToStream.java source file. This was causing the JCK test failures noted in the bug. Note, there are two setCdataSectionElement methods in ToStream.java. The one with the bug has been fixed. * Some updates to accommodate ArrayList, HashMap, and Generics. * Bundled in changes for JDK-8037259. This was an xpointer bug. Existing tests: JAXP SQE and unit tests passed. JCK tests passed. Thanks, David From xueming.shen at oracle.com Wed Jun 4 19:30:30 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 04 Jun 2014 12:30:30 -0700 Subject: RFR: JDK-8044727: Problem reading the contents of some zip files Message-ID: <538F73D6.2040702@oracle.com> Hi, Please help review issue: https://bugs.openjdk.java.net/browse/JDK-8044727 webrev: http://cr.openjdk.java.net/~sherman/8044727/webrev/ cause: Regression caused by the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f [http://cr.openjdk.java.net/~sherman/6303183/webrev] in which the new implementation of ZipInoutStream.writeLOC() incorrectly tries to always interpret the ZIP64 extra data, if it "exists", even the size/csize fields of the entry have "normal' size data. The original implementation only does the check (and then setting), if at least one of the sizes (entry size and compressed size) has the "zip64 magic value" (this is what the zip64 spec says/requests the implementation to do). Those "offending" zip files obviously have the extra data with ZIP64 tag (0x0001), but the entry size/csize are "normal"/non-zip64-value. The change is to back to the correct implementation, only check and set the ZIP64 size(s) if the sizes in the zip entry size fields are "zip64 magic value". I'm not adding a regression test, as it will force to check in another "binary" zip file into the repository (the ZipOutputStream does not output a "bogus" extra data with ZIP64 tag, if the sizes do not requires a ZIP64 extra data). I've manually verify the fix against the test case attached in the bug report. Thanks! -Sherman From martinrb at google.com Wed Jun 4 19:25:58 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Jun 2014 12:25:58 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538EBC93.4080409@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> Message-ID: Tests for Timer are inherently timing (!) dependent. It's reasonable for tests to assume that: - reasonable events like creating a thread and executing a simple task should complete in less than, say 2500ms. - system clock will not change by a significant amount (> 1 sec) during the test. Yes, that means Timer tests are likely to fail during daylight saving time switchover - we can live with that. (we could even try to fix that, by detecting deviations between clock time and elapsed time, but probably not worth it) Can you detect any real-world unreliability in my latest version of the test, not counting daylight saving time switch? I continue to resist your efforts to "fix" the test by removing chances for the SUT code to go wrong. On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang wrote: > Hi Martin, > > Thanks for explanation, now I can understand why you set the DELAY_MS to > 100 seconds, it is true that it prevents failure on a slow host, however, i > still have some concerns. > Because the test tests to schedule tasks at the time in the past, so all > 13 tasks should be executed immediately and finished within a short time. > If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that the > timer have plenty of time to finish tasks, so whether it causes above test > point lost. > > Back to the original test, i think it should be a test stabilization > issue, because the original test assumes that the timer should be cancelled > within < 1 second before the 14th task is called. this assumption may not > be guaranteed due to 2 reasons: > 1. if test is executed in jtreg concurrent mode on a slow host. > 2. the system clock of virtual machine may not be accurate (maybe faster > than physical). > > To support the point, i changed the test as attached to print the > execution time to see whether the timer behaves expected as the API > document described. the result is as expected. > > The unrepeated task executed immediately: [1401855509336] > The repeated task executed immediately and repeated per 1 second: > [1401855509337, 1401855510337, 1401855511338] > The fixed-rate task executed immediately and catch up the delay: > [1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, > 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, > 1401855509338, 1401855509836, 1401855510836] > > > Thanks, > Eric > On 2014/6/4 9:16, Martin Buchholz wrote: > > > > > On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang wrote: > >> Hi Martin, >> >> To sleep(1000) is not enough to reproduce the failure, because it is much >> lower than the period DELAY_MS (10*1000) of the repeated task created by >> "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". >> >> Try sleep(DELAY_MS), the failure can be reproduced. >> > > Well sure, then the task is rescheduled, so I expect it to fail in this > case. > > But in my version I had set DELAY_MS to 100 seconds. The point of > extending the DELAY_MS is to prevent flaky failure on a slow machine. > > Again, how do we know that this test hasn't found a Timer bug? > > I still can't reproduce it. > > > From huizhe.wang at oracle.com Wed Jun 4 19:27:49 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 04 Jun 2014 12:27:49 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan In-Reply-To: <538F66DD.1050905@oracle.com> References: <538F66DD.1050905@oracle.com> Message-ID: <538F7335.1080309@oracle.com> Hi David, Good work! This is a major patch in Xalan, one last in Xalan 2.7.1. Previously, it caused many failures in JCK and SQE regression tests. I see that you've resolved those failures with the fix stated below, and getting all tests to pass. Some minor cleanup may be desirable, such as: - the unused AbstractTranslet: import java.util.Vector - comments in EmptySerializer and ToSAXHandler: SerializationHandler#setCdataSectionElements(java.util.Vector) - comment in the new method initCdataElems in SerializerBase that "we just ended a URI, add the URI to the vector" although it didn't. - comments in ToStream about setCdataSectionElements(Vector v) Thanks, Joe On 6/4/2014 11:35 AM, David Li wrote: > Hi, > > This is an update to JAXP serialization from Apache Xalan. For > details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8041523. > > Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ > > Summary of changes. > * Changes from the Apache bug referenced in JDK-8041523 > * Update ToStream.setCdataSectionElements to a newer version from the > most recent Apache ToStream.java source file. This was causing the > JCK test failures noted in the bug. Note, there are two > setCdataSectionElement methods in ToStream.java. The one with the bug > has been fixed. > * Some updates to accommodate ArrayList, HashMap, and Generics. > * Bundled in changes for JDK-8037259. This was an xpointer bug. > > Existing tests: JAXP SQE and unit tests passed. JCK tests passed. > > Thanks, > David From Alan.Bateman at oracle.com Wed Jun 4 20:10:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Jun 2014 21:10:51 +0100 Subject: RFR: JDK-8044727: Problem reading the contents of some zip files In-Reply-To: <538F73D6.2040702@oracle.com> References: <538F73D6.2040702@oracle.com> Message-ID: <538F7D4B.9050101@oracle.com> On 04/06/2014 20:30, Xueming Shen wrote: > Hi, > > Please help review > > issue: > https://bugs.openjdk.java.net/browse/JDK-8044727 > > webrev: > http://cr.openjdk.java.net/~sherman/8044727/webrev/ This case was easy to miss, the change looks good. -Alan From roger.riggs at oracle.com Wed Jun 4 20:23:43 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 04 Jun 2014 16:23:43 -0400 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> Message-ID: <538F804F.1070908@oracle.com> Hi Martin, Eric, Of several hundred failures of this test, most were done in a JRE run with -Xcomp set. A few failures occurred with -Xmixed, none with -Xint. The printed "elapsed" times (not normalized to hardware or OS) range from 24 to 132 (ms) with most falling into several buckets in the 30's, 40's, 50's and 70's. I don't spot anything in the Timer.mainLoop code that might break when highly optimized but that's one possibility. Roger On 6/4/2014 3:25 PM, Martin Buchholz wrote: > Tests for Timer are inherently timing (!) dependent. > It's reasonable for tests to assume that: > - reasonable events like creating a thread and executing a simple task > should complete in less than, say 2500ms. > - system clock will not change by a significant amount (> 1 sec) during the > test. Yes, that means Timer tests are likely to fail during daylight > saving time switchover - we can live with that. (we could even try to fix > that, by detecting deviations between clock time and elapsed time, but > probably not worth it) > > Can you detect any real-world unreliability in my latest version of the > test, not counting daylight saving time switch? > > I continue to resist your efforts to "fix" the test by removing chances for > the SUT code to go wrong. > > > On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang wrote: > >> Hi Martin, >> >> Thanks for explanation, now I can understand why you set the DELAY_MS to >> 100 seconds, it is true that it prevents failure on a slow host, however, i >> still have some concerns. >> Because the test tests to schedule tasks at the time in the past, so all >> 13 tasks should be executed immediately and finished within a short time. >> If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that the >> timer have plenty of time to finish tasks, so whether it causes above test >> point lost. >> >> Back to the original test, i think it should be a test stabilization >> issue, because the original test assumes that the timer should be cancelled >> within < 1 second before the 14th task is called. this assumption may not >> be guaranteed due to 2 reasons: >> 1. if test is executed in jtreg concurrent mode on a slow host. >> 2. the system clock of virtual machine may not be accurate (maybe faster >> than physical). >> >> To support the point, i changed the test as attached to print the >> execution time to see whether the timer behaves expected as the API >> document described. the result is as expected. >> >> The unrepeated task executed immediately: [1401855509336] >> The repeated task executed immediately and repeated per 1 second: >> [1401855509337, 1401855510337, 1401855511338] >> The fixed-rate task executed immediately and catch up the delay: >> [1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, >> 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, >> 1401855509338, 1401855509836, 1401855510836] >> >> >> Thanks, >> Eric >> On 2014/6/4 9:16, Martin Buchholz wrote: >> >> >> >> >> On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang wrote: >> >>> Hi Martin, >>> >>> To sleep(1000) is not enough to reproduce the failure, because it is much >>> lower than the period DELAY_MS (10*1000) of the repeated task created by >>> "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". >>> >>> Try sleep(DELAY_MS), the failure can be reproduced. >>> >> Well sure, then the task is rescheduled, so I expect it to fail in this >> case. >> >> But in my version I had set DELAY_MS to 100 seconds. The point of >> extending the DELAY_MS is to prevent flaky failure on a slow machine. >> >> Again, how do we know that this test hasn't found a Timer bug? >> >> I still can't reproduce it. >> >> >> From david.x.li at oracle.com Wed Jun 4 21:04:42 2014 From: david.x.li at oracle.com (David Li) Date: Wed, 04 Jun 2014 14:04:42 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan In-Reply-To: <538F7335.1080309@oracle.com> References: <538F66DD.1050905@oracle.com> <538F7335.1080309@oracle.com> Message-ID: <538F89EA.9010501@oracle.com> Hi Joe, I have applied these changes and uploaded for review. http://cr.openjdk.java.net/~dli/8041523/webrev/. Let me know if you see anything else. Thanks, David On 6/4/2014 12:27 PM, huizhe wang wrote: > Hi David, > > Good work! > > This is a major patch in Xalan, one last in Xalan 2.7.1. Previously, > it caused many failures in JCK and SQE regression tests. I see that > you've resolved those failures with the fix stated below, and getting > all tests to pass. > > Some minor cleanup may be desirable, such as: > - the unused AbstractTranslet: import java.util.Vector > - comments in EmptySerializer and ToSAXHandler: > SerializationHandler#setCdataSectionElements(java.util.Vector) > - comment in the new method initCdataElems in SerializerBase that "we > just ended a URI, add the URI to the vector" although it didn't. > - comments in ToStream about setCdataSectionElements(Vector v) > > Thanks, > Joe > > On 6/4/2014 11:35 AM, David Li wrote: >> Hi, >> >> This is an update to JAXP serialization from Apache Xalan. For >> details, please refer to: >> https://bugs.openjdk.java.net/browse/JDK-8041523. >> >> Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ >> >> Summary of changes. >> * Changes from the Apache bug referenced in JDK-8041523 >> * Update ToStream.setCdataSectionElements to a newer version from the >> most recent Apache ToStream.java source file. This was causing the >> JCK test failures noted in the bug. Note, there are two >> setCdataSectionElement methods in ToStream.java. The one with the >> bug has been fixed. >> * Some updates to accommodate ArrayList, HashMap, and Generics. >> * Bundled in changes for JDK-8037259. This was an xpointer bug. >> >> Existing tests: JAXP SQE and unit tests passed. JCK tests passed. >> >> Thanks, >> David > From huizhe.wang at oracle.com Wed Jun 4 21:26:20 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 04 Jun 2014 14:26:20 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan In-Reply-To: <538F89EA.9010501@oracle.com> References: <538F66DD.1050905@oracle.com> <538F7335.1080309@oracle.com> <538F89EA.9010501@oracle.com> Message-ID: <538F8EFC.2090204@oracle.com> The followings are still in the webrev: - the unused AbstractTranslet: import java.util.Vector can be removed - comments in EmptySerializer and ToSAXHandler: SerializationHandler#setCdataSectionElements(java.util.Vector) The issue is SerializationHandler does not define a method "setCdataSectionElements" -Joe On 6/4/2014 2:04 PM, David Li wrote: > Hi Joe, > > I have applied these changes and uploaded for review. > http://cr.openjdk.java.net/~dli/8041523/webrev/. Let me know if you > see anything else. > > Thanks, > David > > On 6/4/2014 12:27 PM, huizhe wang wrote: >> Hi David, >> >> Good work! >> >> This is a major patch in Xalan, one last in Xalan 2.7.1. Previously, >> it caused many failures in JCK and SQE regression tests. I see that >> you've resolved those failures with the fix stated below, and getting >> all tests to pass. >> >> Some minor cleanup may be desirable, such as: >> - the unused AbstractTranslet: import java.util.Vector >> - comments in EmptySerializer and ToSAXHandler: >> SerializationHandler#setCdataSectionElements(java.util.Vector) >> - comment in the new method initCdataElems in SerializerBase that >> "we just ended a URI, add the URI to the vector" although it didn't. >> - comments in ToStream about setCdataSectionElements(Vector v) >> >> Thanks, >> Joe >> >> On 6/4/2014 11:35 AM, David Li wrote: >>> Hi, >>> >>> This is an update to JAXP serialization from Apache Xalan. For >>> details, please refer to: >>> https://bugs.openjdk.java.net/browse/JDK-8041523. >>> >>> Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ >>> >>> Summary of changes. >>> * Changes from the Apache bug referenced in JDK-8041523 >>> * Update ToStream.setCdataSectionElements to a newer version from >>> the most recent Apache ToStream.java source file. This was causing >>> the JCK test failures noted in the bug. Note, there are two >>> setCdataSectionElement methods in ToStream.java. The one with the >>> bug has been fixed. >>> * Some updates to accommodate ArrayList, HashMap, and Generics. >>> * Bundled in changes for JDK-8037259. This was an xpointer bug. >>> >>> Existing tests: JAXP SQE and unit tests passed. JCK tests passed. >>> >>> Thanks, >>> David >> > From david.x.li at oracle.com Wed Jun 4 21:44:07 2014 From: david.x.li at oracle.com (David Li) Date: Wed, 04 Jun 2014 14:44:07 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan In-Reply-To: <538F8EFC.2090204@oracle.com> References: <538F66DD.1050905@oracle.com> <538F7335.1080309@oracle.com> <538F89EA.9010501@oracle.com> <538F8EFC.2090204@oracle.com> Message-ID: <538F9327.10801@oracle.com> I just checked and it is removed in my browser. I think you may need to clear your browser cache (or use a different browser). That's what I had to do before the changes would show up. -David On 6/4/2014 2:26 PM, huizhe wang wrote: > The followings are still in the webrev: > - the unused AbstractTranslet: import java.util.Vector > can be removed > > - comments in EmptySerializer and ToSAXHandler: > SerializationHandler#setCdataSectionElements(java.util.Vector) > The issue is SerializationHandler does not define a method > "setCdataSectionElements" > > -Joe > > On 6/4/2014 2:04 PM, David Li wrote: >> Hi Joe, >> >> I have applied these changes and uploaded for review. >> http://cr.openjdk.java.net/~dli/8041523/webrev/. Let me know if you >> see anything else. >> >> Thanks, >> David >> >> On 6/4/2014 12:27 PM, huizhe wang wrote: >>> Hi David, >>> >>> Good work! >>> >>> This is a major patch in Xalan, one last in Xalan 2.7.1. Previously, >>> it caused many failures in JCK and SQE regression tests. I see that >>> you've resolved those failures with the fix stated below, and >>> getting all tests to pass. >>> >>> Some minor cleanup may be desirable, such as: >>> - the unused AbstractTranslet: import java.util.Vector >>> - comments in EmptySerializer and ToSAXHandler: >>> SerializationHandler#setCdataSectionElements(java.util.Vector) >>> - comment in the new method initCdataElems in SerializerBase that >>> "we just ended a URI, add the URI to the vector" although it didn't. >>> - comments in ToStream about setCdataSectionElements(Vector v) >>> >>> Thanks, >>> Joe >>> >>> On 6/4/2014 11:35 AM, David Li wrote: >>>> Hi, >>>> >>>> This is an update to JAXP serialization from Apache Xalan. For >>>> details, please refer to: >>>> https://bugs.openjdk.java.net/browse/JDK-8041523. >>>> >>>> Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ >>>> >>>> Summary of changes. >>>> * Changes from the Apache bug referenced in JDK-8041523 >>>> * Update ToStream.setCdataSectionElements to a newer version from >>>> the most recent Apache ToStream.java source file. This was causing >>>> the JCK test failures noted in the bug. Note, there are two >>>> setCdataSectionElement methods in ToStream.java. The one with the >>>> bug has been fixed. >>>> * Some updates to accommodate ArrayList, HashMap, and Generics. >>>> * Bundled in changes for JDK-8037259. This was an xpointer bug. >>>> >>>> Existing tests: JAXP SQE and unit tests passed. JCK tests passed. >>>> >>>> Thanks, >>>> David >>> >> > From henry.jen at oracle.com Wed Jun 4 22:14:49 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 04 Jun 2014 15:14:49 -0700 Subject: RFR: 8044855: Add missing @since tag under java.beans.* Message-ID: <538F9A59.2000207@oracle.com> Hi, Please review a trivial webrev that provides missing @since tag for elements under java.beans, This version is determined based on javadoc of 1.0.2, 1.1.8 and 1.2.2. http://cr.openjdk.java.net/~henryjen/jdk9/8044855/0/webrev Cheers, Henry From philip.race at oracle.com Wed Jun 4 22:42:28 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 04 Jun 2014 15:42:28 -0700 Subject: RFR: 8044855: Add missing @since tag under java.beans.* In-Reply-To: <538F9A59.2000207@oracle.com> References: <538F9A59.2000207@oracle.com> Message-ID: <538FA0D4.4080007@oracle.com> Looks good to me based on what I think I know the history here. Sergey Malenkov should verify .. -phil. On 6/4/2014 3:14 PM, Henry Jen wrote: > Hi, > > Please review a trivial webrev that provides missing @since tag for > elements under java.beans, > > This version is determined based on javadoc of 1.0.2, 1.1.8 and 1.2.2. > > http://cr.openjdk.java.net/~henryjen/jdk9/8044855/0/webrev > > Cheers, > Henry From huizhe.wang at oracle.com Wed Jun 4 23:06:06 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 04 Jun 2014 16:06:06 -0700 Subject: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan In-Reply-To: <538F9327.10801@oracle.com> References: <538F66DD.1050905@oracle.com> <538F7335.1080309@oracle.com> <538F89EA.9010501@oracle.com> <538F8EFC.2090204@oracle.com> <538F9327.10801@oracle.com> Message-ID: <538FA65E.20309@oracle.com> Ok, Looks good. Thanks, Joe On 6/4/2014 2:44 PM, David Li wrote: > I just checked and it is removed in my browser. I think you may need > to clear your browser cache (or use a different browser). That's what > I had to do before the changes would show up. > > -David > > On 6/4/2014 2:26 PM, huizhe wang wrote: >> The followings are still in the webrev: >> - the unused AbstractTranslet: import java.util.Vector >> can be removed >> >> - comments in EmptySerializer and ToSAXHandler: >> SerializationHandler#setCdataSectionElements(java.util.Vector) >> The issue is SerializationHandler does not define a method >> "setCdataSectionElements" >> >> -Joe >> >> On 6/4/2014 2:04 PM, David Li wrote: >>> Hi Joe, >>> >>> I have applied these changes and uploaded for review. >>> http://cr.openjdk.java.net/~dli/8041523/webrev/. Let me know if you >>> see anything else. >>> >>> Thanks, >>> David >>> >>> On 6/4/2014 12:27 PM, huizhe wang wrote: >>>> Hi David, >>>> >>>> Good work! >>>> >>>> This is a major patch in Xalan, one last in Xalan 2.7.1. >>>> Previously, it caused many failures in JCK and SQE regression >>>> tests. I see that you've resolved those failures with the fix >>>> stated below, and getting all tests to pass. >>>> >>>> Some minor cleanup may be desirable, such as: >>>> - the unused AbstractTranslet: import java.util.Vector >>>> - comments in EmptySerializer and ToSAXHandler: >>>> SerializationHandler#setCdataSectionElements(java.util.Vector) >>>> - comment in the new method initCdataElems in SerializerBase that >>>> "we just ended a URI, add the URI to the vector" although it didn't. >>>> - comments in ToStream about setCdataSectionElements(Vector v) >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 6/4/2014 11:35 AM, David Li wrote: >>>>> Hi, >>>>> >>>>> This is an update to JAXP serialization from Apache Xalan. For >>>>> details, please refer to: >>>>> https://bugs.openjdk.java.net/browse/JDK-8041523. >>>>> >>>>> Webrevs: http://cr.openjdk.java.net/~dli/8041523/webrev/ >>>>> >>>>> Summary of changes. >>>>> * Changes from the Apache bug referenced in JDK-8041523 >>>>> * Update ToStream.setCdataSectionElements to a newer version from >>>>> the most recent Apache ToStream.java source file. This was >>>>> causing the JCK test failures noted in the bug. Note, there are >>>>> two setCdataSectionElement methods in ToStream.java. The one with >>>>> the bug has been fixed. >>>>> * Some updates to accommodate ArrayList, HashMap, and Generics. >>>>> * Bundled in changes for JDK-8037259. This was an xpointer bug. >>>>> >>>>> Existing tests: JAXP SQE and unit tests passed. JCK tests passed. >>>>> >>>>> Thanks, >>>>> David >>>> >>> >> > From paul.sandoz at oracle.com Thu Jun 5 08:07:32 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Jun 2014 10:07:32 +0200 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <538F3A68.3010905@oracle.com> References: <538F3A68.3010905@oracle.com> Message-ID: <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov wrote: > https://bugs.openjdk.java.net/browse/JDK-8032400 > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/ > > Consider the following hierarchy: > class T1 { int m() { return 1; }} > class T2 extends T1 { static int m() { return 2; }} > class T3 extends T2 { int m() { return 3; }} > > T3 has a method, which does the following using method handles: > T3::test { invokespecial T1.m() T3 } > > T1.m lookup attempt from T3 ends up as T2.m lookup, but it fails since T2 has static method with the same signature. Lookup.getDirectMethodCommon doesn't expect such failure and throws InternalError. > > JVMS specification states the following: > // JVMS 6.5: invokespecial > // ... 2. Otherwise, if C is a class and has a superclass, a search > // for a declaration of an instance method with the same name and > // descriptor as the resolved method is performed, starting with the > // direct superclass of C and continuing with the direct superclass > // of that class, and so forth, until a match is found or no further > // superclasses exist. If a match is found, then it is the method to > // be invoked. > > The fix is to comply with the spec and search upper in the class hierarchy if lookup attempt fails. > > Testing: regression test, jdk/test/java/lang/invoke, tests on access checks. > Looks ok. The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? Paul. From luchsh at linux.vnet.ibm.com Thu Jun 5 10:37:30 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 5 Jun 2014 18:37:30 +0800 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: <538F1C1B.3040702@oracle.com> References: <538F1C1B.3040702@oracle.com> Message-ID: Hi Alan, On Wed, Jun 4, 2014 at 9:16 PM, Alan Bateman wrote: > On 04/06/2014 07:31, Jonathan Lu wrote: > >> Hi Volker, >> >> Thanks for your comment! an updated webrev was made at >> http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/ >> >> Would it make sense to set errno to sockopt_arg for the case that > getsockopt(SO_ERROR) returns an error? Otherwise it looks okay to me. > If getsockopt(SO_ERROR) failed, I did not find any explicit docs about the behavior. but as I tested with some C code snippet, the value of sockopt_arg would not be changed if getsockopt(SO_ERROR) failed. So I prefer to keep the current approach, does it make sense to you ? > > -Alan. > Many thanks Jonathan From henry.jen at oracle.com Thu Jun 5 17:16:20 2014 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 05 Jun 2014 10:16:20 -0700 Subject: Approved: RFR: 8044855: Add missing @since tag under java.beans.* In-Reply-To: <53903B04.9030608@oracle.com> References: <538F9A59.2000207@oracle.com> <53903B04.9030608@oracle.com> Message-ID: <5390A5E4.5030804@oracle.com> Thanks Sergey and Phil for reviewing. I assume this can go into jdk9/dev although in JBS the category is client-libs? Cheers, Henry On 06/05/2014 02:40 AM, sergey malenkov wrote: > The fix looks good for me. > > Thanks, > SAM > > On 05.06.2014 2:14, Henry Jen wrote: >> Hi, >> >> Please review a trivial webrev that provides missing @since tag for >> elements under java.beans, >> >> This version is determined based on javadoc of 1.0.2, 1.1.8 and 1.2.2. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8044855/0/webrev >> >> Cheers, >> Henry > From philip.race at oracle.com Thu Jun 5 17:25:17 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 05 Jun 2014 10:25:17 -0700 Subject: Approved: RFR: 8044855: Add missing @since tag under java.beans.* In-Reply-To: <5390A5E4.5030804@oracle.com> References: <538F9A59.2000207@oracle.com> <53903B04.9030608@oracle.com> <5390A5E4.5030804@oracle.com> Message-ID: <5390A7FD.90808@oracle.com> I was expecting it to go to 9-client .. -phil. On 6/5/2014 10:16 AM, Henry Jen wrote: > Thanks Sergey and Phil for reviewing. I assume this can go into > jdk9/dev although in JBS the category is client-libs? > > Cheers, > Henry > > On 06/05/2014 02:40 AM, sergey malenkov wrote: >> The fix looks good for me. >> >> Thanks, >> SAM >> >> On 05.06.2014 2:14, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial webrev that provides missing @since tag for >>> elements under java.beans, >>> >>> This version is determined based on javadoc of 1.0.2, 1.1.8 and 1.2.2. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8044855/0/webrev >>> >>> Cheers, >>> Henry >> From Alan.Bateman at oracle.com Thu Jun 5 17:53:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Jun 2014 18:53:39 +0100 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: <538F1C1B.3040702@oracle.com> Message-ID: <5390AEA3.1000506@oracle.com> On 05/06/2014 11:37, Jonathan Lu wrote: > > If getsockopt(SO_ERROR) failed, I did not find any explicit docs > about the behavior. > but as I tested with some C code snippet, the value of sockopt_arg > would not be changed if getsockopt(SO_ERROR) failed. > So I prefer to keep the current approach, does it make sense to you ? The case that I was wondering about is the common case where getsockopt(SO_ERROR) succeeds and I was wondering if the code should actually be: if (sockopt_arg != 0 ) { errno = sockopt_arg; return -1; } That way the caller of NET_Connect will have errno set so that XXX_ThrowByNameWithLastError can create an appropriate exception message. -Alan. From andrej.golovnin at gmail.com Thu Jun 5 20:05:36 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 5 Jun 2014 22:05:36 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: <3FE96E2A-2B18-402A-B3A4-05EE9CB5FF08@gmail.com> Hi, any update? Best regards, Andrej Golovnin On 29.05.2014, at 09:35, Joel Borggr?n-Franck wrote: > Hi, > > We need you send in the patches via the mailing list. Please reply to your mail with the diffs attached directly (not zipped for example). > > I?ll might have time to look at this next week, but it surprises me you need to patch hotspot. Allocations before we have inflated shouldn?t be a problem. > > Also do you have any data showing that this actually makes a difference? > > cheers > /Joel > > On 28 maj 2014, at 23:44, Andrej Golovnin wrote: > >> Hi Joe, >> >> I have prepared a patch for the issue JDK-5043030. >> The patch consists of two parts: one for jdk and one for hotspot. >> You can find the webrevs here: >> >> JDK-patch: https://db.tt/7DYph0OH >> Hotspot-patch: https://db.tt/hHsN0yn4 >> >> The JDK-patch has two tests to verify the changes. >> >> Please review it and I hope you can sponsor it. >> >> Best regards, >> Andrej Golovnin >> > From vladimir.x.ivanov at oracle.com Thu Jun 5 22:25:17 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 06 Jun 2014 02:25:17 +0400 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> Message-ID: <5390EE4D.5020805@oracle.com> Thanks for review, Paul. > > Looks ok. > > The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) > > Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? Good point. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8032400/webrev.01/ Best regards, Vladimir Ivanov From john.r.rose at oracle.com Thu Jun 5 23:17:20 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 5 Jun 2014 16:17:20 -0700 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <5390EE4D.5020805@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> <5390EE4D.5020805@oracle.com> Message-ID: <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> Reviewed. This is not a requirement, but I would prefer (in general) to see less test logic in ASM-generated bytecode and more in Java. I am guessing that the invokeExact call could have been replaced by a simple weakly-typed invoke call in the framing code, and likewise with most of the other invokes (methodType, findSpecial) which are not caller-sensitive. ? John On Jun 5, 2014, at 3:25 PM, Vladimir Ivanov wrote: > Thanks for review, Paul. > >> >> Looks ok. >> >> The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) >> >> Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? > Good point. Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.01/ > > Best regards, > Vladimir Ivanov > _______________________________________________ > 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 Fri Jun 6 04:32:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Jun 2014 14:32:34 +1000 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> Message-ID: <53914462.6040101@oracle.com> On 5/06/2014 5:25 AM, Martin Buchholz wrote: > Tests for Timer are inherently timing (!) dependent. > It's reasonable for tests to assume that: > - reasonable events like creating a thread and executing a simple task > should complete in less than, say 2500ms. Not necessarily with the wrong combination of Xcomp, fastdebug and low-power/slow devices. :( > - system clock will not change by a significant amount (> 1 sec) during the > test. Yes, that means Timer tests are likely to fail during daylight > saving time switchover - we can live with that. (we could even try to fix > that, by detecting deviations between clock time and elapsed time, but > probably not worth it) Virtual environments have notoriously bad time keeping. > Can you detect any real-world unreliability in my latest version of the > test, not counting daylight saving time switch? > > I continue to resist your efforts to "fix" the test by removing chances for > the SUT code to go wrong. I haven't been tracking this one and although I just had a good look at the bug report and the patch I'm not getting a good handle on what is failing. Trying to write timing dependent tests that actually show that something took too long is very difficult given the range of test conditions that have to be accounted for. We've raised lots of timeouts when tests fail just to get them to stop failing. Rarely is consideration given as to whether the failure was reasonable ie that something really shouldn't have taken as long as it did. Unfortunately it's nearly impossible to answer this as we can't determine where the time actually went. David ----- > > On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang wrote: > >> Hi Martin, >> >> Thanks for explanation, now I can understand why you set the DELAY_MS to >> 100 seconds, it is true that it prevents failure on a slow host, however, i >> still have some concerns. >> Because the test tests to schedule tasks at the time in the past, so all >> 13 tasks should be executed immediately and finished within a short time. >> If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that the >> timer have plenty of time to finish tasks, so whether it causes above test >> point lost. >> >> Back to the original test, i think it should be a test stabilization >> issue, because the original test assumes that the timer should be cancelled >> within < 1 second before the 14th task is called. this assumption may not >> be guaranteed due to 2 reasons: >> 1. if test is executed in jtreg concurrent mode on a slow host. >> 2. the system clock of virtual machine may not be accurate (maybe faster >> than physical). >> >> To support the point, i changed the test as attached to print the >> execution time to see whether the timer behaves expected as the API >> document described. the result is as expected. >> >> The unrepeated task executed immediately: [1401855509336] >> The repeated task executed immediately and repeated per 1 second: >> [1401855509337, 1401855510337, 1401855511338] >> The fixed-rate task executed immediately and catch up the delay: >> [1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, >> 1401855509338, 1401855509338, 1401855509338, 1401855509338, 1401855509338, >> 1401855509338, 1401855509836, 1401855510836] >> >> >> Thanks, >> Eric >> On 2014/6/4 9:16, Martin Buchholz wrote: >> >> >> >> >> On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang wrote: >> >>> Hi Martin, >>> >>> To sleep(1000) is not enough to reproduce the failure, because it is much >>> lower than the period DELAY_MS (10*1000) of the repeated task created by >>> "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". >>> >>> Try sleep(DELAY_MS), the failure can be reproduced. >>> >> >> Well sure, then the task is rescheduled, so I expect it to fail in this >> case. >> >> But in my version I had set DELAY_MS to 100 seconds. The point of >> extending the DELAY_MS is to prevent flaky failure on a slow machine. >> >> Again, how do we know that this test hasn't found a Timer bug? >> >> I still can't reproduce it. >> >> >> From martinrb at google.com Fri Jun 6 04:46:44 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 5 Jun 2014 21:46:44 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538F804F.1070908@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> <538F804F.1070908@oracle.com> Message-ID: As with David, the cause of the failure is mystifying. How can things fail when we stay below the timeout value of 500ms? There's a bug either in Timer or my own understanding of what should be happening. Anyways, raising the timeout value (as I have done in my minor rewrite) seems prudent. Fortunately, we can write this test in a way that doesn't require actually waiting for the timeout to elapse. On Wed, Jun 4, 2014 at 1:23 PM, roger riggs wrote: > Hi Martin, Eric, > > Of several hundred failures of this test, most were done in a JRE run with > -Xcomp set. A few failures occurred with -Xmixed, none with -Xint. > > The printed "elapsed" times (not normalized to hardware or OS) range from > 24 to 132 (ms) with most falling into several buckets in the 30's, 40's, > 50's and 70's. > > I don't spot anything in the Timer.mainLoop code that might break when > highly > optimized but that's one possibility. > > Roger > > > > On 6/4/2014 3:25 PM, Martin Buchholz wrote: > >> Tests for Timer are inherently timing (!) dependent. >> It's reasonable for tests to assume that: >> - reasonable events like creating a thread and executing a simple task >> should complete in less than, say 2500ms. >> - system clock will not change by a significant amount (> 1 sec) during >> the >> test. Yes, that means Timer tests are likely to fail during daylight >> saving time switchover - we can live with that. (we could even try to fix >> that, by detecting deviations between clock time and elapsed time, but >> probably not worth it) >> >> Can you detect any real-world unreliability in my latest version of the >> test, not counting daylight saving time switch? >> >> I continue to resist your efforts to "fix" the test by removing chances >> for >> the SUT code to go wrong. >> >> >> On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang >> wrote: >> >> Hi Martin, >>> >>> Thanks for explanation, now I can understand why you set the DELAY_MS to >>> 100 seconds, it is true that it prevents failure on a slow host, >>> however, i >>> still have some concerns. >>> Because the test tests to schedule tasks at the time in the past, so all >>> 13 tasks should be executed immediately and finished within a short time. >>> If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that the >>> timer have plenty of time to finish tasks, so whether it causes above >>> test >>> point lost. >>> >>> Back to the original test, i think it should be a test stabilization >>> issue, because the original test assumes that the timer should be >>> cancelled >>> within < 1 second before the 14th task is called. this assumption may not >>> be guaranteed due to 2 reasons: >>> 1. if test is executed in jtreg concurrent mode on a slow host. >>> 2. the system clock of virtual machine may not be accurate (maybe faster >>> than physical). >>> >>> To support the point, i changed the test as attached to print the >>> execution time to see whether the timer behaves expected as the API >>> document described. the result is as expected. >>> >>> The unrepeated task executed immediately: [1401855509336] >>> The repeated task executed immediately and repeated per 1 second: >>> [1401855509337, 1401855510337, 1401855511338] >>> The fixed-rate task executed immediately and catch up the delay: >>> [1401855509338, 1401855509338, 1401855509338, 1401855509338, >>> 1401855509338, >>> 1401855509338, 1401855509338, 1401855509338, 1401855509338, >>> 1401855509338, >>> 1401855509338, 1401855509836, 1401855510836] >>> >>> >>> Thanks, >>> Eric >>> On 2014/6/4 9:16, Martin Buchholz wrote: >>> >>> >>> >>> >>> On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang >>> wrote: >>> >>> Hi Martin, >>>> >>>> To sleep(1000) is not enough to reproduce the failure, because it is >>>> much >>>> lower than the period DELAY_MS (10*1000) of the repeated task created by >>>> "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". >>>> >>>> Try sleep(DELAY_MS), the failure can be reproduced. >>>> >>>> Well sure, then the task is rescheduled, so I expect it to fail in >>> this >>> case. >>> >>> But in my version I had set DELAY_MS to 100 seconds. The point of >>> extending the DELAY_MS is to prevent flaky failure on a slow machine. >>> >>> Again, how do we know that this test hasn't found a Timer bug? >>> >>> I still can't reproduce it. >>> >>> >>> >>> > From paul.sandoz at oracle.com Fri Jun 6 08:05:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Jun 2014 10:05:10 +0200 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> <5390EE4D.5020805@oracle.com> <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> Message-ID: <0FFAFBA3-D528-4533-B025-87DF1A19D131@oracle.com> On Jun 6, 2014, at 1:17 AM, John Rose wrote: > Reviewed. > > This is not a requirement, but I would prefer (in general) to see less test logic in ASM-generated bytecode and more in Java. I am guessing that the invokeExact call could have been replaced by a simple weakly-typed invoke call in the framing code, and likewise with most of the other invokes (methodType, findSpecial) which are not caller-sensitive. I was wondering that too, but don't wanna block the push. With some judicious squinting i can work out what is going on. Perhaps if there are other related code fixes in the pipe (e.g. for the FIXME) this test could then be updated if there is time. > > ? John > > On Jun 5, 2014, at 3:25 PM, Vladimir Ivanov wrote: > >> Thanks for review, Paul. >> >>> >>> Looks ok. >>> >>> The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) >>> >>> Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? >> Good point. Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.01/ >> +1 Paul. From vladimir.x.ivanov at oracle.com Fri Jun 6 09:31:36 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 06 Jun 2014 13:31:36 +0400 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <0FFAFBA3-D528-4533-B025-87DF1A19D131@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> <5390EE4D.5020805@oracle.com> <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> <0FFAFBA3-D528-4533-B025-87DF1A19D131@oracle.com> Message-ID: <53918A78.3090804@oracle.com> John, Paul, I always welcome valuable suggestions, so here's an update :-) http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ IMO, the test is much cleaner now. Best regards, Vladimir Ivanov On 6/6/14 12:05 PM, Paul Sandoz wrote: > > On Jun 6, 2014, at 1:17 AM, John Rose wrote: > >> Reviewed. >> >> This is not a requirement, but I would prefer (in general) to see less test logic in ASM-generated bytecode and more in Java. I am guessing that the invokeExact call could have been replaced by a simple weakly-typed invoke call in the framing code, and likewise with most of the other invokes (methodType, findSpecial) which are not caller-sensitive. > > I was wondering that too, but don't wanna block the push. With some judicious squinting i can work out what is going on. Perhaps if there are other related code fixes in the pipe (e.g. for the FIXME) this test could then be updated if there is time. > > >> >> ? John >> >> On Jun 5, 2014, at 3:25 PM, Vladimir Ivanov wrote: >> >>> Thanks for review, Paul. >>> >>>> >>>> Looks ok. >>>> >>>> The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) >>>> >>>> Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? >>> Good point. Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.01/ >>> > > +1 > > Paul. > From luchsh at linux.vnet.ibm.com Fri Jun 6 10:03:25 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 6 Jun 2014 18:03:25 +0800 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: <5390AEA3.1000506@oracle.com> References: <538F1C1B.3040702@oracle.com> <5390AEA3.1000506@oracle.com> Message-ID: Hi Alan, On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman wrote: > On 05/06/2014 11:37, Jonathan Lu wrote: > > > If getsockopt(SO_ERROR) failed, I did not find any explicit docs about > the behavior. > but as I tested with some C code snippet, the value of sockopt_arg would > not be changed if getsockopt(SO_ERROR) failed. > So I prefer to keep the current approach, does it make sense to you ? > > The case that I was wondering about is the common case where > getsockopt(SO_ERROR) succeeds and I was wondering if the code should > actually be: > > if (sockopt_arg != 0 ) { > errno = sockopt_arg; > return -1; > } > > That way the caller of NET_Connect will have errno set so that > XXX_ThrowByNameWithLastError can create an appropriate exception message. > You are right! errno will be checked by other code if NET_Connect() failed, I've updated the patch, please help to review. http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ > > -Alan. > Many thanks - Jonathan From paul.sandoz at oracle.com Fri Jun 6 10:25:19 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Jun 2014 12:25:19 +0200 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <53918A78.3090804@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> <5390EE4D.5020805@oracle.com> <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> <0FFAFBA3-D528-4533-B025-87DF1A19D131@oracle.com> <53918A78.3090804@oracle.com> Message-ID: <8F5ACCC5-5F06-4494-91FF-10373CFDDE68@oracle.com> On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov wrote: > John, Paul, > > I always welcome valuable suggestions, so here's an update :-) > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ > > IMO, the test is much cleaner now. > Yes, I like it, easier to understand. Paul. From volker.simonis at gmail.com Fri Jun 6 12:27:45 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Jun 2014 14:27:45 +0200 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: <538F1C1B.3040702@oracle.com> <5390AEA3.1000506@oracle.com> Message-ID: Hi Jonathan, I just wanted to let you know that I've build your changes on AIX 5..3 and 7.1. I've also run the jdk regression tests without specific issues. So thumbs up from me! Regards, Volker On Fri, Jun 6, 2014 at 12:03 PM, Jonathan Lu wrote: > Hi Alan, > > On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman > wrote: > >> On 05/06/2014 11:37, Jonathan Lu wrote: >> >> >> If getsockopt(SO_ERROR) failed, I did not find any explicit docs about >> the behavior. >> but as I tested with some C code snippet, the value of sockopt_arg would >> not be changed if getsockopt(SO_ERROR) failed. >> So I prefer to keep the current approach, does it make sense to you ? >> >> The case that I was wondering about is the common case where >> getsockopt(SO_ERROR) succeeds and I was wondering if the code should >> actually be: >> >> if (sockopt_arg != 0 ) { >> errno = sockopt_arg; >> return -1; >> } >> >> That way the caller of NET_Connect will have errno set so that >> XXX_ThrowByNameWithLastError can create an appropriate exception message. >> > > > You are right! errno will be checked by other code if NET_Connect() failed, > I've updated the patch, please help to review. > > http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ > > > >> >> -Alan. >> > > > Many thanks > - Jonathan From Alan.Bateman at oracle.com Fri Jun 6 12:45:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Jun 2014 13:45:49 +0100 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: <538F1C1B.3040702@oracle.com> <5390AEA3.1000506@oracle.com> Message-ID: <5391B7FD.1010607@oracle.com> On 06/06/2014 11:03, Jonathan Lu wrote: > > You are right! errno will be checked by other code if NET_Connect() > failed, > I've updated the patch, please help to review. > > http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ > > Thanks for the update, this looks good to me now. -Alan. From luchsh at linux.vnet.ibm.com Fri Jun 6 17:03:43 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Sat, 7 Jun 2014 01:03:43 +0800 Subject: RFR 8043954: Fix behavior difference of connect() for AIX In-Reply-To: References: <538F1C1B.3040702@oracle.com> <5390AEA3.1000506@oracle.com> Message-ID: Hi Alan, Volker, Thanks a lot! I've pushed the change. Best regards - Jonathan On Fri, Jun 6, 2014 at 8:27 PM, Volker Simonis wrote: > Hi Jonathan, > > I just wanted to let you know that I've build your changes on AIX 5..3 and > 7.1. > I've also run the jdk regression tests without specific issues. > > So thumbs up from me! > > Regards, > Volker > > > On Fri, Jun 6, 2014 at 12:03 PM, Jonathan Lu > wrote: > > Hi Alan, > > > > On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman > > wrote: > > > >> On 05/06/2014 11:37, Jonathan Lu wrote: > >> > >> > >> If getsockopt(SO_ERROR) failed, I did not find any explicit docs about > >> the behavior. > >> but as I tested with some C code snippet, the value of sockopt_arg would > >> not be changed if getsockopt(SO_ERROR) failed. > >> So I prefer to keep the current approach, does it make sense to you ? > >> > >> The case that I was wondering about is the common case where > >> getsockopt(SO_ERROR) succeeds and I was wondering if the code should > >> actually be: > >> > >> if (sockopt_arg != 0 ) { > >> errno = sockopt_arg; > >> return -1; > >> } > >> > >> That way the caller of NET_Connect will have errno set so that > >> XXX_ThrowByNameWithLastError can create an appropriate exception > message. > >> > > > > > > You are right! errno will be checked by other code if NET_Connect() > failed, > > I've updated the patch, please help to review. > > > > http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ > > > > > > > >> > >> -Alan. > >> > > > > > > Many thanks > > - Jonathan > From sean.coffey at oracle.com Fri Jun 6 17:22:20 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 06 Jun 2014 18:22:20 +0100 Subject: RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader Message-ID: <5391F8CC.3000404@oracle.com> Changes in the ORB loading in 8u5 causes incompatibility changes for some environments where a 3rd party plugin might be deployed over plugin. Some CORBA deployment installations have an incorrect expectation on finding the custom ORBSingleton class using the context classloader. Proper approach is to expect to find such classes on the system classloader. For JDK 9, the 8u5(new) behaviour will remain. For JDK 8u and older update families, I'm proposing we revert back to the old behaviour to aid compatibility in current deployment scenarios. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042789/webrev/ bug : https://bugs.openjdk.java.net/browse/JDK-8042789 I'm working a testcase for this also. regards, Sean. From john.r.rose at oracle.com Fri Jun 6 17:43:16 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 6 Jun 2014 10:43:16 -0700 Subject: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method In-Reply-To: <8F5ACCC5-5F06-4494-91FF-10373CFDDE68@oracle.com> References: <538F3A68.3010905@oracle.com> <8F6F6239-B1B1-43B7-BD2D-FBAE0DA01A75@oracle.com> <5390EE4D.5020805@oracle.com> <1FC23037-F802-4665-8033-A39AEF6D45BA@oracle.com> <0FFAFBA3-D528-4533-B025-87DF1A19D131@oracle.com> <53918A78.3090804@oracle.com> <8F5ACCC5-5F06-4494-91FF-10373CFDDE68@oracle.com> Message-ID: <4BD333B5-C431-429E-BD67-D0B1528130C7@oracle.com> On Jun 6, 2014, at 3:25 AM, Paul Sandoz wrote: > > On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov wrote: > >> John, Paul, >> >> I always welcome valuable suggestions, so here's an update :-) >> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ >> >> IMO, the test is much cleaner now. >> > > Yes, I like it, easier to understand. Exactly what I was hoping for. From lance.andersen at oracle.com Fri Jun 6 17:54:39 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 6 Jun 2014 13:54:39 -0400 Subject: RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader In-Reply-To: <5391F8CC.3000404@oracle.com> References: <5391F8CC.3000404@oracle.com> Message-ID: <46B29925-FD34-46F8-A66F-2DFFE883EF13@oracle.com> Hi Sean I think this makes sense and the change looks fine 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 Jun 6, 2014, at 1:22 PM, Se?n Coffey wrote: > Changes in the ORB loading in 8u5 causes incompatibility changes for some environments where a 3rd party plugin might be deployed over plugin. Some CORBA deployment installations have an incorrect expectation on finding the custom ORBSingleton class using the context classloader. Proper approach is to expect to find such classes on the system classloader. For JDK 9, the 8u5(new) behaviour will remain. > > For JDK 8u and older update families, I'm proposing we revert back to the old behaviour to aid compatibility in current deployment scenarios. > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042789/webrev/ > bug : https://bugs.openjdk.java.net/browse/JDK-8042789 > > I'm working a testcase for this also. > > regards, > Sean. From Alan.Bateman at oracle.com Fri Jun 6 19:50:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Jun 2014 20:50:49 +0100 Subject: RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader In-Reply-To: <5391F8CC.3000404@oracle.com> References: <5391F8CC.3000404@oracle.com> Message-ID: <53921B99.2020502@oracle.com> On 06/06/2014 18:22, Se?n Coffey wrote: > Changes in the ORB loading in 8u5 causes incompatibility changes for > some environments where a 3rd party plugin might be deployed over > plugin. Some CORBA deployment installations have an incorrect > expectation on finding the custom ORBSingleton class using the context > classloader. Proper approach is to expect to find such classes on the > system classloader. For JDK 9, the 8u5(new) behaviour will remain. > Right, it doesn't make sense to use the TCCL to locate the system-wide/singleton ORB and then cache it but clearly some applications that were bundle their own ORB with conflicting configuration are running into this. The change in the webrev looks okay to me (for 8u, not 9 where I agree that we keep the correct behavior). -Alan From mike.duigou at oracle.com Fri Jun 6 19:54:24 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 6 Jun 2014 12:54:24 -0700 Subject: RFR: 8046085: (s) inserting null key into HashMap treebin fails Message-ID: Hello all; This changeset corrects a problem inserting a null key into a HashMap that is using TreeBins. The root cause of the failure was diagnosed by Paul Sandoz and confirmed by Alan Bateman, Doug Lea and myself. I've prepared the changeset and a minimal test which reproduces the failure. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8046085 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8046085/0/webrev/ This change will be backported to 8u-dev as quickly as possible. Mike From chris.hegarty at oracle.com Fri Jun 6 21:20:52 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 Jun 2014 22:20:52 +0100 Subject: RFR: 8046085: (s) inserting null key into HashMap treebin fails In-Reply-To: References: Message-ID: <943B7713-D7A5-4244-9EFE-6E058304A62F@oracle.com> The change and test look good to me Mike. Typo? treeifiying -> treeifying. ;-) -Chris. > On 6 Jun 2014, at 20:54, Mike Duigou wrote: > > Hello all; > > This changeset corrects a problem inserting a null key into a HashMap that is using TreeBins. The root cause of the failure was diagnosed by Paul Sandoz and confirmed by Alan Bateman, Doug Lea and myself. I've prepared the changeset and a minimal test which reproduces the failure. > > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8046085 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8046085/0/webrev/ > > This change will be backported to 8u-dev as quickly as possible. > > Mike From martinrb at google.com Sat Jun 7 01:32:41 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Jun 2014 18:32:41 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> <538F804F.1070908@oracle.com> Message-ID: If you don't want to go with my rewrite, you can conservatively just check in a 10x increase in all the constant durations and see whether the flakiness goes away. On Thu, Jun 5, 2014 at 9:46 PM, Martin Buchholz wrote: > As with David, the cause of the failure is mystifying. > How can things fail when we stay below the timeout value of 500ms? > There's a bug either in Timer or my own understanding of what should be > happening. > > Anyways, raising the timeout value (as I have done in my minor rewrite) > seems prudent. Fortunately, we can write this test in a way that doesn't > require actually waiting for the timeout to elapse. > > > On Wed, Jun 4, 2014 at 1:23 PM, roger riggs > wrote: > >> Hi Martin, Eric, >> >> Of several hundred failures of this test, most were done in a JRE run with >> -Xcomp set. A few failures occurred with -Xmixed, none with -Xint. >> >> The printed "elapsed" times (not normalized to hardware or OS) range from >> 24 to 132 (ms) with most falling into several buckets in the 30's, 40's, >> 50's and 70's. >> >> I don't spot anything in the Timer.mainLoop code that might break when >> highly >> optimized but that's one possibility. >> >> Roger >> >> >> >> On 6/4/2014 3:25 PM, Martin Buchholz wrote: >> >>> Tests for Timer are inherently timing (!) dependent. >>> It's reasonable for tests to assume that: >>> - reasonable events like creating a thread and executing a simple task >>> should complete in less than, say 2500ms. >>> - system clock will not change by a significant amount (> 1 sec) during >>> the >>> test. Yes, that means Timer tests are likely to fail during daylight >>> saving time switchover - we can live with that. (we could even try to fix >>> that, by detecting deviations between clock time and elapsed time, but >>> probably not worth it) >>> >>> Can you detect any real-world unreliability in my latest version of the >>> test, not counting daylight saving time switch? >>> >>> I continue to resist your efforts to "fix" the test by removing chances >>> for >>> the SUT code to go wrong. >>> >>> >>> On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang >>> wrote: >>> >>> Hi Martin, >>>> >>>> Thanks for explanation, now I can understand why you set the DELAY_MS to >>>> 100 seconds, it is true that it prevents failure on a slow host, >>>> however, i >>>> still have some concerns. >>>> Because the test tests to schedule tasks at the time in the past, so all >>>> 13 tasks should be executed immediately and finished within a short >>>> time. >>>> If set the elapsed time limitation to 50s (DELAY_MS/2), it seems that >>>> the >>>> timer have plenty of time to finish tasks, so whether it causes above >>>> test >>>> point lost. >>>> >>>> Back to the original test, i think it should be a test stabilization >>>> issue, because the original test assumes that the timer should be >>>> cancelled >>>> within < 1 second before the 14th task is called. this assumption may >>>> not >>>> be guaranteed due to 2 reasons: >>>> 1. if test is executed in jtreg concurrent mode on a slow host. >>>> 2. the system clock of virtual machine may not be accurate (maybe faster >>>> than physical). >>>> >>>> To support the point, i changed the test as attached to print the >>>> execution time to see whether the timer behaves expected as the API >>>> document described. the result is as expected. >>>> >>>> The unrepeated task executed immediately: [1401855509336] >>>> The repeated task executed immediately and repeated per 1 second: >>>> [1401855509337, 1401855510337, 1401855511338] >>>> The fixed-rate task executed immediately and catch up the delay: >>>> [1401855509338, 1401855509338, 1401855509338, 1401855509338, >>>> 1401855509338, >>>> 1401855509338, 1401855509338, 1401855509338, 1401855509338, >>>> 1401855509338, >>>> 1401855509338, 1401855509836, 1401855510836] >>>> >>>> >>>> Thanks, >>>> Eric >>>> On 2014/6/4 9:16, Martin Buchholz wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang >>>> wrote: >>>> >>>> Hi Martin, >>>>> >>>>> To sleep(1000) is not enough to reproduce the failure, because it is >>>>> much >>>>> lower than the period DELAY_MS (10*1000) of the repeated task created >>>>> by >>>>> "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". >>>>> >>>>> Try sleep(DELAY_MS), the failure can be reproduced. >>>>> >>>>> Well sure, then the task is rescheduled, so I expect it to fail in >>>> this >>>> case. >>>> >>>> But in my version I had set DELAY_MS to 100 seconds. The point of >>>> extending the DELAY_MS is to prevent flaky failure on a slow machine. >>>> >>>> Again, how do we know that this test hasn't found a Timer bug? >>>> >>>> I still can't reproduce it. >>>> >>>> >>>> >>>> >> > From joe.darcy at oracle.com Sat Jun 7 19:19:43 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 07 Jun 2014 12:19:43 -0700 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: References: Message-ID: <539365CF.4000806@oracle.com> Hi Joel, Sorry for the belated review. Generally the change looks good. One question, in 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { 2804 return m1.getReturnType() == m2.getReturnType() && 2805 m1.getName() == m2.getName() && 2806 arrayContentsEq(m1.getParameterTypes(), 2807 m2.getParameterTypes()); 2808 } Should the equality check on 2805 be .equals rather than == ? Thanks, -Joe On 05/07/2014 10:43 AM, Joel Borggr?n-Franck wrote: > Hi, > > Since Java 8 the methods Class.getMethod() and Class.getMethods() can in some circumstances return methods that are not members of the class. This is due to a spec change in 8 not due to a code change. For this to happen you need to have an interface hierarchy that looks something like: > > interface I { void m(); } > interface J extends I { void m(); } > > and either one of: > > interface K extends ***I,*** J {} > class C implements ***I,*** J {} > > In Java 7 K.class.getMethods() would return [ I.m, J.m ]. The 7 spec is a bit vague but I have been convinced by experts that this is actually correct in 7. However this was changed in the spec for 8, now only J.m() is a member of K or C so the result should only contain [ J.m() ]. > > See the bug: https://bugs.openjdk.java.net/browse/JDK-8029674 for a more thorough discussion of this. > > The fix proposed for 8u (and 9 at first) is a partial fix that ensures that: > > - a concrete class does not have any abstract methods > - nothing is changed unless someone introduces default methods into the interface hierarchy > > This is to minimise the behavioural compatibility concerns in a minor release. For 9 we might implement the full solution. (See the 9 bug: https://bugs.openjdk.java.net/browse/JDK-8029459). > > Basically in the fix proposed for 8u, default methods prune less specific methods from the result if they have the same discriptor. There are some complications due to preserving the old lookup order and the fact that we don?t want different results depending on the order of pairwise comparisons. Since this work and MethodArray in general is comparing descriptors bridges should not interact with this patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029674 > Patch: http://cr.openjdk.java.net/~jfranck/8029674/webrev.02/ > > *** Testing *** > > I made a test with a bit over 100 cases where 40 of the tests test behaviour that shouldn?t change (IE they pass both with and without the patch). The test is a bit vast, but I have commented some of the more interesting results. > > *** Performance *** > > The time complexity of this is O(defaultMethods * methods). getMethods() is already somewhat quadratic in complexity due to removing interface methods that have a concrete implementation. Also the result is cached so this is a one time increase per Class. > > I have done some experiments on a patched jdk without the cache and the performance looks decent: > > - Loading every class in rt.jar and calling getMethods() on every Class takes 8s on my laptop both before and after the patch. Perhaps not that surprising since there aren?t that many default methods in the jdk and this is probably dominated by IO. > > - Calling getMethods on a Class with 16K methods, 10% which are default methods, seem to take roughly 50% longer on my laptop (2,4 instead of 1,7 seconds). I?m working on converting this benchmark to JMH, but at least I don?t think I have made the most basic benchmark errors. > > If this turns out to be a performance problem I have an idea for an index that will make this O(methods sharing name * methods) for an addition of a few allocations, but I don?t expect this to be necessary. > > Thanks in advance > > cheers > /Joel From andrej.golovnin at gmail.com Sat Jun 7 20:34:27 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Sat, 7 Jun 2014 22:34:27 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: References: <539365CF.4000806@oracle.com> Message-ID: <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> Hi Joe, > Sorry for the belated review. > > Generally the change looks good. One question, in > > 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { > 2804 return m1.getReturnType() == m2.getReturnType() && > 2805 m1.getName() == m2.getName() && > 2806 arrayContentsEq(m1.getParameterTypes(), > 2807 m2.getParameterTypes()); > 2808 } > > Should the equality check on 2805 be .equals rather than == ? > "==" can be used in this case as the method name is interned by JVM. Here is the comment for the field "name" from java.lang.reflect.Method: // This is guaranteed to be interned by the VM in the 1.4 // reflection implementation private String name; BTW, in the old version of Class in the line 2766 there was already a similar check: 2764 if (m != null && 2765 m.getReturnType() == toRemove.getReturnType() && 2766 m.getName() == toRemove.getName() && 2767 arrayContentsEq(m.getParameterTypes(), 2768 toRemove.getParameterTypes())) { 2769 methods[i] = null; Best regards, Andrej Golovnin From roger.riggs at oracle.com Mon Jun 9 15:03:13 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 09 Jun 2014 11:03:13 -0400 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> <538F804F.1070908@oracle.com> Message-ID: <5395CCB1.8010900@oracle.com> Hi Eric, Martin, I'm fine with the re-write. I'm not sure why the re-ordering of y3 will change the behavior of the test but it will provide more debugging info. Roger On 6/6/2014 9:32 PM, Martin Buchholz wrote: > If you don't want to go with my rewrite, you can conservatively just > check in a 10x increase in all the constant durations and see whether > the flakiness goes away. > > > On Thu, Jun 5, 2014 at 9:46 PM, Martin Buchholz > wrote: > > As with David, the cause of the failure is mystifying. > How can things fail when we stay below the timeout value of 500ms? > There's a bug either in Timer or my own understanding of what > should be happening. > > Anyways, raising the timeout value (as I have done in my minor > rewrite) seems prudent. Fortunately, we can write this test in a > way that doesn't require actually waiting for the timeout to elapse. > > > On Wed, Jun 4, 2014 at 1:23 PM, roger riggs > > wrote: > > Hi Martin, Eric, > > Of several hundred failures of this test, most were done in a > JRE run with > -Xcomp set. A few failures occurred with -Xmixed, none with > -Xint. > > The printed "elapsed" times (not normalized to hardware or OS) > range from > 24 to 132 (ms) with most falling into several buckets in the > 30's, 40's, 50's and 70's. > > I don't spot anything in the Timer.mainLoop code that might > break when highly > optimized but that's one possibility. > > Roger > > > > On 6/4/2014 3:25 PM, Martin Buchholz wrote: > > Tests for Timer are inherently timing (!) dependent. > It's reasonable for tests to assume that: > - reasonable events like creating a thread and executing a > simple task > should complete in less than, say 2500ms. > - system clock will not change by a significant amount (> > 1 sec) during the > test. Yes, that means Timer tests are likely to fail > during daylight > saving time switchover - we can live with that. (we could > even try to fix > that, by detecting deviations between clock time and > elapsed time, but > probably not worth it) > > Can you detect any real-world unreliability in my latest > version of the > test, not counting daylight saving time switch? > > I continue to resist your efforts to "fix" the test by > removing chances for > the SUT code to go wrong. > > > On Tue, Jun 3, 2014 at 11:28 PM, Eric Wang > > > wrote: > > Hi Martin, > > Thanks for explanation, now I can understand why you > set the DELAY_MS to > 100 seconds, it is true that it prevents failure on a > slow host, however, i > still have some concerns. > Because the test tests to schedule tasks at the time > in the past, so all > 13 tasks should be executed immediately and finished > within a short time. > If set the elapsed time limitation to 50s > (DELAY_MS/2), it seems that the > timer have plenty of time to finish tasks, so whether > it causes above test > point lost. > > Back to the original test, i think it should be a test > stabilization > issue, because the original test assumes that the > timer should be cancelled > within < 1 second before the 14th task is called. this > assumption may not > be guaranteed due to 2 reasons: > 1. if test is executed in jtreg concurrent mode on a > slow host. > 2. the system clock of virtual machine may not be > accurate (maybe faster > than physical). > > To support the point, i changed the test as attached > to print the > execution time to see whether the timer behaves > expected as the API > document described. the result is as expected. > > The unrepeated task executed immediately: [1401855509336] > The repeated task executed immediately and repeated > per 1 second: > [1401855509337, 1401855510337, 1401855511338] > The fixed-rate task executed immediately and catch up > the delay: > [1401855509338, 1401855509338, 1401855509338, > 1401855509338, 1401855509338, > 1401855509338, 1401855509338, 1401855509338, > 1401855509338, 1401855509338, > 1401855509338, 1401855509836, 1401855510836] > > > Thanks, > Eric > On 2014/6/4 9:16, Martin Buchholz wrote: > > > > > On Tue, Jun 3, 2014 at 6:12 PM, Eric Wang > > wrote: > > Hi Martin, > > To sleep(1000) is not enough to reproduce the > failure, because it is much > lower than the period DELAY_MS (10*1000) of the > repeated task created by > "scheduleAtFixedRate(t, counter(y3), past, DELAY_MS)". > > Try sleep(DELAY_MS), the failure can be reproduced. > > Well sure, then the task is rescheduled, so I expect > it to fail in this > case. > > But in my version I had set DELAY_MS to 100 seconds. > The point of > extending the DELAY_MS is to prevent flaky failure on > a slow machine. > > Again, how do we know that this test hasn't found a > Timer bug? > > I still can't reproduce it. > > > > > > From joel.franck at oracle.com Mon Jun 9 16:33:40 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 9 Jun 2014 18:33:40 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> References: <539365CF.4000806@oracle.com> <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> Message-ID: Hi Joe, IIRC name isn?t actually interned with String.intern() but in the VM:s Symbol table as a name representing a (Java) method. Should be equivalent, as long as we don?t start comparing it with == with interned Strings. As Andrej wrote, this is just refactoring of the previous code, to reuse the logic. cheers /Joel On 07 Jun 2014, at 22:34, Andrej Golovnin wrote: > Hi Joe, > >> Sorry for the belated review. >> >> Generally the change looks good. One question, in >> >> 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { >> 2804 return m1.getReturnType() == m2.getReturnType() && >> 2805 m1.getName() == m2.getName() && >> 2806 arrayContentsEq(m1.getParameterTypes(), >> 2807 m2.getParameterTypes()); >> 2808 } >> >> Should the equality check on 2805 be .equals rather than == ? >> > > "==" can be used in this case as the method name is interned by JVM. > Here is the comment for the field "name" from java.lang.reflect.Method: > > // This is guaranteed to be interned by the VM in the 1.4 > // reflection implementation > private String name; > > BTW, in the old version of Class in the line 2766 there was already a similar check: > > 2764 if (m != null && > 2765 m.getReturnType() == toRemove.getReturnType() && > 2766 m.getName() == toRemove.getName() && > 2767 arrayContentsEq(m.getParameterTypes(), > 2768 toRemove.getParameterTypes())) { > 2769 methods[i] = null; > > > Best regards, > Andrej Golovnin > > From martinrb at google.com Mon Jun 9 17:18:21 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Jun 2014 10:18:21 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <5395CCB1.8010900@oracle.com> References: <538832ED.8030809@oracle.com> <538DD2D7.1050706@oracle.com> <538E100D.90105@oracle.com> <538E727A.5020507@oracle.com> <538EBC93.4080409@oracle.com> <538F804F.1070908@oracle.com> <5395CCB1.8010900@oracle.com> Message-ID: On Mon, Jun 9, 2014 at 8:03 AM, roger riggs wrote: > Hi Eric, Martin, > > I'm fine with the re-write. I'm not sure why the re-ordering of y3 will > change the > behavior of the test but it will provide more debugging info. > No reason for re-ordering except consistency. Instead of untimed await, it seems slightly better to use timed wait for the latches. Here's my latest version of the mini-rewrite: import java.util.*; import java.util.concurrent.*; import static java.util.concurrent.TimeUnit.*; public class Args { static final long DELAY_MS = 30 * 1000L; void schedule(final Timer t, final TimerTask task, final Date d) { t.schedule(task, d); assertThrows (IllegalStateException.class, () -> t.schedule(task, d)); } void schedule(final Timer t, final TimerTask task, final Date d, final long period) { t.schedule(task, d, period); assertThrows (IllegalStateException.class, () -> t.schedule(task, d, period)); } void scheduleAtFixedRate(final Timer t, final TimerTask task, final Date d, final long period) { t.scheduleAtFixedRate(task, d, period); assertThrows (IllegalStateException.class, () -> t.scheduleAtFixedRate(task, d, period)); } TimerTask counter(final CountDownLatch latch) { return new TimerTask() { public void run() { if (latch.getCount() == 0) fail(String.format("Latch counted down too many times: " + latch)); latch.countDown(); }}; } TimerTask nop() { return new TimerTask() { public void run() { }}; } void test(String[] args) throws Throwable { final Timer t = new Timer(); try { test(t); } finally { // Ensure this test doesn't interfere with subsequent // tests even in case of failure. t.cancel(); } // Attempts to schedule tasks on a cancelled Timer result in ISE. final Date past = new Date(System.currentTimeMillis() - DELAY_MS); final Date future = new Date(System.currentTimeMillis() + DELAY_MS); assertThrows (IllegalStateException.class, () -> t.schedule(nop(), 42), () -> t.schedule(nop(), 42), () -> t.schedule(nop(), past), () -> t.schedule(nop(), 42, 42), () -> t.schedule(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), 42, 42), () -> t.scheduleAtFixedRate(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), future, 42)); } void test(Timer t) throws Throwable { final TimerTask x = new TimerTask() { public void run() {}}; assertThrows (IllegalArgumentException.class, () -> t.schedule(x, -42), () -> t.schedule(x, new Date(-42)), () -> t.schedule(x, Long.MAX_VALUE), () -> t.schedule(x, -42, 42), () -> t.schedule(x, new Date(-42), 42), () -> t.schedule(x, Long.MAX_VALUE, 42), () -> t.schedule(x, 42, 0), () -> t.schedule(x, new Date(42), 0), () -> t.schedule(x, 42, -42), () -> t.schedule(x, new Date(42), -42), () -> t.scheduleAtFixedRate(x, -42, 42), () -> t.scheduleAtFixedRate(x, new Date(-42), 42), () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), () -> t.scheduleAtFixedRate(x, 42, 0), () -> t.scheduleAtFixedRate(x, new Date(42), 0), () -> t.scheduleAtFixedRate(x, 42, -42), () -> t.scheduleAtFixedRate(x, new Date(42), -42)); assertThrows (NullPointerException.class, () -> t.schedule(null, 42), () -> t.schedule(x, (Date)null), () -> t.schedule(null, 42, 42), () -> t.schedule(x, (Date)null, 42), () -> t.scheduleAtFixedRate(null, 42, 42), () -> t.scheduleAtFixedRate(x, (Date)null, 42)); // Create local classes for clearer diagnostics in case of failure class OneShotLatch extends CountDownLatch { OneShotLatch() { super(1); } } class FixedDelayLatch extends CountDownLatch { FixedDelayLatch() { super(1); } } class FixedRateLatch extends CountDownLatch { FixedRateLatch() { super(11); } } final CountDownLatch y1 = new OneShotLatch(); final CountDownLatch y2 = new FixedDelayLatch(); final CountDownLatch y3 = new FixedRateLatch(); final long start = System.currentTimeMillis(); final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); schedule( t, counter(y1), past); schedule( t, counter(y2), past, DELAY_MS); scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); check(y1.await(DELAY_MS / 4, MILLISECONDS)); check(y2.await(DELAY_MS / 4, MILLISECONDS)); check(y3.await(DELAY_MS / 4, MILLISECONDS)); final long elapsed = System.currentTimeMillis() - start; if (elapsed >= DELAY_MS / 2) fail(String.format("Test took too long: elapsed=%d%n", elapsed)); } //--------------------- Infrastructure --------------------------- volatile int passed = 0, failed = 0; void pass() {passed++;} void fail() {failed++; Thread.dumpStack();} void fail(String msg) {System.err.println(msg); fail();} void unexpected(Throwable t) {failed++; t.printStackTrace();} void check(boolean cond) {if (cond) pass(); else fail();} void equal(Object x, Object y) { if (x == null ? y == null : x.equals(y)) pass(); else fail(x + " not equal to " + y);} public static void main(String[] args) throws Throwable { new Args().instanceMain(args);} void instanceMain(String[] args) throws Throwable { try {test(args);} catch (Throwable t) {unexpected(t);} System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); if (failed > 0) throw new AssertionError("Some tests failed");} interface F { void f() throws Throwable; } void assertThrows(Class k, F... fs) { for (F f : fs) try {f.f(); fail("Expected " + k.getName() + " not thrown");} catch (Throwable t) { if (k.isAssignableFrom(t.getClass())) pass(); else unexpected(t);}} } From andrej.golovnin at gmail.com Mon Jun 9 19:56:36 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 9 Jun 2014 21:56:36 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: References: <539365CF.4000806@oracle.com> <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> Message-ID: <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> Hi Joel, > IIRC name isn?t actually interned with String.intern() but in the VM:s Symbol table as a name representing a (Java) method. Should be equivalent, as long as we don?t start comparing it with == with interned Strings. I think that's not true. The following small test program prints true on the console: public class Test { public static void main(String... argv) throws Exception { Method m = Test.class.getMethod("main", String[].class); System.out.println(m.getName() == new String("main").intern()); } } And if you look into reflection.cpp at lines 787-789, you will see following code: Symbol* method_name = method->name(); oop name_oop = StringTable::intern(method_name, CHECK_NULL); Handle name = Handle(THREAD, name_oop); And later at the line 798 we have this code: java_lang_reflect_Method::set_name(mh(), name()); Therefore I would say the name is actually interned in terms of String.intern(). And you can compare the name of a method with == with interned Strings. The same applies to a name of a class and to a name of a field too. Please feel free to correct me. Best regards, Andrej Golovnin > > cheers > /Joel > > On 07 Jun 2014, at 22:34, Andrej Golovnin wrote: > >> Hi Joe, >> >>> Sorry for the belated review. >>> >>> Generally the change looks good. One question, in >>> >>> 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { >>> 2804 return m1.getReturnType() == m2.getReturnType() && >>> 2805 m1.getName() == m2.getName() && >>> 2806 arrayContentsEq(m1.getParameterTypes(), >>> 2807 m2.getParameterTypes()); >>> 2808 } >>> >>> Should the equality check on 2805 be .equals rather than == ? >>> >> >> "==" can be used in this case as the method name is interned by JVM. >> Here is the comment for the field "name" from java.lang.reflect.Method: >> >> // This is guaranteed to be interned by the VM in the 1.4 >> // reflection implementation >> private String name; >> >> BTW, in the old version of Class in the line 2766 there was already a similar check: >> >> 2764 if (m != null && >> 2765 m.getReturnType() == toRemove.getReturnType() && >> 2766 m.getName() == toRemove.getName() && >> 2767 arrayContentsEq(m.getParameterTypes(), >> 2768 toRemove.getParameterTypes())) { >> 2769 methods[i] = null; >> >> >> Best regards, >> Andrej Golovnin >> >> > From henry.jen at oracle.com Mon Jun 9 21:39:16 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 09 Jun 2014 14:39:16 -0700 Subject: RFR: 8046389: Add missing @since tag under javax.sql.** Message-ID: <53962984.1070406@oracle.com> Hi, Please review a trivial webrev that provides missing @since tag for elements under javax.sql, javax.sql.CommonDataSource was extracted out since 1.6, methods have @since 1.4 tag because those methods existed in origins since then. http://cr.openjdk.java.net/~henryjen/jdk9/8046389/0/webrev/ Cheers, Henry From joe.darcy at oracle.com Mon Jun 9 23:09:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 09 Jun 2014 16:09:13 -0700 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> References: <539365CF.4000806@oracle.com> <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> Message-ID: <53963E99.4000705@oracle.com> Thanks for the investigation Andrej. In any case, I'd prefer a comment noting the interned-ness (or mostly interned-ness, etc.) of the name to let other readers of the code using == rather than .equals is intentional and not a bug. Thanks, -Joe On 06/09/2014 12:56 PM, Andrej Golovnin wrote: > Hi Joel, > >> IIRC name isn?t actually interned with String.intern() but in the VM:s Symbol table as a name representing a (Java) method. Should be equivalent, as long as we don?t start comparing it with == with interned Strings. > I think that's not true. > > The following small test program prints true on the console: > > public class Test { > > public static void main(String... argv) throws Exception { > Method m = Test.class.getMethod("main", String[].class); > System.out.println(m.getName() == new String("main").intern()); > } > > } > > And if you look into reflection.cpp at lines 787-789, you will see following code: > > Symbol* method_name = method->name(); > oop name_oop = StringTable::intern(method_name, CHECK_NULL); > Handle name = Handle(THREAD, name_oop); > > And later at the line 798 we have this code: > > java_lang_reflect_Method::set_name(mh(), name()); > > Therefore I would say the name is actually interned in terms of String.intern(). > And you can compare the name of a method with == with interned Strings. > > The same applies to a name of a class and to a name of a field too. > Please feel free to correct me. > > Best regards, > Andrej Golovnin > > >> cheers >> /Joel >> >> On 07 Jun 2014, at 22:34, Andrej Golovnin wrote: >> >>> Hi Joe, >>> >>>> Sorry for the belated review. >>>> >>>> Generally the change looks good. One question, in >>>> >>>> 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { >>>> 2804 return m1.getReturnType() == m2.getReturnType() && >>>> 2805 m1.getName() == m2.getName() && >>>> 2806 arrayContentsEq(m1.getParameterTypes(), >>>> 2807 m2.getParameterTypes()); >>>> 2808 } >>>> >>>> Should the equality check on 2805 be .equals rather than == ? >>>> >>> "==" can be used in this case as the method name is interned by JVM. >>> Here is the comment for the field "name" from java.lang.reflect.Method: >>> >>> // This is guaranteed to be interned by the VM in the 1.4 >>> // reflection implementation >>> private String name; >>> >>> BTW, in the old version of Class in the line 2766 there was already a similar check: >>> >>> 2764 if (m != null && >>> 2765 m.getReturnType() == toRemove.getReturnType() && >>> 2766 m.getName() == toRemove.getName() && >>> 2767 arrayContentsEq(m.getParameterTypes(), >>> 2768 toRemove.getParameterTypes())) { >>> 2769 methods[i] = null; >>> >>> >>> Best regards, >>> Andrej Golovnin >>> >>> From peter.levart at gmail.com Tue Jun 10 06:14:47 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 10 Jun 2014 08:14:47 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: References: Message-ID: <5396A257.7050908@gmail.com> Hi Joel, I don't know if this is warranted, since this is on slow path (the resulting methods are cached) and the number of overloaded methods is typically not large, but the following MethodArray method: 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { could use a JavaLangAccess bridge to access the Method's parameter types without cloning the array each time. Especially since it's called many times inside nested loop (see removeLessSpecifics()) where the number of invocations grows quadratically with the MethodArray's length. Method.getParameterTypes() is only invoked for pairs of overloaded methods, so this might not be a real issue. Number of invocations could be halved though with this optimization of removeLessSpecific(): void removeLessSpecifics() { if (!hasDefaults()) return; for (int i = 1; i < length; i++) { Method m = get(i); if (m == null) continue; for (int j = 0; j < i; j++) { Method n = get(j); if (n == null || !(m.isDefault() || n.isDefault())) continue; if (!matchesNameAndDescriptor(m, n)) continue; if (hasMoreSpecificClass(m, n)) remove(j); else if (hasMoreSpecificClass(n, m)) remove(i); } } } Regards, Peter On 05/07/2014 07:43 PM, Joel Borggr?n-Franck wrote: > Hi, > > Since Java 8 the methods Class.getMethod() and Class.getMethods() can in some circumstances return methods that are not members of the class. This is due to a spec change in 8 not due to a code change. For this to happen you need to have an interface hierarchy that looks something like: > > interface I { void m(); } > interface J extends I { void m(); } > > and either one of: > > interface K extends ***I,*** J {} > class C implements ***I,*** J {} > > In Java 7 K.class.getMethods() would return [ I.m, J.m ]. The 7 spec is a bit vague but I have been convinced by experts that this is actually correct in 7. However this was changed in the spec for 8, now only J.m() is a member of K or C so the result should only contain [ J.m() ]. > > See the bug: https://bugs.openjdk.java.net/browse/JDK-8029674 for a more thorough discussion of this. > > The fix proposed for 8u (and 9 at first) is a partial fix that ensures that: > > - a concrete class does not have any abstract methods > - nothing is changed unless someone introduces default methods into the interface hierarchy > > This is to minimise the behavioural compatibility concerns in a minor release. For 9 we might implement the full solution. (See the 9 bug: https://bugs.openjdk.java.net/browse/JDK-8029459). > > Basically in the fix proposed for 8u, default methods prune less specific methods from the result if they have the same discriptor. There are some complications due to preserving the old lookup order and the fact that we don?t want different results depending on the order of pairwise comparisons. Since this work and MethodArray in general is comparing descriptors bridges should not interact with this patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029674 > Patch: http://cr.openjdk.java.net/~jfranck/8029674/webrev.02/ > > *** Testing *** > > I made a test with a bit over 100 cases where 40 of the tests test behaviour that shouldn?t change (IE they pass both with and without the patch). The test is a bit vast, but I have commented some of the more interesting results. > > *** Performance *** > > The time complexity of this is O(defaultMethods * methods). getMethods() is already somewhat quadratic in complexity due to removing interface methods that have a concrete implementation. Also the result is cached so this is a one time increase per Class. > > I have done some experiments on a patched jdk without the cache and the performance looks decent: > > - Loading every class in rt.jar and calling getMethods() on every Class takes 8s on my laptop both before and after the patch. Perhaps not that surprising since there aren?t that many default methods in the jdk and this is probably dominated by IO. > > - Calling getMethods on a Class with 16K methods, 10% which are default methods, seem to take roughly 50% longer on my laptop (2,4 instead of 1,7 seconds). I?m working on converting this benchmark to JMH, but at least I don?t think I have made the most basic benchmark errors. > > If this turns out to be a performance problem I have an idea for an index that will make this O(methods sharing name * methods) for an addition of a few allocations, but I don?t expect this to be necessary. > > Thanks in advance > > cheers > /Joel From joel.franck at oracle.com Tue Jun 10 06:18:29 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 10 Jun 2014 08:18:29 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> References: <539365CF.4000806@oracle.com> <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> Message-ID: <31B8172F-24B0-4C5B-8EC6-945B022C4D8B@oracle.com> Hi Andrej, On 9 jun 2014, at 21:56, Andrej Golovnin wrote: > Hi Joel, > >> IIRC name isn?t actually interned with String.intern() but in the VM:s Symbol table as a name representing a (Java) method. Should be equivalent, as long as we don?t start comparing it with == with interned Strings. > > I think that's not true. > You are right, I was confusing name with the Symbol itself. cheers /Joel From joel.franck at oracle.com Tue Jun 10 06:41:44 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 10 Jun 2014 08:41:44 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <5396A257.7050908@gmail.com> References: <5396A257.7050908@gmail.com> Message-ID: <38790E94-BB1A-42A9-8982-86E2FCED7AD6@oracle.com> Hi Peter, Thanks for looking at this. I like the idea, but I think you need to use LangReflectAccess, which almost isn?t in use today. I would like to think some more about how to best do it so I think this should be a potential follow up. cheers /Joel On 10 jun 2014, at 08:14, Peter Levart wrote: > Hi Joel, > > I don't know if this is warranted, since this is on slow path (the resulting methods are cached) and the number of overloaded methods is typically not large, but the following MethodArray method: > > 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { > > could use a JavaLangAccess bridge to access the Method's parameter types without cloning the array each time. Especially since it's called many times inside nested loop (see removeLessSpecifics()) where the number of invocations grows quadratically with the MethodArray's length. Method.getParameterTypes() is only invoked for pairs of overloaded methods, so this might not be a real issue. > > Number of invocations could be halved though with this optimization of removeLessSpecific(): > > void removeLessSpecifics() { > if (!hasDefaults()) > return; > > for (int i = 1; i < length; i++) { > Method m = get(i); > if (m == null) > continue; > > for (int j = 0; j < i; j++) { > Method n = get(j); > if (n == null || !(m.isDefault() || n.isDefault())) > continue; > > if (!matchesNameAndDescriptor(m, n)) > continue; > > if (hasMoreSpecificClass(m, n)) > remove(j); > else if (hasMoreSpecificClass(n, m)) > remove(i); > } > } > } > > > Regards, Peter > > > On 05/07/2014 07:43 PM, Joel Borggr?n-Franck wrote: >> Hi, >> >> Since Java 8 the methods Class.getMethod() and Class.getMethods() can in some circumstances return methods that are not members of the class. This is due to a spec change in 8 not due to a code change. For this to happen you need to have an interface hierarchy that looks something like: >> >> interface I { void m(); } >> interface J extends I { void m(); } >> >> and either one of: >> >> interface K extends ***I,*** J {} >> class C implements ***I,*** J {} >> >> In Java 7 K.class.getMethods() would return [ I.m, J.m ]. The 7 spec is a bit vague but I have been convinced by experts that this is actually correct in 7. However this was changed in the spec for 8, now only J.m() is a member of K or C so the result should only contain [ J.m() ]. >> >> See the bug: >> https://bugs.openjdk.java.net/browse/JDK-8029674 >> for a more thorough discussion of this. >> >> The fix proposed for 8u (and 9 at first) is a partial fix that ensures that: >> >> - a concrete class does not have any abstract methods >> - nothing is changed unless someone introduces default methods into the interface hierarchy >> >> This is to minimise the behavioural compatibility concerns in a minor release. For 9 we might implement the full solution. (See the 9 bug: >> https://bugs.openjdk.java.net/browse/JDK-8029459 >> ). >> >> Basically in the fix proposed for 8u, default methods prune less specific methods from the result if they have the same discriptor. There are some complications due to preserving the old lookup order and the fact that we don?t want different results depending on the order of pairwise comparisons. Since this work and MethodArray in general is comparing descriptors bridges should not interact with this patch. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8029674 >> >> Patch: >> http://cr.openjdk.java.net/~jfranck/8029674/webrev.02/ >> >> >> *** Testing *** >> >> I made a test with a bit over 100 cases where 40 of the tests test behaviour that shouldn?t change (IE they pass both with and without the patch). The test is a bit vast, but I have commented some of the more interesting results. >> >> *** Performance *** >> >> The time complexity of this is O(defaultMethods * methods). getMethods() is already somewhat quadratic in complexity due to removing interface methods that have a concrete implementation. Also the result is cached so this is a one time increase per Class. >> >> I have done some experiments on a patched jdk without the cache and the performance looks decent: >> >> - Loading every class in rt.jar and calling getMethods() on every Class takes 8s on my laptop both before and after the patch. Perhaps not that surprising since there aren?t that many default methods in the jdk and this is probably dominated by IO. >> >> - Calling getMethods on a Class with 16K methods, 10% which are default methods, seem to take roughly 50% longer on my laptop (2,4 instead of 1,7 seconds). I?m working on converting this benchmark to JMH, but at least I don?t think I have made the most basic benchmark errors. >> >> If this turns out to be a performance problem I have an idea for an index that will make this O(methods sharing name * methods) for an addition of a few allocations, but I don?t expect this to be necessary. >> >> Thanks in advance >> >> cheers >> /Joel >> > From joel.franck at oracle.com Tue Jun 10 06:43:21 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 10 Jun 2014 08:43:21 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <53963E99.4000705@oracle.com> References: <539365CF.4000806@oracle.com> <37E7F2E0-184A-428E-A23C-487EAEE2D69A@gmail.com> <0874F647-1733-4D60-B5E8-1E9D19A7170F@gmail.com> <53963E99.4000705@oracle.com> Message-ID: Hi Joe, I?ll add a comment. cheers /Joel On 10 jun 2014, at 01:09, Joe Darcy wrote: > Thanks for the investigation Andrej. > > In any case, I'd prefer a comment noting the interned-ness (or mostly interned-ness, etc.) of the name to let other readers of the code using == rather than .equals is intentional and not a bug. > > Thanks, > > -Joe > > On 06/09/2014 12:56 PM, Andrej Golovnin wrote: >> Hi Joel, >> >>> IIRC name isn?t actually interned with String.intern() but in the VM:s Symbol table as a name representing a (Java) method. Should be equivalent, as long as we don?t start comparing it with == with interned Strings. >> I think that's not true. >> >> The following small test program prints true on the console: >> >> public class Test { >> >> public static void main(String... argv) throws Exception { >> Method m = Test.class.getMethod("main", String[].class); >> System.out.println(m.getName() == new String("main").intern()); >> } >> >> } >> >> And if you look into reflection.cpp at lines 787-789, you will see following code: >> >> Symbol* method_name = method->name(); >> oop name_oop = StringTable::intern(method_name, CHECK_NULL); >> Handle name = Handle(THREAD, name_oop); >> >> And later at the line 798 we have this code: >> >> java_lang_reflect_Method::set_name(mh(), name()); >> >> Therefore I would say the name is actually interned in terms of String.intern(). >> And you can compare the name of a method with == with interned Strings. >> >> The same applies to a name of a class and to a name of a field too. >> Please feel free to correct me. >> >> Best regards, >> Andrej Golovnin >> >> >>> cheers >>> /Joel >>> >>> On 07 Jun 2014, at 22:34, Andrej Golovnin wrote: >>> >>>> Hi Joe, >>>> >>>>> Sorry for the belated review. >>>>> >>>>> Generally the change looks good. One question, in >>>>> >>>>> 2803 private boolean matchesNameAndDescriptor(Method m1, Method m2) { >>>>> 2804 return m1.getReturnType() == m2.getReturnType() && >>>>> 2805 m1.getName() == m2.getName() && >>>>> 2806 arrayContentsEq(m1.getParameterTypes(), >>>>> 2807 m2.getParameterTypes()); >>>>> 2808 } >>>>> >>>>> Should the equality check on 2805 be .equals rather than == ? >>>>> >>>> "==" can be used in this case as the method name is interned by JVM. >>>> Here is the comment for the field "name" from java.lang.reflect.Method: >>>> >>>> // This is guaranteed to be interned by the VM in the 1.4 >>>> // reflection implementation >>>> private String name; >>>> >>>> BTW, in the old version of Class in the line 2766 there was already a similar check: >>>> >>>> 2764 if (m != null && >>>> 2765 m.getReturnType() == toRemove.getReturnType() && >>>> 2766 m.getName() == toRemove.getName() && >>>> 2767 arrayContentsEq(m.getParameterTypes(), >>>> 2768 toRemove.getParameterTypes())) { >>>> 2769 methods[i] = null; >>>> >>>> >>>> Best regards, >>>> Andrej Golovnin >>>> >>>> > From joel.franck at oracle.com Tue Jun 10 15:13:44 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 10 Jun 2014 17:13:44 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> Message-ID: <237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com> Hi, First, thanks for contributing this. Lets start with some process, have you signed the OCA? I have a lot of things on my plate right now so the progress of this might be slow, that doesn?t mean I have dropped it. I?m currently digesting the FieldAccessor mechanism, this will take some time. Comments inline, On 29 maj 2014, at 12:45, Andrej Golovnin wrote: > Hi Joel, > >>> When you have for example following method: >>> >>> public int method() { >>> return 0; >>> } >>> >>> And you invoke this method over the reflection API, >>> then the first N invocations are done via the native code. >> >> Yes, this is before inflation. Inflation happens after 15 calls IIRC, which is why I don?t think it matters from a performance standpoint. > > I would say, It depends on how do you define "matters". I personally don't care > about the native part in this case, as I always set "sun.reflect.noInflation=true". > But I think the changes to Hotspot are just needed for the correctness of the fix. The bug entry says this is a ?bug? but I disagree. There is nothing wrong with the current code, it just isn?t as efficient as it can be. IMO this is an enhancement, which influences trade-off like the HotSpot part. I won?t review the HotSpot change, and I don?t think it is that desirable given that we inflate after 15 calls, and it adds code to the VM. >> >> Your tests show that the valueOf caches are used which is good. However the byte code spinning is a core piece of reflection that is currently in production in countless places. A change in this area should not only be obviously correct and thouroghly tested > > That's why we do the code review. ;-) That is why we have tests :) You will have an easier time getting this accepted it you can show good code coverage of the fix in the current test suite for example. See if you can get jcov [1] up and running with this patch, I haven?t tried it on classes in sun.reflect but if it works and you can prove good coverage it will make my life easier, which directly translates to how easy it will be to get this patch committed. >> , you must show "real world? benefit. Ideally you should be able to show significant reduction in allocation in some application. > > I'm working on a product which has ca. 3 million lines of code and make > direct and indirect use of Reflection API. And in one of our use cases > I see, that JVM allocates ca. 9GB of Boolean objects. All of them are > allocated through the usage of Reflection API. Even that most of this > objects are allocated in TLABs and are removed by GC when the use > case is finished, I would say we have allocated 9GB of Boolean objects > to much. Or do you see it differently? > No, this was exactly the kind of real world benefit I was looking for. > Let me know, if you need more data or if I should write some test. Lets start with your current tests and the reflection tests in jdk/test and try to get a coverage metric. With the new build system, supply ??with-jtreg=some path? to configure and you can run a test suite called jdk_lang which includes reflection with make TEST=jdk_lang {CONCURRENCY=[num physical cores/4]} test where CONCURRENCY is optional. While the changes to the field accessors look easy, I need to work my way through the entire FieldAccessor implementation. I?ll have to get back to you on that. The summary in both tests could be improved, while the language mandates the caches, that doesn?t apply to reflection. Some comments: src/share/classes/sun/reflect/AccessorGenerator.java src/share/classes/sun/reflect/MethodAccessorGenerator.java looks fine from a casual glance. test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java: this need to be redesigned when dropping the vm part. I think it could also be interesting to see that the return from a direct method call .equals() the return from a reflective call. You might also consider setting the inflation threshold just high enough that you can make one pass uninflated checking just .eqials() then one pass in inflated code checking == as well. cheers /Joel [1] https://wiki.openjdk.java.net/display/CodeTools/jcov From henry.jen at oracle.com Wed Jun 11 00:00:16 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 10 Jun 2014 17:00:16 -0700 Subject: RFR: 8046485: Add missing @since tag under javax.swing.* Message-ID: <53979C10.1080307@oracle.com> Hi, Please review a trivial webrev that provides missing @since tag for elements under javax.swing, Essentially it's simply add @since 1.2 for all classes/interfaces/exception that are missing @since tag, as JDK 1.2 package.html has @since tag but was removed in 1.3. The @since tag is added to *.java instead of package.html so that we can have javac report javadoc via javax.lang.model.util.Elements.getDocComment(Element c). http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/ Cheers, Henry From ioi.lam at oracle.com Wed Jun 11 00:12:18 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 10 Jun 2014 17:12:18 -0700 Subject: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #1 Message-ID: <53979EE2.5000601@oracle.com> Hi Folks, Please review a the following clean up and refactoring of the AppCDS code http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v1/ https://bugs.openjdk.java.net/browse/JDK-8046070 Summary of fix: Clean up and refactor the Class Data Sharing (CDS) code, including: + Improve archive integrity checking + Support bytecode verification during archive dumping time + Allow the user to configure the CDS class list and archive file. + Allow future extension of the CDS class loading mechanism. Tests: JPRT (hotspot only, and jdk) UTE (vm.runtime.testlist, vm.quick.testlist, vm.parallel_class_loading.testlist) Thanks - Ioi From huizhe.wang at oracle.com Wed Jun 11 15:54:33 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 Jun 2014 08:54:33 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc Message-ID: <53987BB9.50407@oracle.com> Fix some typos in the JAXP documentation. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ Thanks, Joe From chris.hegarty at oracle.com Wed Jun 11 16:10:57 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Jun 2014 17:10:57 +0100 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <53987BB9.50407@oracle.com> References: <53987BB9.50407@oracle.com> Message-ID: <53987F91.2040606@oracle.com> Looks good to me Joe. -Chris. On 11/06/14 16:54, huizhe wang wrote: > Fix some typos in the JAXP documentation. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ > > Thanks, > Joe > > > From daniel.fuchs at oracle.com Wed Jun 11 16:11:29 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Jun 2014 18:11:29 +0200 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <53987BB9.50407@oracle.com> References: <53987BB9.50407@oracle.com> Message-ID: <53987FB1.3040708@oracle.com> Hi Joe, Looks good! -- daniel On 6/11/14 5:54 PM, huizhe wang wrote: > Fix some typos in the JAXP documentation. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ > > Thanks, > Joe > > > From huizhe.wang at oracle.com Wed Jun 11 16:28:58 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 Jun 2014 09:28:58 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <53987FB1.3040708@oracle.com> References: <53987BB9.50407@oracle.com> <53987FB1.3040708@oracle.com> Message-ID: <539883CA.9080309@oracle.com> Thanks Daniel, Chris! -Joe On 6/11/2014 9:11 AM, Daniel Fuchs wrote: > Hi Joe, > > Looks good! > > -- daniel > > On 6/11/14 5:54 PM, huizhe wang wrote: >> Fix some typos in the JAXP documentation. Please review. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >> >> Thanks, >> Joe >> >> >> > From Lance.Andersen at oracle.com Wed Jun 11 16:48:21 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 11 Jun 2014 12:48:21 -0400 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <53987BB9.50407@oracle.com> References: <53987BB9.50407@oracle.com> Message-ID: <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> Hi Joe, please change dont to don't I would get rid of the

otherwise it is OK Best Lance On Jun 11, 2014, at 11:54 AM, huizhe wang wrote: > Fix some typos in the JAXP documentation. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ > > Thanks, > Joe > > > 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 huizhe.wang at oracle.com Wed Jun 11 17:20:42 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 Jun 2014 10:20:42 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> Message-ID: <53988FEA.3090701@oracle.com> On 6/11/2014 9:48 AM, Lance Andersen wrote: > Hi Joe, > > please change > > dont > > to > > don't Oops, I committed too quickly. But this is a dev comment, so we can fix that in the next patch. > > I would get rid of the

Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: If you have more than one paragraph in the doc comment, separate the paragraphs with a |

|paragraph tag, as shown. [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html -Joe > > otherwise it is OK > > Best > Lance > On Jun 11, 2014, at 11:54 AM, huizhe wang > wrote: > >> Fix some typos in the JAXP documentation. Please review. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >> >> >> Thanks, >> Joe >> >> >> > > > > 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 Jun 11 17:24:07 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 11 Jun 2014 13:24:07 -0400 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <53988FEA.3090701@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> Message-ID: <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> Hi Joe,

is what I am talking about. On the myriad of clean-ups that were needed to be done in JDBC, getting rid of these type of

blah

blocks was needed and just use

Best Lance On Jun 11, 2014, at 1:20 PM, huizhe wang wrote: > > On 6/11/2014 9:48 AM, Lance Andersen wrote: >> Hi Joe, >> >> please change >> >> dont >> >> to >> >> don't > > Oops, I committed too quickly. But this is a dev comment, so we can fix that in the next patch. > >> >> I would get rid of the

> > Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: > If you have more than one paragraph in the doc comment, separate the paragraphs with a

paragraph tag, as shown. > > [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html > > -Joe > >> >> otherwise it is OK >> >> Best >> Lance >> On Jun 11, 2014, at 11:54 AM, huizhe wang wrote: >> >>> Fix some typos in the JAXP documentation. Please review. >>> >>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>> >>> Thanks, >>> Joe >>> >>> >>> >> >> >> >> >> 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 huizhe.wang at oracle.com Wed Jun 11 17:49:41 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 Jun 2014 10:49:41 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> Message-ID: <539896B5.1000102@oracle.com> And, here is a good discussion on closing tags: http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm -Joe On 6/11/2014 10:24 AM, Lance Andersen wrote: > Hi Joe, > >

is what I am talking about. > > On the myriad of clean-ups that were needed to be done in JDBC, > getting rid of these type of

blah

blocks was needed and just > use

> > Best > Lance > On Jun 11, 2014, at 1:20 PM, huizhe wang > wrote: > >> >> On 6/11/2014 9:48 AM, Lance Andersen wrote: >>> Hi Joe, >>> >>> please change >>> >>> dont >>> >>> to >>> >>> don't >> >> Oops, I committed too quickly. But this is a dev comment, so we can >> fix that in the next patch. >> >>> >>> I would get rid of the

>> >> Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: >> If you have more than one paragraph in the doc comment, separate the >> paragraphs with a |

|paragraph tag, as shown. >> >> [1] >> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html >> >> -Joe >> >>> >>> otherwise it is OK >>> >>> Best >>> Lance >>> On Jun 11, 2014, at 11:54 AM, huizhe wang >> > wrote: >>> >>>> Fix some typos in the JAXP documentation. Please review. >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>>> >>>> >>>> Thanks, >>>> Joe >>>> >>>> >>>> >>> >>> >>> >>> >>> 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 joel.franck at oracle.com Thu Jun 12 07:46:39 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 12 Jun 2014 09:46:39 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: Message-ID: <20140612074639.GB19704@oracle.com> Andrej, Joe, Peter, Thanks for looking at this, fix pushed yesterday. Peter, I filed a follow up: https://bugs.openjdk.java.net/browse/JDK-8046666 cheers /Joel From andrej.golovnin at gmail.com Thu Jun 12 19:03:53 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 12 Jun 2014 21:03:53 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com> Message-ID: Hi Joel, First, thanks for contributing this. Lets start with some process, have you > signed the OCA? > Yes, you can find me here: http://www.oracle.com/technetwork/community/oca-486395.html#g > > > > I would say, It depends on how do you define "matters". I personally > don't care > > about the native part in this case, as I always set > "sun.reflect.noInflation=true". > > But I think the changes to Hotspot are just needed for the correctness > of the fix. > > > I won?t review the HotSpot change, and David has already reviewed it and he didn't find any problems so far. > I don?t think it is that desirable given that we inflate after 15 calls, > and it adds code to the VM. > As I already wrote it is just needed for the consistent behavior. I understand that JDK is Oracle's product and it is up to you to accept or reject some changes. But as a user of your product I expect consistent behavior even if that means to add 47 lines of code (the most of them are just a simple switch statement) to HotSpot. If you reject the HotSpot change, then you should be prepared to reject from time to time bug reports about inconsistent behavior of the Java Reflection API. I'll file the first one. :-D > That is why we have tests :) You will have an easier time getting this > accepted it you can show good code coverage of the fix in the current test > suite for example. See if you can get jcov [1] up and running with this > patch, I haven?t tried it on classes in sun.reflect but if it works and you > can prove good coverage it will make my life easier, which directly > translates to how easy it will be to get this patch committed. > Do you have any documentation for jcov? The Wiki page doesn't contain any useful information about the usage of jcov. > Lets start with your current tests and the reflection tests in jdk/test > and try to get a coverage metric. With the new build system, supply > ??with-jtreg=some path? to configure and you can run a test suite called > jdk_lang which includes reflection with > > make TEST=jdk_lang {CONCURRENCY=[num physical cores/4]} test > Here are the results: Tests that passed 440 Tests that failed 2 Tests that had errors 1 Tests that were not run 5186 Total 5629 The failed tests: jdk/lambda/LambdaTranslationTest1.java jdk/lambda/LambdaTranslationTest2.java >From my standpoint, this tests have bugs. They make use of Locale sensitive APIs and assume that the current Locale has the same formatting rules as Locale.US. I use a locale with a different formatting rules. This tests fail even without my patch. And here is the test which had errors (this test fails also without my patch): sun/misc/CopyMemory.java The test fails with the following error message: Agent[1].stdout: # Agent[1].stdout: # A fatal error has been detected by the Java Runtime Environment: Agent[1].stdout: # Agent[1].stdout: # SIGSEGV (0xb) at pc=0x00000001029157cb, pid=76794, tid=16771 Agent[1].stdout: # Agent[1].stdout: # JRE version: OpenJDK Runtime Environment (9.0) (build 1.9.0-internal-andrej_2014_06_11_20_43-b00) Agent[1].stdout: # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-andrej_2014_06_11_20_43-b00 mixed mode bsd-amd64 compressed oops) Agent[1].stdout: # Problematic frame: Agent[1].stdout: # V [libjvm.dylib+0x5157cb] Unsafe_SetByte+0x5b Agent[1].stdout: # Agent[1].stdout: # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again Agent[1].stdout: # Agent[1].stdout: # An error report file with more information is saved as: Agent[1].stdout: # /Users/Andrej/Projects/jdk9/build/macosx-x86_64-normal-server-release/testoutput/jdk_lang/JTwork/scratch/0/hs_err_pid76794.log Agent[1].stdout: # Agent[1].stdout: # If you would like to submit a bug report, please visit: Agent[1].stdout: # http://bugreport.sun.com/bugreport/crash.jsp Agent[1].stdout: # It seems to be this bug https://bugs.openjdk.java.net/browse/JDK-8022407. But the bug is closed as fixed. Maybe we have a small regression. Btw, I'm using a MacBook Pro with the latest versions of Mac OS X and Xcode and JDK 9 master repository. If needed I can provide more information. > While the changes to the field accessors look easy, I need to work my way > through the entire FieldAccessor implementation. I?ll have to get back to > you on that. > > The summary in both tests could be improved, while the language mandates > the caches, that doesn?t apply to reflection. > > Some comments: > > src/share/classes/sun/reflect/AccessorGenerator.java > src/share/classes/sun/reflect/MethodAccessorGenerator.java > > looks fine from a casual glance. > > test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java: > > this need to be redesigned when dropping the vm part. I think it could > also be interesting to see that the return from a direct method call > .equals() the return from a reflective call. You might also consider > setting the inflation threshold just high enough that you can make one pass > uninflated checking just .eqials() then one pass in inflated code checking > == as well. > > Before I start to change something I think we should make the decision whether we are going to drop the VM part or not. As I already said, I'm for the consistent behavior and therefore against the dropping the VM part. But I'm only the user of the JDK. Maybe other members of the core team could share with us their opinion. Best regards, Andrej Golovnin From joel.franck at oracle.com Thu Jun 12 20:39:55 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 12 Jun 2014 22:39:55 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com> Message-ID: On 12 jun 2014, at 21:03, Andrej Golovnin wrote: >> >> That is why we have tests :) You will have an easier time getting this accepted it you can show good code coverage of the fix in the current test suite for example. See if you can get jcov [1] up and running with this patch, I haven?t tried it on classes in sun.reflect but if it works and you can prove good coverage it will make my life easier, which directly translates to how easy it will be to get this patch committed. >> > Do you have any documentation for jcov? The Wiki page doesn't contain any useful information about the usage of jcov. > If jtreg is compiled with jcov support, the jtreg help has all the info you need. Unfortunately It looks like the jtreg binaries you can find doesn?t include jcov. The Adopt OpenJDK group compiles jtreg, perhaps you can work with them to get a build of jtreg + jcov? I?ll generate the coverage report myself, I?m curious if it works with the core reflection code, but it will probably happen faster if you do it. cheers /Joel From joel.franck at oracle.com Fri Jun 13 08:46:50 2014 From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=) Date: Fri, 13 Jun 2014 10:46:50 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com> Message-ID: <20140613084650.GA24337@oracle.com> Hi Andrej, On 2014-06-12, Andrej Golovnin wrote: > > I don?t think it is that desirable given that we inflate after 15 calls, > > and it adds code to the VM. > > > > As I already wrote it is just needed for the consistent behavior. I don't want consistency here. I want the uninflated invocations/field gets to return new boxes for now. > > Lets start with your current tests and the reflection tests in jdk/test > > and try to get a coverage metric. With the new build system, supply > > ??with-jtreg=some path? to configure and you can run a test suite called > > jdk_lang which includes reflection with > > > > make TEST=jdk_lang {CONCURRENCY=[num physical cores/4]} test > > > The failed tests: > > jdk/lambda/LambdaTranslationTest1.java > jdk/lambda/LambdaTranslationTest2.java > > From my standpoint, this tests have bugs. They make use of Locale sensitive > APIs and assume that the current Locale has the same formatting rules as > Locale.US. I use a locale with a different formatting rules. This tests > fail even without my patch. > If you start a separate thread posting a reproducer I'll file bugs for this. > Before I start to change something I think we should make the decision > whether we are going to drop the VM part or not. I am dropping the VM part. Again, I have very limited time to work on this. We are looking into other changes in reflection that may or may not change and/or supersede this work. I think this would be a fine contribution to get in to 9, a good baseline to build further work upon, but the scope has to be limited. Given the risk-reward here my bar for accepting this is quite high. I'm looking forward to a rewritten test and some coverage information. cheers /Joel From otaviojava at java.net Sat Jun 14 13:46:20 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 14 Jun 2014 10:46:20 -0300 Subject: Long valueOf instead of new Long Message-ID: Reason: The Long class has cache and using it, will save memory and will faster than using create new instance of Long. webrev: https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip similar: https://bugs.openjdk.java.net/browse/JDK-8044461 -- 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 d02b062bc827 src/share/classes/sun/tools/java/BinaryConstantPool.java --- a/src/share/classes/sun/tools/java/BinaryConstantPool.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/java/BinaryConstantPool.java Sat Jun 14 10:29:45 2014 -0300 @@ -66,7 +66,7 @@ cpool[i] = new Float(in.readFloat()); break; case CONSTANT_LONG: - cpool[i++] = new Long(in.readLong()); + cpool[i++] = in.readLong(); break; case CONSTANT_DOUBLE: cpool[i++] = new Double(in.readDouble()); diff -r d02b062bc827 src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java --- a/src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java Sat Jun 14 10:29:45 2014 -0300 @@ -56,7 +56,7 @@ ObjectName mbeanName = new ObjectName(GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE + ",name=" + name); if (client.isRegistered(mbeanName)) { - gcMBeans.put(mbeanName, new Long(0)); + gcMBeans.put(mbeanName, 0L); } } catch (Exception e) { assert false; @@ -97,7 +97,7 @@ Long gcCount = e.getValue(); Long newCount = gc.getCollectionCount(); if (newCount > gcCount) { - gcMBeans.put(e.getKey(), new Long(newCount)); + gcMBeans.put(e.getKey(), newCount); lastGcInfo = gc.getLastGcInfo(); if (lastGcInfo.getEndTime() > lastGcEndTime) { gcId = lastGcInfo.getId(); diff -r d02b062bc827 src/share/classes/sun/tools/tree/BitNotExpression.java --- a/src/share/classes/sun/tools/tree/BitNotExpression.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/tree/BitNotExpression.java Sat Jun 14 10:29:45 2014 -0300 @@ -83,7 +83,7 @@ asm.add(where, opc_ldc, new Integer(-1)); asm.add(where, opc_ixor); } else { - asm.add(where, opc_ldc2_w, new Long(-1)); + asm.add(where, opc_ldc2_w, -1L); asm.add(where, opc_lxor); } } diff -r d02b062bc827 src/share/classes/sun/tools/tree/IncDecExpression.java --- a/src/share/classes/sun/tools/tree/IncDecExpression.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/tree/IncDecExpression.java Sat Jun 14 10:29:45 2014 -0300 @@ -131,7 +131,7 @@ asm.add(where, inc ? opc_iadd : opc_isub); break; case TC_LONG: - asm.add(where, opc_ldc2_w, new Long(1)); + asm.add(where, opc_ldc2_w, 1L); asm.add(where, inc ? opc_ladd : opc_lsub); break; case TC_FLOAT: diff -r d02b062bc827 src/share/classes/sun/tools/tree/LongExpression.java --- a/src/share/classes/sun/tools/tree/LongExpression.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/tree/LongExpression.java Sat Jun 14 10:29:45 2014 -0300 @@ -50,7 +50,7 @@ * Get the value */ public Object getValue() { - return new Long(value); + return value; } /** @@ -71,7 +71,7 @@ * Code */ public void codeValue(Environment env, Context ctx, Assembler asm) { - asm.add(where, opc_ldc2_w, new Long(value)); + asm.add(where, opc_ldc2_w, value); } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/security/action/GetLongAction.java --- a/src/share/classes/sun/security/action/GetLongAction.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/action/GetLongAction.java Sat Jun 14 10:29:45 2014 -0300 @@ -106,7 +106,7 @@ public Long run() { Long value = Long.getLong(theProp); if ((value == null) && defaultSet) - return new Long(defaultVal); + return defaultVal; return value; } } diff -r d02b062bc827 src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java --- a/src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java Sat Jun 14 10:29:45 2014 -0300 @@ -203,7 +203,7 @@ } public int hashCode() { - return new Long(pName).hashCode(); + return Long.valueOf(pName).hashCode(); } public byte[] export() throws GSSException { diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/KerberosTime.java --- a/src/share/classes/sun/security/krb5/internal/KerberosTime.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/KerberosTime.java Sat Jun 14 10:29:45 2014 -0300 @@ -188,7 +188,7 @@ } public int getMicroSeconds() { - Long temp_long = new Long((kerberosTime % 1000L) * 1000L); + Long temp_long = (kerberosTime % 1000L) * 1000L; return temp_long.intValue() + microSeconds; } @@ -250,7 +250,7 @@ } public int getSeconds() { - Long temp_long = new Long(kerberosTime / 1000L); + Long temp_long = kerberosTime / 1000L; return temp_long.intValue(); } diff -r d02b062bc827 src/share/classes/sun/security/tools/keytool/Main.java --- a/src/share/classes/sun/security/tools/keytool/Main.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/tools/keytool/Main.java Sat Jun 14 10:29:45 2014 -0300 @@ -1629,7 +1629,7 @@ Object[] source = {new Integer(keysize), privKey.getAlgorithm(), chain[0].getSigAlgName(), - new Long(validity), + validity, x500Name}; System.err.println(form.format(source)); } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/nio/ch/Util.java --- a/src/share/classes/sun/nio/ch/Util.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/nio/ch/Util.java Sat Jun 14 10:29:44 2014 -0300 @@ -329,7 +329,7 @@ try { dbb = (MappedByteBuffer)directByteBufferConstructor.newInstance( new Object[] { new Integer(size), - new Long(addr), + addr, fd, unmapper }); } catch (InstantiationException | @@ -374,7 +374,7 @@ try { dbb = (MappedByteBuffer)directByteBufferRConstructor.newInstance( new Object[] { new Integer(size), - new Long(addr), + addr, fd, unmapper }); } catch (InstantiationException | -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/management/GcInfoCompositeData.java --- a/src/share/classes/sun/management/GcInfoCompositeData.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/GcInfoCompositeData.java Sat Jun 14 10:29:44 2014 -0300 @@ -105,10 +105,10 @@ try { baseGcInfoItemValues = new Object[] { - new Long(info.getId()), - new Long(info.getStartTime()), - new Long(info.getEndTime()), - new Long(info.getDuration()), + info.getId(), + info.getStartTime(), + info.getEndTime(), + info.getDuration(), memoryUsageMapType.toOpenTypeData(info.getMemoryUsageBeforeGc()), memoryUsageMapType.toOpenTypeData(info.getMemoryUsageAfterGc()), }; diff -r d02b062bc827 src/share/classes/sun/management/HotspotThread.java --- a/src/share/classes/sun/management/HotspotThread.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/HotspotThread.java Sat Jun 14 10:29:44 2014 -0300 @@ -60,7 +60,7 @@ int numThreads = getInternalThreadTimes0(names, times); Map result = new HashMap<>(numThreads); for (int i = 0; i < numThreads; i++) { - result.put(names[i], new Long(times[i])); + result.put(names[i], times[i]); } return result; } diff -r d02b062bc827 src/share/classes/sun/management/MemoryNotifInfoCompositeData.java --- a/src/share/classes/sun/management/MemoryNotifInfoCompositeData.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/MemoryNotifInfoCompositeData.java Sat Jun 14 10:29:44 2014 -0300 @@ -60,7 +60,7 @@ final Object[] memoryNotifInfoItemValues = { memoryNotifInfo.getPoolName(), MemoryUsageCompositeData.toCompositeData(memoryNotifInfo.getUsage()), - new Long(memoryNotifInfo.getCount()), + memoryNotifInfo.getCount(), }; try { diff -r d02b062bc827 src/share/classes/sun/management/MemoryUsageCompositeData.java --- a/src/share/classes/sun/management/MemoryUsageCompositeData.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/MemoryUsageCompositeData.java Sat Jun 14 10:29:44 2014 -0300 @@ -56,10 +56,10 @@ // CONTENTS OF THIS ARRAY MUST BE SYNCHRONIZED WITH // memoryUsageItemNames! final Object[] memoryUsageItemValues = { - new Long(usage.getInit()), - new Long(usage.getUsed()), - new Long(usage.getCommitted()), - new Long(usage.getMax()), + usage.getInit(), + usage.getUsed(), + usage.getCommitted(), + usage.getMax(), }; try { diff -r d02b062bc827 src/share/classes/sun/management/ThreadInfoCompositeData.java --- a/src/share/classes/sun/management/ThreadInfoCompositeData.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/ThreadInfoCompositeData.java Sat Jun 14 10:29:44 2014 -0300 @@ -108,16 +108,16 @@ // CONTENTS OF THIS ARRAY MUST BE SYNCHRONIZED WITH // threadInfoItemNames! final Object[] threadInfoItemValues = { - new Long(threadInfo.getThreadId()), + threadInfo.getThreadId(), threadInfo.getThreadName(), threadInfo.getThreadState().name(), - new Long(threadInfo.getBlockedTime()), - new Long(threadInfo.getBlockedCount()), - new Long(threadInfo.getWaitedTime()), - new Long(threadInfo.getWaitedCount()), + threadInfo.getBlockedTime(), + threadInfo.getBlockedCount(), + threadInfo.getWaitedTime(), + threadInfo.getWaitedCount(), lockInfoData, threadInfo.getLockName(), - new Long(threadInfo.getLockOwnerId()), + threadInfo.getLockOwnerId(), threadInfo.getLockOwnerName(), stackTraceData, threadInfo.isSuspended(), diff -r d02b062bc827 src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java --- a/src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java Sat Jun 14 10:29:44 2014 -0300 @@ -43,7 +43,7 @@ } public Object getValue() { - return new Long(value); + return Long.valueOf(value); } /** diff -r d02b062bc827 src/share/classes/sun/management/counter/perf/PerfLongCounter.java --- a/src/share/classes/sun/management/counter/perf/PerfLongCounter.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/counter/perf/PerfLongCounter.java Sat Jun 14 10:29:44 2014 -0300 @@ -42,7 +42,7 @@ } public Object getValue() { - return new Long(lb.get(0)); + return Long.valueOf(lb.get(0)); } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -129,21 +129,21 @@ * Getter for the "JvmClassesUnloadedCount" variable. */ public Long getJvmClassesUnloadedCount() throws SnmpStatusException { - return new Long(getClassLoadingMXBean().getUnloadedClassCount()); + return getClassLoadingMXBean().getUnloadedClassCount(); } /** * Getter for the "JvmClassesTotalLoadedCount" variable. */ public Long getJvmClassesTotalLoadedCount() throws SnmpStatusException { - return new Long(getClassLoadingMXBean().getTotalLoadedClassCount()); + return getClassLoadingMXBean().getTotalLoadedClassCount(); } /** * Getter for the "JvmClassesLoadedCount" variable. */ public Long getJvmClassesLoadedCount() throws SnmpStatusException { - return new Long(getClassLoadingMXBean().getLoadedClassCount()); + return (long)getClassLoadingMXBean().getLoadedClassCount(); } } diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -115,7 +115,7 @@ t = getCompilationMXBean().getTotalCompilationTime(); else t = 0; - return new Long(t); + return t; } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -70,7 +70,7 @@ */ // Don't bother to uses the request contextual cache for this. public Long getJvmMemGCTimeMs() throws SnmpStatusException { - return new Long(gcm.getCollectionTime()); + return gcm.getCollectionTime(); } /** @@ -78,7 +78,7 @@ */ // Don't bother to uses the request contextual cache for this. public Long getJvmMemGCCount() throws SnmpStatusException { - return new Long(gcm.getCollectionCount()); + return gcm.getCollectionCount(); } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -191,7 +191,7 @@ */ public Long getJvmMemPoolMaxSize() throws SnmpStatusException { final long val = getMemoryUsage().getMax(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -200,7 +200,7 @@ */ public Long getJvmMemPoolUsed() throws SnmpStatusException { final long val = getMemoryUsage().getUsed(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -209,7 +209,7 @@ */ public Long getJvmMemPoolInitSize() throws SnmpStatusException { final long val = getMemoryUsage().getInit(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -218,7 +218,7 @@ */ public Long getJvmMemPoolCommitted() throws SnmpStatusException { final long val = getMemoryUsage().getCommitted(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -227,7 +227,7 @@ */ public Long getJvmMemPoolPeakMaxSize() throws SnmpStatusException { final long val = getPeakMemoryUsage().getMax(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -236,7 +236,7 @@ */ public Long getJvmMemPoolPeakUsed() throws SnmpStatusException { final long val = getPeakMemoryUsage().getUsed(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -245,7 +245,7 @@ */ public Long getJvmMemPoolPeakCommitted() throws SnmpStatusException { final long val = getPeakMemoryUsage().getCommitted(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -254,7 +254,7 @@ */ public Long getJvmMemPoolCollectMaxSize() throws SnmpStatusException { final long val = getCollectMemoryUsage().getMax(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -263,7 +263,7 @@ */ public Long getJvmMemPoolCollectUsed() throws SnmpStatusException { final long val = getCollectMemoryUsage().getUsed(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -272,7 +272,7 @@ */ public Long getJvmMemPoolCollectCommitted() throws SnmpStatusException { final long val = getCollectMemoryUsage().getCommitted(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -283,7 +283,7 @@ if (!pool.isUsageThresholdSupported()) return JvmMemoryImpl.Long0; final long val = pool.getUsageThreshold(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -334,7 +334,7 @@ if (!pool.isUsageThresholdSupported()) return JvmMemoryImpl.Long0; final long val = pool.getUsageThresholdCount(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -345,7 +345,7 @@ if (!pool.isCollectionUsageThresholdSupported()) return JvmMemoryImpl.Long0; final long val = pool.getCollectionUsageThreshold(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -399,7 +399,7 @@ if (!pool.isCollectionUsageThresholdSupported()) return JvmMemoryImpl.Long0; final long val = pool.getCollectionUsageThresholdCount(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return JvmMemoryImpl.Long0; } @@ -450,7 +450,7 @@ */ public synchronized Long getJvmMemPoolPeakReset() throws SnmpStatusException { - return new Long(jvmMemPoolPeakReset); + return jvmMemPoolPeakReset; } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -222,7 +222,7 @@ } } - static final Long Long0 = new Long(0); + static final Long Long0 = 0L; /** * Getter for the "JvmMemoryNonHeapMaxSize" variable. @@ -230,7 +230,7 @@ public Long getJvmMemoryNonHeapMaxSize() throws SnmpStatusException { final long val = getNonHeapMemoryUsage().getMax(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -239,7 +239,7 @@ */ public Long getJvmMemoryNonHeapCommitted() throws SnmpStatusException { final long val = getNonHeapMemoryUsage().getCommitted(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -248,7 +248,7 @@ */ public Long getJvmMemoryNonHeapUsed() throws SnmpStatusException { final long val = getNonHeapMemoryUsage().getUsed(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -257,7 +257,7 @@ */ public Long getJvmMemoryNonHeapInitSize() throws SnmpStatusException { final long val = getNonHeapMemoryUsage().getInit(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -266,7 +266,7 @@ */ public Long getJvmMemoryHeapMaxSize() throws SnmpStatusException { final long val = getHeapMemoryUsage().getMax(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -320,7 +320,7 @@ */ public Long getJvmMemoryHeapCommitted() throws SnmpStatusException { final long val = getHeapMemoryUsage().getCommitted(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -359,7 +359,7 @@ */ public Long getJvmMemoryHeapUsed() throws SnmpStatusException { final long val = getHeapMemoryUsage().getUsed(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -368,7 +368,7 @@ */ public Long getJvmMemoryHeapInitSize() throws SnmpStatusException { final long val = getHeapMemoryUsage().getInit(); - if (val > -1) return new Long(val); + if (val > -1) return val; else return Long0; } @@ -380,11 +380,11 @@ final long val = ManagementFactory.getMemoryMXBean(). getObjectPendingFinalizationCount(); - if (val > -1) return new Long((int)val); + if (val > -1) return val; // Should never happen... but stay safe all the same. // - else return new Long(0); + else return 0L; } static final MibLogger log = new MibLogger(JvmMemoryImpl.class); diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -259,14 +259,14 @@ * Getter for the "JvmRTUptimeMs" variable. */ public Long getJvmRTUptimeMs() throws SnmpStatusException { - return new Long(getRuntimeMXBean().getUptime()); + return getRuntimeMXBean().getUptime(); } /** * Getter for the "JvmRTStartTimeMs" variable. */ public Long getJvmRTStartTimeMs() throws SnmpStatusException { - return new Long(getRuntimeMXBean().getStartTime()); + return getRuntimeMXBean().getStartTime(); } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -231,7 +231,7 @@ log.debug("getJvmThreadInstCpuTimeNs", "Operation not supported: " + e); } - return new Long(l); + return l; } /** @@ -248,14 +248,14 @@ //Monitoring is disabled if(l == -1) l = 0; } - return new Long(l); + return l; } /** * Getter for the "JvmThreadInstBlockCount" variable. */ public Long getJvmThreadInstBlockCount() throws SnmpStatusException { - return new Long(info.getBlockedCount()); + return info.getBlockedCount(); } /** @@ -272,14 +272,14 @@ //Monitoring is disabled if(l == -1) l = 0; } - return new Long(l); + return l; } /** * Getter for the "JvmThreadInstWaitCount" variable. */ public Long getJvmThreadInstWaitCount() throws SnmpStatusException { - return new Long(info.getWaitedCount()); + return info.getWaitedCount(); } /** @@ -294,7 +294,7 @@ * Getter for the "JvmThreadInstId" variable. */ public Long getJvmThreadInstId() throws SnmpStatusException { - return new Long(info.getThreadId()); + return info.getThreadId(); } /** diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java Sat Jun 14 10:29:44 2014 -0300 @@ -303,28 +303,28 @@ * Getter for the "JvmThreadTotalStartedCount" variable. */ public Long getJvmThreadTotalStartedCount() throws SnmpStatusException { - return new Long(getThreadMXBean().getTotalStartedThreadCount()); + return getThreadMXBean().getTotalStartedThreadCount(); } /** * Getter for the "JvmThreadPeakCount" variable. */ public Long getJvmThreadPeakCount() throws SnmpStatusException { - return new Long(getThreadMXBean().getPeakThreadCount()); + return (long)getThreadMXBean().getPeakThreadCount(); } /** * Getter for the "JvmThreadDaemonCount" variable. */ public Long getJvmThreadDaemonCount() throws SnmpStatusException { - return new Long(getThreadMXBean().getDaemonThreadCount()); + return (long)getThreadMXBean().getDaemonThreadCount(); } /** * Getter for the "JvmThreadCount" variable. */ public Long getJvmThreadCount() throws SnmpStatusException { - return new Long(getThreadMXBean().getThreadCount()); + return (long)getThreadMXBean().getThreadCount(); } /** @@ -332,7 +332,7 @@ */ public synchronized Long getJvmThreadPeakCountReset() throws SnmpStatusException { - return new Long(jvmThreadPeakCountReset); + return jvmThreadPeakCountReset; } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java --- a/src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java Sat Jun 14 10:29:44 2014 -0300 @@ -66,7 +66,7 @@ * return type is guaranteed to be of type Long. */ public Object getValue() { - return new Long(lb.get(0)); + return Long.valueOf(lb.get(0)); } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java --- a/src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java Sat Jun 14 10:29:44 2014 -0300 @@ -458,7 +458,7 @@ Integer fiveHundred = new Integer(500); // *** Shared Longs - Long oneThousand = new Long(1000); + Long oneThousand = 1000L; LazyValue dialogPlain12 = t -> new FontUIResource(Font.DIALOG, Font.PLAIN, 12); -------------- next part -------------- diff -r d02b062bc827 src/share/classes/javax/management/loading/MLet.java --- a/src/share/classes/javax/management/loading/MLet.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/javax/management/loading/MLet.java Sat Jun 14 10:29:44 2014 -0300 @@ -1311,7 +1311,7 @@ if (type.compareTo("java.lang.Short") == 0) return new Short(param); if (type.compareTo("java.lang.Long") == 0) - return new Long(param); + return Long.valueOf(param); if (type.compareTo("java.lang.Integer") == 0) return new Integer(param); if (type.compareTo("java.lang.Float") == 0) diff -r d02b062bc827 src/share/classes/javax/management/modelmbean/RequiredModelMBean.java --- a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Sat Jun 14 10:29:44 2014 -0300 @@ -544,7 +544,7 @@ } // convert seconds to milliseconds for time comparison - currencyPeriod = ((new Long(expTime)).longValue()) * 1000; + currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000; if (currencyPeriod < 0) { /* if currencyTimeLimit is -1 then value is never cached */ returnCachedValue = false; @@ -580,7 +580,7 @@ if (tStamp == null) tStamp = "0"; - long lastTime = (new Long(tStamp)).longValue(); + long lastTime = (Long.valueOf(tStamp)).longValue(); if (tracing) { MODELMBEAN_LOGGER.logp(Level.FINER, -------------- next part -------------- diff -r d02b062bc827 src/share/classes/java/text/DecimalFormat.java --- a/src/share/classes/java/text/DecimalFormat.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/java/text/DecimalFormat.java Sat Jun 14 10:29:44 2014 -0300 @@ -2094,7 +2094,7 @@ } return gotDouble ? - (Number)new Double(doubleResult) : (Number)new Long(longResult); + (Number)new Double(doubleResult) : (Number)Long.valueOf(longResult); } } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/java/awt/image/renderable/ParameterBlock.java --- a/src/share/classes/java/awt/image/renderable/ParameterBlock.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/java/awt/image/renderable/ParameterBlock.java Sat Jun 14 10:29:44 2014 -0300 @@ -381,7 +381,7 @@ * the specified parameter. */ public ParameterBlock add(long l) { - return add(new Long(l)); + return add(l); } /** @@ -505,7 +505,7 @@ * the specified parameter. */ public ParameterBlock set(long l, int index) { - return set(new Long(l), index); + return set(l, index); } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java Sat Jun 14 10:29:44 2014 -0300 @@ -2502,7 +2502,7 @@ case ClassWriter.FLOAT: return new Float(Float.intBitsToFloat(readInt(index))); case ClassWriter.LONG: - return new Long(readLong(index)); + return Long.valueOf(readLong(index)); case ClassWriter.DOUBLE: return new Double(Double.longBitsToDouble(readLong(index))); case ClassWriter.CLASS: diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java Sat Jun 14 10:29:44 2014 -0300 @@ -422,7 +422,7 @@ if (value == 0L || value == 1L) { mv.visitInsn(Opcodes.LCONST_0 + (int) value); } else { - mv.visitLdcInsn(new Long(value)); + mv.visitLdcInsn(value); } } diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java Sat Jun 14 10:29:44 2014 -0300 @@ -745,7 +745,7 @@ if (cst == 0L || cst == 1L) { mv.visitInsn(Opcodes.LCONST_0 + (int) cst); } else { - mv.visitLdcInsn(new Long(cst)); + mv.visitLdcInsn(cst); } } diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java Sat Jun 14 10:29:44 2014 -0300 @@ -366,8 +366,7 @@ protected void addSVUID(long svuid) { FieldVisitor fv = super.visitField(Opcodes.ACC_FINAL - + Opcodes.ACC_STATIC, "serialVersionUID", "J", null, new Long( - svuid)); + + Opcodes.ACC_STATIC, "serialVersionUID", "J", null, svuid); if (fv != null) { fv.visitEnd(); } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat Jun 14 10:29:43 2014 -0300 @@ -935,7 +935,7 @@ try { methodInfo = loc.sourceName() + MessageOutput.format("line number", - new Object [] {new Long(lineNumber)}); + new Object [] {Long.valueOf(lineNumber)}); } catch (AbsentInformationException e) { methodInfo = MessageOutput.format("unknown"); } @@ -946,7 +946,7 @@ meth.declaringType().name(), meth.name(), methodInfo, - new Long(pc)}); + Long.valueOf(pc)}); } else { MessageOutput.println("stack frame dump", new Object [] {new Integer(frameNumber + 1), diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java Sat Jun 14 10:29:43 2014 -0300 @@ -102,7 +102,7 @@ if ((id & ~Snapshot.SMALL_ID_MASK) == 0) { return new Integer((int)id); } else { - return new Long(id); + return id; } } diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java --- a/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java Sat Jun 14 10:29:43 2014 -0300 @@ -583,7 +583,7 @@ if (identifierSize == 4) { return new Integer((int)id); } else { - return new Long(id); + return id; } } diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java --- a/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java Sat Jun 14 10:29:43 2014 -0300 @@ -215,7 +215,7 @@ long id = readID(); byte[] chars = new byte[(int)length - identifierSize]; in.readFully(chars); - names.put(new Long(id), new String(chars)); + names.put(id, new String(chars)); break; } case HPROF_LOAD_CLASS: { @@ -223,7 +223,7 @@ long classID = readID(); int stackTraceSerialNo = in.readInt(); long classNameID = readID(); - Long classIdI = new Long(classID); + Long classIdI = classID; String nm = getNameFromID(classNameID).replace('/', '.'); classNameFromObjectID.put(classIdI, nm); if (classNameFromSerialNo != null) { @@ -303,7 +303,7 @@ warn("Weird stack frame line number: " + lineNumber); lineNumber = StackFrame.LINE_NUMBER_UNKNOWN; } - stackFrames.put(new Long(id), + stackFrames.put(id, new StackFrame(methodName, methodSig, className, sourceFile, lineNumber)); @@ -319,7 +319,7 @@ StackFrame[] frames = new StackFrame[in.readInt()]; for (int i = 0; i < frames.length; i++) { long fid = readID(); - frames[i] = stackFrames.get(new Long(fid)); + frames[i] = stackFrames.get(fid); if (frames[i] == null) { throw new IOException("Stack frame " + toHex(fid) + " not found"); } @@ -619,7 +619,7 @@ } private String getNameFromID(long id) throws IOException { - return getNameFromID(new Long(id)); + return getNameFromID(id); } private String getNameFromID(Long id) throws IOException { @@ -703,7 +703,7 @@ String signature = "" + ((char) type); fields[i] = new JavaField(fieldName, signature); } - String name = classNameFromObjectID.get(new Long(id)); + String name = classNameFromObjectID.get(id); if (name == null) { warn("Class name not found for " + toHex(id)); name = "unknown-name@" + toHex(id); diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java --- a/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Sat Jun 14 10:29:43 2014 -0300 @@ -63,9 +63,9 @@ } Long count = referrersStat.get(cl); if (count == null) { - count = new Long(1); + count = 1L; } else { - count = new Long(count.longValue() + 1); + count = count + 1L; } referrersStat.put(cl, count); } @@ -75,9 +75,9 @@ JavaClass cl = obj.getClazz(); Long count = refereesStat.get(cl); if (count == null) { - count = new Long(1); + count = 1L; } else { - count = new Long(count.longValue() + 1); + count = count + 1L; } refereesStat.put(cl, count); } diff -r d02b062bc827 src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Sat Jun 14 10:29:43 2014 -0300 @@ -781,7 +781,7 @@ type.setSignature(signature); } - typesByID.put(new Long(id), type); + typesByID.put(id, type); typesBySignature.add(type); if ((vm.traceFlags & VirtualMachine.TRACE_REFTYPES) != 0) { @@ -809,7 +809,7 @@ if (comp == 0) { matches++; iter.remove(); - typesByID.remove(new Long(type.ref())); + typesByID.remove(type.ref()); if ((vm.traceFlags & VirtualMachine.TRACE_REFTYPES) != 0) { vm.printTrace("Uncaching ReferenceType, sig=" + signature + ", id=" + type.ref()); @@ -895,7 +895,7 @@ ReferenceTypeImpl retType = null; synchronized (this) { if (typesByID != null) { - retType = (ReferenceTypeImpl)typesByID.get(new Long(id)); + retType = (ReferenceTypeImpl)typesByID.get(id); } if (retType == null) { retType = addReferenceType(id, tag, signature); @@ -1247,7 +1247,7 @@ return null; } ObjectReferenceImpl object = null; - Long key = new Long(id); + Long key = id; /* * Attempt to retrieve an existing object object reference @@ -1313,7 +1313,7 @@ // Handle any queue elements that are not strongly reachable processQueue(); - SoftObjectReference ref = objectsByID.remove(new Long(object.ref())); + SoftObjectReference ref = objectsByID.remove(object.ref()); if (ref != null) { batchForDispose(ref); } else { -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java --- a/src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java Sat Jun 14 10:29:43 2014 -0300 @@ -110,7 +110,7 @@ * */ public SolarisNumericGroupPrincipal(long name, boolean primaryGroup) { - this.name = (new Long(name)).toString(); + this.name = Long.valueOf(name).toString(); this.primaryGroup = primaryGroup; } @@ -137,7 +137,7 @@ * SolarisNumericGroupPrincipal as a long. */ public long longValue() { - return ((new Long(name)).longValue()); + return Long.valueOf(name); } /** diff -r d02b062bc827 src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java --- a/src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java Sat Jun 14 10:29:43 2014 -0300 @@ -96,7 +96,7 @@ * represented as a long. */ public SolarisNumericUserPrincipal(long name) { - this.name = (new Long(name)).toString(); + this.name = Long.valueOf(name).toString(); } /** @@ -122,7 +122,7 @@ * SolarisNumericUserPrincipal as a long. */ public long longValue() { - return ((new Long(name)).longValue()); + return Long.valueOf(name); } /** diff -r d02b062bc827 src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java --- a/src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java Sat Jun 14 10:29:43 2014 -0300 @@ -102,7 +102,7 @@ * */ public UnixNumericGroupPrincipal(long name, boolean primaryGroup) { - this.name = (new Long(name)).toString(); + this.name = Long.valueOf(name).toString(); this.primaryGroup = primaryGroup; } @@ -129,7 +129,7 @@ * UnixNumericGroupPrincipal as a long. */ public long longValue() { - return ((new Long(name)).longValue()); + return Long.valueOf(name); } /** diff -r d02b062bc827 src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java --- a/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java Sat Jun 14 10:29:43 2014 -0300 @@ -87,7 +87,7 @@ * represented as a long. */ public UnixNumericUserPrincipal(long name) { - this.name = (new Long(name)).toString(); + this.name = Long.valueOf(name).toString(); } /** @@ -113,7 +113,7 @@ * UnixNumericUserPrincipal as a long. */ public long longValue() { - return ((new Long(name)).longValue()); + return Long.valueOf(name); } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java Sat Jun 14 10:29:43 2014 -0300 @@ -84,7 +84,7 @@ * @return The Long representation of the value. */ public Long toLong() { - return new Long(value) ; + return value; } /** diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpInt.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpInt.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpInt.java Sat Jun 14 10:29:43 2014 -0300 @@ -130,7 +130,7 @@ * @return The Long representation of the value. */ public Long toLong() { - return new Long(value) ; + return value; } /** diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Sat Jun 14 10:29:43 2014 -0300 @@ -136,7 +136,7 @@ */ public boolean isNestedArc(long arc) { if (subgroups == null) return false; - Object obj = subgroups.get(new Long(arc)); + Object obj = subgroups.get(arc); // if the arc is registered in the hashtable, // it leads to a subgroup. return (obj != null); @@ -260,7 +260,7 @@ * */ void registerNestedArc(long arc) { - Long obj = new Long(arc); + Long obj = arc; if (subgroups == null) subgroups = new Hashtable<>(); // registers the arc in the hashtable. subgroups.put(obj,obj); diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java --- a/src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java Sat Jun 14 10:29:43 2014 -0300 @@ -858,7 +858,7 @@ */ @Override public Long getSnmpOutTraps() { - return new Long(snmpOutTraps); + return (long)snmpOutTraps; } /** @@ -868,7 +868,7 @@ */ @Override public Long getSnmpOutGetResponses() { - return new Long(snmpOutGetResponses); + return (long)snmpOutGetResponses; } /** @@ -878,7 +878,7 @@ */ @Override public Long getSnmpOutGenErrs() { - return new Long(snmpOutGenErrs); + return (long) snmpOutGenErrs; } /** @@ -888,7 +888,7 @@ */ @Override public Long getSnmpOutBadValues() { - return new Long(snmpOutBadValues); + return (long)snmpOutBadValues; } /** @@ -898,7 +898,7 @@ */ @Override public Long getSnmpOutNoSuchNames() { - return new Long(snmpOutNoSuchNames); + return (long)snmpOutNoSuchNames; } /** @@ -908,7 +908,7 @@ */ @Override public Long getSnmpOutTooBigs() { - return new Long(snmpOutTooBigs); + return (long)snmpOutTooBigs; } /** @@ -918,7 +918,7 @@ */ @Override public Long getSnmpInASNParseErrs() { - return new Long(snmpInASNParseErrs); + return (long)snmpInASNParseErrs; } /** @@ -928,7 +928,7 @@ */ @Override public Long getSnmpInBadCommunityUses() { - return new Long(snmpInBadCommunityUses); + return (long)snmpInBadCommunityUses; } /** @@ -939,7 +939,7 @@ */ @Override public Long getSnmpInBadCommunityNames() { - return new Long(snmpInBadCommunityNames); + return (long)snmpInBadCommunityNames; } /** @@ -949,7 +949,7 @@ */ @Override public Long getSnmpInBadVersions() { - return new Long(snmpInBadVersions); + return (long)snmpInBadVersions; } /** @@ -959,7 +959,7 @@ */ @Override public Long getSnmpOutPkts() { - return new Long(snmpOutPkts); + return (long)snmpOutPkts; } /** @@ -969,7 +969,7 @@ */ @Override public Long getSnmpInPkts() { - return new Long(snmpInPkts); + return (long)snmpInPkts; } /** @@ -979,7 +979,7 @@ */ @Override public Long getSnmpInGetRequests() { - return new Long(snmpInGetRequests); + return (long)snmpInGetRequests; } /** @@ -989,7 +989,7 @@ */ @Override public Long getSnmpInGetNexts() { - return new Long(snmpInGetNexts); + return (long)snmpInGetNexts; } /** @@ -999,7 +999,7 @@ */ @Override public Long getSnmpInSetRequests() { - return new Long(snmpInSetRequests); + return (long)snmpInSetRequests; } /** @@ -1009,7 +1009,7 @@ */ @Override public Long getSnmpInTotalSetVars() { - return new Long(snmpInTotalSetVars); + return (long)snmpInTotalSetVars; } /** @@ -1019,7 +1019,7 @@ */ @Override public Long getSnmpInTotalReqVars() { - return new Long(snmpInTotalReqVars); + return (long)snmpInTotalReqVars; } /** @@ -1032,7 +1032,7 @@ */ @Override public Long getSnmpSilentDrops() { - return new Long(snmpSilentDrops); + return (long)snmpSilentDrops; } /** @@ -1045,7 +1045,7 @@ */ @Override public Long getSnmpProxyDrops() { - return new Long(0); + return 0L; } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java --- a/src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java Sat Jun 14 10:29:43 2014 -0300 @@ -421,7 +421,7 @@ try { return Long.getLong(propName, defVal); } catch (SecurityException e) { - return new Long(defVal); + return defVal; } } }); diff -r d02b062bc827 src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java --- a/src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java Sat Jun 14 10:29:43 2014 -0300 @@ -221,7 +221,7 @@ return; NamingEvent e = new NamingEvent(eventSrc, NamingEvent.OBJECT_ADDED, - newBd, null, new Long(changeID)); + newBd, null, changeID); support.queueEvent(e, namingListeners); } @@ -233,7 +233,7 @@ return; NamingEvent e = new NamingEvent(eventSrc, NamingEvent.OBJECT_REMOVED, - null, oldBd, new Long(changeID)); + null, oldBd, changeID); support.queueEvent(e, namingListeners); } @@ -248,7 +248,7 @@ Binding oldBd = new Binding(newBd.getName(), null, newBd.isRelative()); NamingEvent e = new NamingEvent( - eventSrc, NamingEvent.OBJECT_CHANGED, newBd, oldBd, new Long(changeID)); + eventSrc, NamingEvent.OBJECT_CHANGED, newBd, oldBd, changeID); support.queueEvent(e, namingListeners); } @@ -273,7 +273,7 @@ } NamingEvent e = new NamingEvent( - eventSrc, NamingEvent.OBJECT_RENAMED, newBd, oldBd, new Long(changeID)); + eventSrc, NamingEvent.OBJECT_RENAMED, newBd, oldBd, changeID); support.queueEvent(e, namingListeners); } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java --- a/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Sat Jun 14 10:29:43 2014 -0300 @@ -616,7 +616,7 @@ return index; } - Long l1 = new Long(stream.getStreamPosition()); + Long l1 = stream.getStreamPosition(); imageStartPosition.add(l1); ++index; } diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java --- a/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java Sat Jun 14 10:29:43 2014 -0300 @@ -367,10 +367,10 @@ // Now we are at the first image if there are any, so add it // to the list if (hasNextImage()) { - imagePositions.add(new Long(iis.getStreamPosition())); + imagePositions.add(iis.getStreamPosition()); } } else { // Not tables only, so add original pos to the list - imagePositions.add(new Long(savePos)); + imagePositions.add(savePos); // And set current image since we've read it now currentImage = 0; } @@ -498,7 +498,7 @@ if (!hasNextImage()) { throw new IndexOutOfBoundsException(); } - pos = new Long(iis.getStreamPosition()); + pos = iis.getStreamPosition(); imagePositions.add(pos); if (seekForwardOnly) { iis.flushBefore(pos.longValue()); From otaviojava at java.net Sat Jun 14 16:38:21 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 14 Jun 2014 13:38:21 -0300 Subject: Character, Byte, Short valueOf instead of new instance Message-ID: Reason: The Character, Byte, Short classes have cache and using it, will save memory and will faster than using create new instance. webrev: https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip similar: https://bugs.openjdk.java.net/browse/JDK-8044461 -- 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 d02b062bc827 src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Jun 14 13:33:30 2014 -0300 @@ -342,14 +342,14 @@ Object result; if (primitiveToWrapper.containsKey(type)) { if (type.equals(Character.TYPE.getName())) { - result = new Character(value.charAt(0)); + result = value.charAt(0); } else { result = newStringConstructor( ((Class) primitiveToWrapper.get(type)).getName(), value); } } else if (type.equals(Character.class.getName())) { - result = new Character(value.charAt(0)); + result = value.charAt(0); } else if (Number.class.isAssignableFrom(Utils.getClass(type))) { result = createNumberFromStringValue(value); } else if (value == null || value.equals("null")) { -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/security/pkcs/PKCS9Attribute.java --- a/src/share/classes/sun/security/pkcs/PKCS9Attribute.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/pkcs/PKCS9Attribute.java Sat Jun 14 13:33:30 2014 -0300 @@ -309,26 +309,26 @@ */ private static final Byte[][] PKCS9_VALUE_TAGS = { null, - {new Byte(DerValue.tag_IA5String)}, // EMailAddress - {new Byte(DerValue.tag_IA5String), // UnstructuredName - new Byte(DerValue.tag_PrintableString)}, - {new Byte(DerValue.tag_ObjectId)}, // ContentType - {new Byte(DerValue.tag_OctetString)}, // MessageDigest - {new Byte(DerValue.tag_UtcTime)}, // SigningTime - {new Byte(DerValue.tag_Sequence)}, // Countersignature - {new Byte(DerValue.tag_PrintableString), - new Byte(DerValue.tag_T61String)}, // ChallengePassword - {new Byte(DerValue.tag_PrintableString), - new Byte(DerValue.tag_T61String)}, // UnstructuredAddress - {new Byte(DerValue.tag_SetOf)}, // ExtendedCertificateAttributes - {new Byte(DerValue.tag_Sequence)}, // issuerAndSerialNumber + {DerValue.tag_IA5String}, // EMailAddress + {DerValue.tag_IA5String, // UnstructuredName + DerValue.tag_PrintableString}, + {DerValue.tag_ObjectId}, // ContentType + {DerValue.tag_OctetString}, // MessageDigest + {DerValue.tag_UtcTime}, // SigningTime + {DerValue.tag_Sequence}, // Countersignature + {DerValue.tag_PrintableString, + DerValue.tag_T61String}, // ChallengePassword + {DerValue.tag_PrintableString, + DerValue.tag_T61String}, // UnstructuredAddress + {DerValue.tag_SetOf}, // ExtendedCertificateAttributes + {DerValue.tag_Sequence}, // issuerAndSerialNumber null, null, null, - {new Byte(DerValue.tag_Sequence)}, // extensionRequest - {new Byte(DerValue.tag_Sequence)}, // SMIMECapability - {new Byte(DerValue.tag_Sequence)}, // SigningCertificate - {new Byte(DerValue.tag_Sequence)} // SignatureTimestampToken + {DerValue.tag_Sequence}, // extensionRequest + {DerValue.tag_Sequence}, // SMIMECapability + {DerValue.tag_Sequence}, // SigningCertificate + {DerValue.tag_Sequence} // SignatureTimestampToken }; private static final Class[] VALUE_CLASSES = new Class[18]; @@ -511,7 +511,7 @@ // check for illegal element tags Byte tag; for (int i=0; i < elems.length; i++) { - tag = new Byte(elems[i].tag); + tag = elems[i].tag; if (indexOf(tag, PKCS9_VALUE_TAGS[index], 0) == -1) throwTagException(tag); diff -r d02b062bc827 src/share/classes/sun/security/x509/AVA.java --- a/src/share/classes/sun/security/x509/AVA.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/security/x509/AVA.java Sat Jun 14 13:33:30 2014 -0300 @@ -517,7 +517,7 @@ if (hexDigits.indexOf(Character.toUpperCase((char)c2)) >= 0) { int hi = Character.digit((char)c1, 16); int lo = Character.digit((char)c2, 16); - return new Byte((byte)((hi<<4) + lo)); + return (byte)((hi<<4) + lo); } else { throw new IOException ("escaped hex value must include two valid digits"); -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/misc/ProxyGenerator.java --- a/src/share/classes/sun/misc/ProxyGenerator.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/misc/ProxyGenerator.java Sat Jun 14 13:33:30 2014 -0300 @@ -1885,7 +1885,7 @@ "late constant pool addition: " + key); } short i = addEntry(new ValueEntry(key)); - map.put(key, new Short(i)); + map.put(key, i); return i; } } @@ -1903,7 +1903,7 @@ throw new InternalError("late constant pool addition"); } short i = addEntry(e); - map.put(e, new Short(i)); + map.put(e, i); return i; } } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Sat Jun 14 13:33:30 2014 -0300 @@ -139,7 +139,7 @@ "Unexpected exception: " + r); log.debug("getJvmThreadInstState",r); } - Byte[] result = { new Byte(bitmap[0]), new Byte(bitmap[1]) }; + Byte[] result = {bitmap[0], bitmap[1]}; return result; } } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java Sat Jun 14 13:33:30 2014 -0300 @@ -1858,7 +1858,7 @@ break; case 'B': // pointer to CONSTANT_Byte av.visit(name, - new Byte((byte) readInt(items[readUnsignedShort(v)]))); + (byte) readInt(items[readUnsignedShort(v)])); v += 2; break; case 'Z': // pointer to CONSTANT_Boolean @@ -1868,13 +1868,12 @@ v += 2; break; case 'S': // pointer to CONSTANT_Short - av.visit(name, new Short( - (short) readInt(items[readUnsignedShort(v)]))); + av.visit(name, + (short) readInt(items[readUnsignedShort(v)])); v += 2; break; case 'C': // pointer to CONSTANT_Char - av.visit(name, new Character( - (char) readInt(items[readUnsignedShort(v)]))); + av.visit(name, (char) readInt(items[readUnsignedShort(v)])); v += 2; break; case 's': // pointer to CONSTANT_Utf8 -------------- next part -------------- diff -r d02b062bc827 src/share/classes/javax/management/loading/MLet.java --- a/src/share/classes/javax/management/loading/MLet.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/javax/management/loading/MLet.java Sat Jun 14 13:33:30 2014 -0300 @@ -1307,9 +1307,9 @@ if (type.compareTo("java.lang.Boolean") == 0) return Boolean.valueOf(param); if (type.compareTo("java.lang.Byte") == 0) - return new Byte(param); + return Byte.valueOf(param); if (type.compareTo("java.lang.Short") == 0) - return new Short(param); + return Short.valueOf(param); if (type.compareTo("java.lang.Long") == 0) return new Long(param); if (type.compareTo("java.lang.Integer") == 0) -------------- next part -------------- diff -r d02b062bc827 src/share/classes/java/beans/Statement.java --- a/src/share/classes/java/beans/Statement.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/java/beans/Statement.java Sat Jun 14 13:33:29 2014 -0300 @@ -248,7 +248,7 @@ // ignored elsewhere. if (target == Character.class && arguments.length == 1 && argClasses[0] == String.class) { - return new Character(((String)arguments[0]).charAt(0)); + return ((String)arguments[0]).charAt(0); } try { m = ConstructorFinder.findConstructor((Class)target, argClasses); -------------- next part -------------- diff -r d02b062bc827 src/share/classes/java/awt/Component.java --- a/src/share/classes/java/awt/Component.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/java/awt/Component.java Sat Jun 14 13:33:29 2014 -0300 @@ -8506,7 +8506,7 @@ if (changeSupport == null || oldValue == newValue) { return; } - firePropertyChange(propertyName, new Character(oldValue), new Character(newValue)); + firePropertyChange(propertyName, oldValue, newValue); } /** diff -r d02b062bc827 src/share/classes/java/awt/image/renderable/ParameterBlock.java --- a/src/share/classes/java/awt/image/renderable/ParameterBlock.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/java/awt/image/renderable/ParameterBlock.java Sat Jun 14 13:33:29 2014 -0300 @@ -337,7 +337,7 @@ * the specified parameter. */ public ParameterBlock add(byte b) { - return add(new Byte(b)); + return add(b); } /** @@ -348,7 +348,7 @@ * the specified parameter. */ public ParameterBlock add(char c) { - return add(new Character(c)); + return add(c); } /** @@ -359,7 +359,7 @@ * the specified parameter. */ public ParameterBlock add(short s) { - return add(new Short(s)); + return add(s); } /** @@ -441,7 +441,7 @@ * the specified parameter. */ public ParameterBlock set(byte b, int index) { - return set(new Byte(b), index); + return set(b, index); } /** @@ -457,7 +457,7 @@ * the specified parameter. */ public ParameterBlock set(char c, int index) { - return set(new Character(c), index); + return set(c, index); } /** @@ -473,7 +473,7 @@ * the specified parameter. */ public ParameterBlock set(short s, int index) { - return set(new Short(s), index); + return set(s, index); } /** -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java Sat Jun 14 13:33:29 2014 -0300 @@ -1460,7 +1460,7 @@ if (logger.isLoggable(Level.INFO)) { logger.log(Level.INFO, "DIGEST39:Incorrect padding: {0}", - new Byte(msgWithPadding[msgWithPadding.length - 1])); + msgWithPadding[msgWithPadding.length - 1]); } return EMPTY_BYTE_ARRAY; } diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java --- a/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java Sat Jun 14 13:33:29 2014 -0300 @@ -241,7 +241,7 @@ "KRB5CLNT05:Challenge [unwrapped]:", gssOutToken); } logger.log(Level.FINE, "KRB5CLNT06:Server protections: {0}", - new Byte(gssOutToken[0])); + gssOutToken[0]); } // Client selects preferred protection @@ -293,7 +293,7 @@ if (logger.isLoggable(Level.FINE)) { logger.log(Level.FINE, "KRB5CLNT08:Selected protection: {0}; privacy: {1}; integrity: {2}", - new Object[]{new Byte(selectedQop), + new Object[]{selectedQop, Boolean.valueOf(privacy), Boolean.valueOf(integrity)}); } diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java --- a/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java Sat Jun 14 13:33:29 2014 -0300 @@ -221,7 +221,7 @@ if (logger.isLoggable(Level.FINE)) { logger.log(Level.FINE, "KRB5SRV06:Supported protections: {0}; recv max buf size: {1}", - new Object[]{new Byte(allQop), + new Object[]{allQop, new Integer(recvMaxBufSize)}); } @@ -288,7 +288,7 @@ if (logger.isLoggable(Level.FINE)) { logger.log(Level.FINE, "KRB5SRV10:Selected protection: {0}; privacy: {1}; integrity: {2}", - new Object[]{new Byte(selectedQop), + new Object[]{selectedQop, Boolean.valueOf(privacy), Boolean.valueOf(integrity)}); logger.log(Level.FINE, diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java --- a/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java Sat Jun 14 13:33:29 2014 -0300 @@ -77,7 +77,7 @@ if (logger.isLoggable(Level.FINE)) { logger.logp(Level.FINE, myClassName, "constructor", - "SASLIMPL02:Preferred qop mask: {0}", new Byte(allQop)); + "SASLIMPL02:Preferred qop mask: {0}", allQop); if (qop.length > 0) { StringBuffer qopbuf = new StringBuffer(); -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java --- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Sat Jun 14 13:33:29 2014 -0300 @@ -379,7 +379,7 @@ // used for substring comparisons (where proto has "*" wildcards private boolean substringMatch(String proto, String value) { // simple case 1: "*" means attribute presence is being tested - if(proto.equals(new Character(WILDCARD_TOKEN).toString())) { + if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) { if(debug) {System.out.println("simple presence assertion");} return true; } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpString.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpString.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpString.java Sat Jun 14 13:33:29 2014 -0300 @@ -140,7 +140,7 @@ public Byte[] toByte() { Byte[] result = new Byte[value.length] ; for (int i = 0 ; i < value.length ; i++) { - result[i] = new Byte(value[i]) ; + result[i] = value[i]; } return result ; } -------------- next part -------------- diff -r d02b062bc827 src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java --- a/src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Fri Jun 13 11:21:30 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Sat Jun 14 13:33:29 2014 -0300 @@ -1102,8 +1102,7 @@ "PasswordField.selectionBackground", SelectionBackgroundColor, "PasswordField.selectionForeground", SelectionTextColor, "PasswordField.caretForeground",WindowTextColor, - "PasswordField.echoChar", new XPValue(new Character((char)0x25CF), - new Character('*')), + "PasswordField.echoChar", new XPValue((char)0x25CF, '*'), // *** ProgressBar "ProgressBar.font", ControlFont, From ivan.gerasimov at oracle.com Sat Jun 14 21:00:49 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 15 Jun 2014 01:00:49 +0400 Subject: RFR [8042990] Optimize conversion to hex string Message-ID: <539CB801.9080506@oracle.com> Hello! There is a method Integer.toHexString(int), which produce a string with no extra leading zeroes. I found a couple of places in jdk, where it would be useful to have a variant of the method which pads the result with the required amount of zeroes. Would you please take at the webrev? http://cr.openjdk.java.net/~igerasim/8042990/0/webrev/ It includes implementations of Integer.toHexString(int, int) and Long.toHexString(long, int) with the second argument standing for the minimum width of the produced string. It also contains a few replacements of the same behaving code with calls to these new methods. Sincerely yours, Ivan From claes.redestad at oracle.com Sat Jun 14 21:23:02 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 14 Jun 2014 23:23:02 +0200 Subject: RFR [8042990] Optimize conversion to hex string In-Reply-To: <539CB801.9080506@oracle.com> References: <539CB801.9080506@oracle.com> Message-ID: <539CBD36.5030800@oracle.com> Hi, I'd just want to point out that there is an open bug and proposed patch to optimize UUID even further (which would conflict with your patch): https://bugs.openjdk.java.net/browse/JDK-8006627 Wouldn't it generally be better to break apart library changes (Integer/Long) from applied optimizations to ease backporting etc? /Claes On 2014-06-14 23:00, Ivan Gerasimov wrote: > Hello! > > There is a method Integer.toHexString(int), which produce a string > with no extra leading zeroes. > I found a couple of places in jdk, where it would be useful to have a > variant of the method which pads the result with the required amount > of zeroes. > > Would you please take at the webrev? > http://cr.openjdk.java.net/~igerasim/8042990/0/webrev/ > > It includes implementations of Integer.toHexString(int, int) and > Long.toHexString(long, int) with the second argument standing for the > minimum width of the produced string. > It also contains a few replacements of the same behaving code with > calls to these new methods. > > Sincerely yours, > Ivan From claes.redestad at oracle.com Sat Jun 14 22:36:29 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 15 Jun 2014 00:36:29 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer Message-ID: <539CCE6D.6040207@oracle.com> Hi, please review this patch to add offset based variants of Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong and expose them through JavaLangAccess along with formatUnsignedInt/-Long. This is proposed to enable a number of minor optimizations, starting with https://bugs.openjdk.java.net/browse/JDK-8006627 Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ Thanks! /Claes From claes.redestad at oracle.com Sat Jun 14 22:41:32 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 15 Jun 2014 00:41:32 +0200 Subject: RFR [9] 8006627: UUID to/from String performance should be improved by reducing object allocations Message-ID: <539CCF9C.9090001@oracle.com> Hi, please review this patch to improve UUID performance, originally proposed by Steven Schlansker, rebased to use the allocation-free methods added in https://bugs.openjdk.java.net/browse/JDK-8041972 Webrev: http://cr.openjdk.java.net/~redestad/8006627/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8006627 Thanks! /Claes From forax at univ-mlv.fr Sun Jun 15 11:48:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 Jun 2014 13:48:49 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539CCE6D.6040207@oracle.com> References: <539CCE6D.6040207@oracle.com> Message-ID: <539D8821.3070808@univ-mlv.fr> On 06/15/2014 12:36 AM, Claes Redestad wrote: > Hi, > > please review this patch to add offset based variants of > Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong > and expose them through JavaLangAccess along with > formatUnsignedInt/-Long. This is proposed to enable a number of minor > optimizations, starting with > https://bugs.openjdk.java.net/browse/JDK-8006627 > > Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ > > Thanks! > > /Claes In my opinion, and as suggested in the description of 8041972, these methods should be public. Having written my share of scanners/parsers in Java, these methods are really helpful but given that they only rely on charAt/length of String, I think they should take a CharSequence and not a String as first parameter, in order to support other storages of characters like by example a java.nio.CharBuffer. So for me, instead of adding a bunch of method in shared secrets, those method should be public and take a CharSequence. Miinor nits, Integer.parseInt(String,int,int) don't need to test if s is null given it delegated to parseInt(String, int, int, int), and Integer.parseInt(String) should directly call parseInt(s, 10, 0, s.length()) instead of calling parseInt(s, 10) that calls parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). cheers, R?mi From claes.redestad at oracle.com Sun Jun 15 12:29:20 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 15 Jun 2014 14:29:20 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539D8821.3070808@univ-mlv.fr> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> Message-ID: <539D91A0.9050901@oracle.com> On 2014-06-15 13:48, Remi Forax wrote: > > On 06/15/2014 12:36 AM, Claes Redestad wrote: >> Hi, >> >> please review this patch to add offset based variants of >> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >> and expose them through JavaLangAccess along with >> formatUnsignedInt/-Long. This is proposed to enable a number of minor >> optimizations, starting with >> https://bugs.openjdk.java.net/browse/JDK-8006627 >> >> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >> >> Thanks! >> >> /Claes > > In my opinion, and as suggested in the description of 8041972, these > methods should be public. Ultimately, yes. The ulterior motive here is to be able to backport these to 8u40 (maybe even 7) for internal JDK use, while updating to public (and dropping the SharedSecrets) should be done in a later, 9-only update. Adding public methods would require CCC approval, more detailed javadocs and possibly be part of a JEP, so pushing a back-portable internal patch as a first step seems reasonable. > Having written my share of scanners/parsers in Java, these methods are > really helpful but > given that they only rely on charAt/length of String, I think they > should take a CharSequence and not a String as first parameter, > in order to support other storages of characters like by example a > java.nio.CharBuffer. > > So for me, instead of adding a bunch of method in shared secrets, > those method should be public and take a CharSequence. I wouldn't mind switching over to CharSequence for the newly added methods. I wasn't around last time[1] this was proposed for the existing methods, but I know there were arguments that changing to a (possibly) mutable input type might have problematic side effects that would form a valid argument against this switch, while I personally share the opinion that it's up to the caller to enforce immutability when necessary and that text parsing methods should all use CharSequence when possible. > > Miinor nits, Integer.parseInt(String,int,int) don't need to test if s > is null given it delegated to parseInt(String, int, int, int), > and Integer.parseInt(String) should directly call parseInt(s, 10, 0, > s.length()) instead of calling parseInt(s, 10) that calls > parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). > > cheers, > R?mi Not checking for null in parseInt(String, int, int) would mean we would get a NPE calling s.length() in the call to parseInt(String, int, int, int), so this is needed for compatibility. Microbenchmarks suggests the extra check does not have any performance impact since the JIT can easily prove that the inner null checks can be removed when an outer method. Calling parseInt(s, 10, 0, s.length()) directly in place of parseInt(s, 10, 0) would likewise require an earlier null check (slightly more code duplication) while being performance neutral either way. /Claes [1] https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html From claes.redestad at oracle.com Sun Jun 15 22:22:44 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 Jun 2014 00:22:44 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539D91A0.9050901@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> Message-ID: <539E1CB4.2050502@oracle.com> I've updated the patch to use CharSequence in favor of String for all new methods, as well as ensuring all new methods are package private (for now): http://cr.openjdk.java.net/~redestad/8041972/webrev.2/ Reviews appreciated! /Claes On 2014-06-15 14:29, Claes Redestad wrote: > > On 2014-06-15 13:48, Remi Forax wrote: >> >> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch to add offset based variants of >>> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >>> and expose them through JavaLangAccess along with >>> formatUnsignedInt/-Long. This is proposed to enable a number of >>> minor optimizations, starting with >>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>> >>> Thanks! >>> >>> /Claes >> >> In my opinion, and as suggested in the description of 8041972, these >> methods should be public. > Ultimately, yes. The ulterior motive here is to be able to backport > these to 8u40 (maybe even 7) for internal JDK use, while updating to > public (and dropping the SharedSecrets) should be done in a later, > 9-only update. Adding public methods would require CCC approval, more > detailed javadocs and possibly be part of a JEP, so pushing a > back-portable internal patch as a first step seems reasonable. >> Having written my share of scanners/parsers in Java, these methods >> are really helpful but >> given that they only rely on charAt/length of String, I think they >> should take a CharSequence and not a String as first parameter, >> in order to support other storages of characters like by example a >> java.nio.CharBuffer. >> >> So for me, instead of adding a bunch of method in shared secrets, >> those method should be public and take a CharSequence. > I wouldn't mind switching over to CharSequence for the newly added > methods. I wasn't around last time[1] this was proposed for the > existing methods, but I know there were arguments that changing to a > (possibly) mutable input type might have problematic side effects that > would form a valid argument against this switch, while I personally > share the opinion that it's up to the caller to enforce immutability > when necessary and that text parsing methods should all use > CharSequence when possible. >> >> Miinor nits, Integer.parseInt(String,int,int) don't need to test if s >> is null given it delegated to parseInt(String, int, int, int), >> and Integer.parseInt(String) should directly call parseInt(s, 10, 0, >> s.length()) instead of calling parseInt(s, 10) that calls >> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >> >> cheers, >> R?mi > Not checking for null in parseInt(String, int, int) would mean we > would get a NPE calling s.length() in the call to parseInt(String, > int, int, int), so this is needed for compatibility. Microbenchmarks > suggests the extra check does not have any performance impact since > the JIT can easily prove that the inner null checks can be removed > when an outer method. > > Calling parseInt(s, 10, 0, s.length()) directly in place of > parseInt(s, 10, 0) would likewise require an earlier null check > (slightly more code duplication) while being performance neutral > either way. > > /Claes > > [1] > https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html From forax at univ-mlv.fr Sun Jun 15 23:14:19 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Jun 2014 01:14:19 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539D91A0.9050901@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> Message-ID: <539E28CB.3050605@univ-mlv.fr> On 06/15/2014 02:29 PM, Claes Redestad wrote: > > On 2014-06-15 13:48, Remi Forax wrote: >> >> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch to add offset based variants of >>> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >>> and expose them through JavaLangAccess along with >>> formatUnsignedInt/-Long. This is proposed to enable a number of >>> minor optimizations, starting with >>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>> >>> Thanks! >>> >>> /Claes >> >> In my opinion, and as suggested in the description of 8041972, these >> methods should be public. > Ultimately, yes. The ulterior motive here is to be able to backport > these to 8u40 (maybe even 7) for internal JDK use, while updating to > public (and dropping the SharedSecrets) should be done in a later, > 9-only update. Adding public methods would require CCC approval, more > detailed javadocs and possibly be part of a JEP, so pushing a > back-portable internal patch as a first step seems reasonable. Ok, >> Having written my share of scanners/parsers in Java, these methods >> are really helpful but >> given that they only rely on charAt/length of String, I think they >> should take a CharSequence and not a String as first parameter, >> in order to support other storages of characters like by example a >> java.nio.CharBuffer. >> >> So for me, instead of adding a bunch of method in shared secrets, >> those method should be public and take a CharSequence. > I wouldn't mind switching over to CharSequence for the newly added > methods. I wasn't around last time[1] this was proposed for the > existing methods, but I know there were arguments that changing to a > (possibly) mutable input type might have problematic side effects that > would form a valid argument against this switch, while I personally > share the opinion that it's up to the caller to enforce immutability > when necessary and that text parsing methods should all use > CharSequence when possible. >> >> Miinor nits, Integer.parseInt(String,int,int) don't need to test if s >> is null given it delegated to parseInt(String, int, int, int), >> and Integer.parseInt(String) should directly call parseInt(s, 10, 0, >> s.length()) instead of calling parseInt(s, 10) that calls >> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >> >> cheers, >> R?mi > Not checking for null in parseInt(String, int, int) would mean we > would get a NPE calling s.length() in the call to parseInt(String, > int, int, int), so this is needed for compatibility. I see, parseInt throws a NumberFormatException instead of a NPE, > Microbenchmarks suggests the extra check does not have any performance > impact since the JIT can easily prove that the inner null checks can > be removed when an outer method. > > Calling parseInt(s, 10, 0, s.length()) directly in place of > parseInt(s, 10, 0) would likewise require an earlier null check > (slightly more code duplication) while being performance neutral > either way. It's not performance neutral. parseInt is already used in converter (objects that does conversions) as a leaf call, if you add several layers of calls, the JIT will hit the maximum depth threshold when inlining (10 by default), so I think it's better to do the check in parseInt(String) (like you do in parseInt(String, int radix, int start)) to avoid performance regression. > > /Claes > > [1] > https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html R?mi From forax at univ-mlv.fr Sun Jun 15 23:16:58 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Jun 2014 01:16:58 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539E1CB4.2050502@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> Message-ID: <539E296A.6060601@univ-mlv.fr> On 06/16/2014 12:22 AM, Claes Redestad wrote: > I've updated the patch to use CharSequence in favor of String for all > new methods, as well as ensuring all new methods are package private > (for now): > > http://cr.openjdk.java.net/~redestad/8041972/webrev.2/ > > Reviews appreciated! > > /Claes Thanks, for that, R?mi > > On 2014-06-15 14:29, Claes Redestad wrote: >> >> On 2014-06-15 13:48, Remi Forax wrote: >>> >>> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch to add offset based variants of >>>> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >>>> and expose them through JavaLangAccess along with >>>> formatUnsignedInt/-Long. This is proposed to enable a number of >>>> minor optimizations, starting with >>>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> In my opinion, and as suggested in the description of 8041972, these >>> methods should be public. >> Ultimately, yes. The ulterior motive here is to be able to backport >> these to 8u40 (maybe even 7) for internal JDK use, while updating to >> public (and dropping the SharedSecrets) should be done in a later, >> 9-only update. Adding public methods would require CCC approval, more >> detailed javadocs and possibly be part of a JEP, so pushing a >> back-portable internal patch as a first step seems reasonable. >>> Having written my share of scanners/parsers in Java, these methods >>> are really helpful but >>> given that they only rely on charAt/length of String, I think they >>> should take a CharSequence and not a String as first parameter, >>> in order to support other storages of characters like by example a >>> java.nio.CharBuffer. >>> >>> So for me, instead of adding a bunch of method in shared secrets, >>> those method should be public and take a CharSequence. >> I wouldn't mind switching over to CharSequence for the newly added >> methods. I wasn't around last time[1] this was proposed for the >> existing methods, but I know there were arguments that changing to a >> (possibly) mutable input type might have problematic side effects >> that would form a valid argument against this switch, while I >> personally share the opinion that it's up to the caller to enforce >> immutability when necessary and that text parsing methods should all >> use CharSequence when possible. >>> >>> Miinor nits, Integer.parseInt(String,int,int) don't need to test if >>> s is null given it delegated to parseInt(String, int, int, int), >>> and Integer.parseInt(String) should directly call parseInt(s, 10, 0, >>> s.length()) instead of calling parseInt(s, 10) that calls >>> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >>> >>> cheers, >>> R?mi >> Not checking for null in parseInt(String, int, int) would mean we >> would get a NPE calling s.length() in the call to parseInt(String, >> int, int, int), so this is needed for compatibility. Microbenchmarks >> suggests the extra check does not have any performance impact since >> the JIT can easily prove that the inner null checks can be removed >> when an outer method. >> >> Calling parseInt(s, 10, 0, s.length()) directly in place of >> parseInt(s, 10, 0) would likewise require an earlier null check >> (slightly more code duplication) while being performance neutral >> either way. >> >> /Claes >> >> [1] >> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html > From joel.franck at oracle.com Mon Jun 16 10:57:57 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 16 Jun 2014 12:57:57 +0200 Subject: RFR 8u20: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class Message-ID: <657F7382-4F1D-4627-8301-7A823283C44F@oracle.com> Hi, Can I get a review for this almost trivial 8u20 back port. The 9 fix reviewed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027173.html applies cleanly except one hunk fails due to a non-backported change updating a for to a for each: $ cat src/share/classes/java/lang/Class.java.rej --- Class.java +++ Class.java @@ -2819,7 +2894,7 @@ // the end. MethodArray inheritedMethods = new MethodArray(); for (Class i : getInterfaces()) { - inheritedMethods.addAllNonStatic(i.privateGetPublicMethods()); + inheritedMethods.addInterfaceMethods(i.privateGetPublicMethods()); } if (!isInterface()) { Class c = getSuperclass(); In 8u the hunk needs to be: @@ -2819,9 +2894,8 @@ // out concrete implementations inherited from superclasses at // the end. MethodArray inheritedMethods = new MethodArray(); - Class[] interfaces = getInterfaces(); - for (int i = 0; i < interfaces.length; i++) { - inheritedMethods.addAllNonStatic(interfaces[i].privateGetPublicMethods()); + for (Class i : getInterfaces()) { + inheritedMethods.addInterfaceMethods(i.privateGetPublicMethods()); } if (!isInterface()) { Class c = getSuperclass(); 8u webrev here: http://cr.openjdk.java.net/~jfranck/8029674/jdk8u/webrev.8u.00/ 9 Bug here: http://bugs.openjdk.java.net/browse/JDK-8029674 cheers /Joel From lance.andersen at oracle.com Mon Jun 16 11:33:41 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Mon, 16 Jun 2014 07:33:41 -0400 Subject: RFR: 8046389: Add missing @since tag under javax.sql.** In-Reply-To: <53962984.1070406@oracle.com> References: <53962984.1070406@oracle.com> Message-ID: <7ADD41F6-136F-4309-9041-1ED2179D452B@oracle.com> This is fine Henry 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 Jun 9, 2014, at 5:39 PM, Henry Jen wrote: > Hi, > > Please review a trivial webrev that provides missing @since tag for elements under javax.sql, > > javax.sql.CommonDataSource was extracted out since 1.6, methods have @since 1.4 tag because those methods existed in origins since then. > > http://cr.openjdk.java.net/~henryjen/jdk9/8046389/0/webrev/ > > Cheers, > Henry From chris.hegarty at oracle.com Mon Jun 16 15:05:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Jun 2014 16:05:54 +0100 Subject: RFR [9] 8046902: Remove sun.misc.Timer Message-ID: <539F07D2.5090502@oracle.com> The type sun.misc.Timer has long since been replaced by the standard java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should be removed from the platform. This is part of the larger cleanup of legacy unused classes from sun.misc, see JDK-6852936 [1]. sun.misc.Timeable will also be removed as part of this issue. http://cr.openjdk.java.net/~chegar/8046902/webrev.00/webrev/ -Chris. [0] https://bugs.openjdk.java.net/browse/JDK-8046902 [1] https://bugs.openjdk.java.net/browse/JDK-6852936 From henry.jen at oracle.com Mon Jun 16 15:11:13 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 16 Jun 2014 08:11:13 -0700 Subject: RFR: 8046389: Add missing @since tag under javax.sql.** In-Reply-To: <7ADD41F6-136F-4309-9041-1ED2179D452B@oracle.com> References: <53962984.1070406@oracle.com> <7ADD41F6-136F-4309-9041-1ED2179D452B@oracle.com> Message-ID: <539F0911.8050104@oracle.com> Thanks for the review, Lance. Cheers, Henry On 06/16/2014 04:33 AM, Lance @ Oracle wrote: > This is fine Henry > > 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 Jun 9, 2014, at 5:39 PM, Henry Jen > wrote: > >> Hi, >> >> Please review a trivial webrev that provides missing @since tag for >> elements under javax.sql, >> >> javax.sql.CommonDataSource was extracted out since 1.6, methods have >> @since 1.4 tag because those methods existed in origins since then. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8046389/0/webrev/ >> >> Cheers, >> Henry From roger.riggs at oracle.com Mon Jun 16 15:50:21 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 16 Jun 2014 11:50:21 -0400 Subject: RFR [9] 8046902: Remove sun.misc.Timer In-Reply-To: <539F07D2.5090502@oracle.com> References: <539F07D2.5090502@oracle.com> Message-ID: <539F123D.7050805@oracle.com> Hi Chris, Looks good, especially since there are no current uses. Roger On 6/16/2014 11:05 AM, Chris Hegarty wrote: > The type sun.misc.Timer has long since been replaced by the standard > java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer > should be removed from the platform. This is part of the larger > cleanup of legacy unused classes from sun.misc, see JDK-6852936 [1]. > > sun.misc.Timeable will also be removed as part of this issue. > > http://cr.openjdk.java.net/~chegar/8046902/webrev.00/webrev/ > > -Chris. > > [0] https://bugs.openjdk.java.net/browse/JDK-8046902 > [1] https://bugs.openjdk.java.net/browse/JDK-6852936 From mike.duigou at oracle.com Mon Jun 16 16:43:23 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 16 Jun 2014 09:43:23 -0700 Subject: RFR [9] 8046902: Remove sun.misc.Timer In-Reply-To: <539F07D2.5090502@oracle.com> References: <539F07D2.5090502@oracle.com> Message-ID: <960104B7-04F0-474B-809C-8EC75264F862@oracle.com> Remove it before someone starts to use it! Mike On Jun 16 2014, at 08:05 , Chris Hegarty wrote: > The type sun.misc.Timer has long since been replaced by the standard java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should be removed from the platform. This is part of the larger cleanup of legacy unused classes from sun.misc, see JDK-6852936 [1]. > > sun.misc.Timeable will also be removed as part of this issue. > > http://cr.openjdk.java.net/~chegar/8046902/webrev.00/webrev/ > > -Chris. > > [0] https://bugs.openjdk.java.net/browse/JDK-8046902 > [1] https://bugs.openjdk.java.net/browse/JDK-6852936 From vladimir.x.ivanov at oracle.com Mon Jun 16 16:50:39 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 16 Jun 2014 20:50:39 +0400 Subject: [9] RFR (XS): 8046903: VM anonymous class members can't be statically invocable Message-ID: <539F205F.9040005@oracle.com> http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8046903 j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish between VM anonymous classes and ordinary classes. In some very specific circumstances (VM anonymous class declared in one of predefined core packages), it can consider a member of VM anonymous class as statically invocable and symbolically reference it from generated bytecode. It's wrong because such class can't be looked up by name and the attempt to run such code ends up with NoClassDefFoundError. The fix is to disable static invocation for members of VM anonymous classes. Testing: regression test. Thanks! Best regards, Vladimir Ivanov From paul.sandoz at oracle.com Mon Jun 16 16:51:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jun 2014 17:51:04 +0100 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> <53766815.40600@oracle.com> <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> <5379B7DC.2020206@oracle.com> <537A3CF5.5010401@oracle.com> <68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com> Message-ID: <93462213-92CF-46A3-B465-7A52E4193775@oracle.com> After some further reflection i have decided to not separate this out and some bits going to client and some bits going to dev, and have pushed all changes to dev. I realise this might cause some friction but believe it the right thing to do. I remain unconvinced that the separate process for patches such as this scales and is a valuable use of our development time and resources. A merging process is surely fundamentally more efficient (and anyway has to be performed) over N developers having to use a slightly different process [*]. Call me human and flawed in my management of time :-( but higher priority things keep getting pushed to the top of my stack before getting around to following this separate process and i really don't want the code to bit rot. I suspect i am not unique in this regard. Paul. [*] Is it documented? I have never managed to obtain a definitive answer, nor an explicit white-list of Java package names (external yes, internal no). On May 20, 2014, at 7:45 AM, Paul Sandoz wrote: > > On May 19, 2014, at 6:18 PM, Phil Race wrote: > >> On 5/19/2014 12:50 AM, Alan Bateman wrote: >>> On 19/05/2014 07:53, Paul Sandoz wrote: >>>> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. >>> If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this). >>> >>> For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client. >>> >> The changes should go through client for the reasons I already gave. > > IIUC these were the reasons you gave in a previous email on this thread: > > "I would not push hotspot changes to client either. Also lots of files > are being updated in client and doing it this way will minimise merges ..." > > I don't find either very convincing. > > >> No new permissions are needed but it will need a unique bug id. >> > > Ok. > > >> FWIW integrations are intended to be bi-weekly but holidays interfered this time. >> > > Why does it take so long? > > Paul. From xueming.shen at oracle.com Mon Jun 16 17:00:37 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 16 Jun 2014 10:00:37 -0700 Subject: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb In-Reply-To: <537BC093.40102@oracle.com> References: <53672CB4.3050708@oracle.com> <537A4980.5050603@oracle.com> <537BC093.40102@oracle.com> Message-ID: <539F22B5.90409@oracle.com> OK, let's go the non-controversial approach. The webrev has been updated to simply remove those redundant/duplicated class files from the builder and use the updated version of the tzdb builder. http://cr.openjdk.java.net/~sherman/8042369/webrev Thanks! -Sherman On 5/20/2014 1:52 PM, roger riggs wrote: > Hi Sherman, > > Even though it has well defined content, checking in the tar.gz seems not quite right. > Can the tests reconstruct the tar file from the contents or directly use > the IANA data on demand from the IANA site? > > From a maintenance point of view, functions added to the JDK should be > well used and maintained and be well supported. > > TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still mentions "-srcdir". > > :+153; the commented out message should be removed > > > Roger > > > On 5/19/2014 2:12 PM, Xueming Shen wrote: >> Hi, >> >> I've not got any feedback so far, so I assume it's good:-) >> >> Anyway, I'm going a little further to throw in a TarInputStream so now we just build the >> tzdb data directly on the tzdata201xy.tar.gz from iana site. I'm not sure if it is OK to >> check in the original .tar.gz file into the jdk repository though. >> >> There are also more improvements in this version, it is much faster now. It might >> not matter as it is only used during build time, though:-) >> >> http://cr.openjdk.java.net/~sherman/8042369/webrev >> >> -Sherman >> >> Btw, I'm still trying to sell the idea of checking in a second tzdb provider implementation >> into the jdk, which directly loads in the tzdb data by using the iana original source data, >> with the assumption that this might be useful at least in certain circumstance (such as >> one gov pushes a tz change, and some of your big jdk customers need their apps run with >> the new data in next 24 hrs...) in the future. >> >> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev >> >> >> On 05/04/2014 11:16 PM, Xueming Shen wrote: >>> Hi >>> >>> Please help review the change for #8042369 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 >>> Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev >>> >>> In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data >>> for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these >>> classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so >>> most of these duplicated classes are no longer needed, with ZoneRules as the only exception. >>> The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the >>> serialization forms of those transitions and rules. The proposed change here is to remove >>> those unneeded duplicated classes. >>> >>> I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler >>> and and straightforward implementation, with the goal of migrating it into a second default >>> ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the >>> IANA directly. One of the benefits of such a provider is that the end user may just drop the latest >>> timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from >>> Oracle. >>> >>> Here is the webrev for the idea >>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ >>> >>> The only disadvantage appears to be the possible "slowdown" of startup time because of >>> the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for >>> j.u.TimeZone, if we go with this direction) >>> >>> Thanks! >>> -Sherman >>> >>> >> > From iris.clark at oracle.com Mon Jun 16 17:08:54 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 16 Jun 2014 10:08:54 -0700 (PDT) Subject: RFR [9] 8046902: Remove sun.misc.Timer In-Reply-To: <539F07D2.5090502@oracle.com> References: <539F07D2.5090502@oracle.com> Message-ID: <65ad1b2f-6bb7-432b-a3ac-920dd3586deb@default> Hi, Chris. Looks great! Long overdue since java.util.Timer was added around Spring 1999 during JDK 1.3 development. Thanks, iris -----Original Message----- From: Chris Hegarty Sent: Monday, June 16, 2014 8:06 AM To: Core-Libs-Dev Subject: RFR [9] 8046902: Remove sun.misc.Timer The type sun.misc.Timer has long since been replaced by the standard java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should be removed from the platform. This is part of the larger cleanup of legacy unused classes from sun.misc, see JDK-6852936 [1]. sun.misc.Timeable will also be removed as part of this issue. http://cr.openjdk.java.net/~chegar/8046902/webrev.00/webrev/ -Chris. [0] https://bugs.openjdk.java.net/browse/JDK-8046902 [1] https://bugs.openjdk.java.net/browse/JDK-6852936 From joe.darcy at oracle.com Mon Jun 16 17:38:56 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 16 Jun 2014 10:38:56 -0700 Subject: RFR 8u20: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class In-Reply-To: <657F7382-4F1D-4627-8301-7A823283C44F@oracle.com> References: <657F7382-4F1D-4627-8301-7A823283C44F@oracle.com> Message-ID: <539F2BB0.3060301@oracle.com> Hi Joel, The 8u version looks fine; thanks, -Joe On 06/16/2014 03:57 AM, Joel Borggr?n-Franck wrote: > Hi, > > Can I get a review for this almost trivial 8u20 back port. The 9 fix reviewed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027173.html applies cleanly except one hunk fails due to a non-backported change updating a for to a for each: > > $ cat src/share/classes/java/lang/Class.java.rej > --- Class.java > +++ Class.java > @@ -2819,7 +2894,7 @@ > // the end. > MethodArray inheritedMethods = new MethodArray(); > for (Class i : getInterfaces()) { > - inheritedMethods.addAllNonStatic(i.privateGetPublicMethods()); > + inheritedMethods.addInterfaceMethods(i.privateGetPublicMethods()); > } > if (!isInterface()) { > Class c = getSuperclass(); > > In 8u the hunk needs to be: > > @@ -2819,9 +2894,8 @@ > // out concrete implementations inherited from superclasses at > // the end. > MethodArray inheritedMethods = new MethodArray(); > - Class[] interfaces = getInterfaces(); > - for (int i = 0; i < interfaces.length; i++) { > - inheritedMethods.addAllNonStatic(interfaces[i].privateGetPublicMethods()); > + for (Class i : getInterfaces()) { > + inheritedMethods.addInterfaceMethods(i.privateGetPublicMethods()); > } > if (!isInterface()) { > Class c = getSuperclass(); > > 8u webrev here: http://cr.openjdk.java.net/~jfranck/8029674/jdk8u/webrev.8u.00/ > 9 Bug here: http://bugs.openjdk.java.net/browse/JDK-8029674 > > cheers > /Joel From john.r.rose at oracle.com Mon Jun 16 18:07:13 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 16 Jun 2014 11:07:13 -0700 Subject: [9] RFR (XS): 8046903: VM anonymous class members can't be statically invocable In-Reply-To: <539F205F.9040005@oracle.com> References: <539F205F.9040005@oracle.com> Message-ID: <0FAA661B-3C00-4303-AE6B-99E63293F8B8@oracle.com> Reviewed. ? John On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8046903 > > j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish between VM anonymous classes and ordinary classes. In some very specific circumstances (VM anonymous class declared in one of predefined core packages), it can consider a member of VM anonymous class as statically invocable and symbolically reference it from generated bytecode. It's wrong because such class can't be looked up by name and the attempt to run such code ends up with NoClassDefFoundError. > > The fix is to disable static invocation for members of VM anonymous classes. > > Testing: regression test. > > Thanks! > > Best regards, > Vladimir Ivanov From roger.riggs at oracle.com Mon Jun 16 19:50:02 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 16 Jun 2014 15:50:02 -0400 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539E1CB4.2050502@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> Message-ID: <539F4A6A.5020002@oracle.com> Hi Claes, The descriptions of the new methods should take the same form as the coresponding existing methods. The rationalization about intermediary objects is not useful in describing the behavior of the method and should be omitted. /** * Parses the string argument starting at fromIndex as a signed integer in the radix * specified by the second argument. ... static int parseInt(CharSequence s, int radix, int fromIndex) The terminology used in java.lang.String for offsets and indexes into strings would be provide a consistent base for talking about substrings. Thanks, Roger For example, On 6/15/2014 6:22 PM, Claes Redestad wrote: > I've updated the patch to use CharSequence in favor of String for all > new methods, as well as ensuring all new methods are package private > (for now): > > http://cr.openjdk.java.net/~redestad/8041972/webrev.2/ > > Reviews appreciated! > > /Claes > > On 2014-06-15 14:29, Claes Redestad wrote: >> >> On 2014-06-15 13:48, Remi Forax wrote: >>> >>> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch to add offset based variants of >>>> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >>>> and expose them through JavaLangAccess along with >>>> formatUnsignedInt/-Long. This is proposed to enable a number of >>>> minor optimizations, starting with >>>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> In my opinion, and as suggested in the description of 8041972, these >>> methods should be public. >> Ultimately, yes. The ulterior motive here is to be able to backport >> these to 8u40 (maybe even 7) for internal JDK use, while updating to >> public (and dropping the SharedSecrets) should be done in a later, >> 9-only update. Adding public methods would require CCC approval, more >> detailed javadocs and possibly be part of a JEP, so pushing a >> back-portable internal patch as a first step seems reasonable. >>> Having written my share of scanners/parsers in Java, these methods >>> are really helpful but >>> given that they only rely on charAt/length of String, I think they >>> should take a CharSequence and not a String as first parameter, >>> in order to support other storages of characters like by example a >>> java.nio.CharBuffer. >>> >>> So for me, instead of adding a bunch of method in shared secrets, >>> those method should be public and take a CharSequence. >> I wouldn't mind switching over to CharSequence for the newly added >> methods. I wasn't around last time[1] this was proposed for the >> existing methods, but I know there were arguments that changing to a >> (possibly) mutable input type might have problematic side effects >> that would form a valid argument against this switch, while I >> personally share the opinion that it's up to the caller to enforce >> immutability when necessary and that text parsing methods should all >> use CharSequence when possible. >>> >>> Miinor nits, Integer.parseInt(String,int,int) don't need to test if >>> s is null given it delegated to parseInt(String, int, int, int), >>> and Integer.parseInt(String) should directly call parseInt(s, 10, 0, >>> s.length()) instead of calling parseInt(s, 10) that calls >>> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >>> >>> cheers, >>> R?mi >> Not checking for null in parseInt(String, int, int) would mean we >> would get a NPE calling s.length() in the call to parseInt(String, >> int, int, int), so this is needed for compatibility. Microbenchmarks >> suggests the extra check does not have any performance impact since >> the JIT can easily prove that the inner null checks can be removed >> when an outer method. >> >> Calling parseInt(s, 10, 0, s.length()) directly in place of >> parseInt(s, 10, 0) would likewise require an earlier null check >> (slightly more code duplication) while being performance neutral >> either way. >> >> /Claes >> >> [1] >> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html > From claes.redestad at oracle.com Mon Jun 16 20:13:02 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 Jun 2014 22:13:02 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539F4A6A.5020002@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> <539F4A6A.5020002@oracle.com> Message-ID: <539F4FCE.9080903@oracle.com> On 2014-06-16 21:50, roger riggs wrote: > Hi Claes, > > The descriptions of the new methods should take the same form as > the coresponding existing methods. The rationalization about > intermediary > objects is not useful in describing the behavior of the method and > should be omitted. Point taken! > > /** > * Parses the string argument starting at fromIndex as a signed > integer in the radix > * specified by the second argument. > ... > > static int parseInt(CharSequence s, int radix, int fromIndex) > > The terminology used in java.lang.String for offsets and indexes into > strings would > be provide a consistent base for talking about substrings. If we're taking cues from String.substring, I guess int beginIndex[, int fromIndex] would be more appropriate. How about: /** * Parses the character sequence argument in the specified {@code radix}, * beginning at the specified {@code beginIndex} and extending to the * character at index {@code endIndex - 1}. * * @see java.lang.Integer#parseInt(String, int) * @param s the {@code CharSequence} containing the integer * representation to be parsed * @param radix the radix to be used while parsing {@code s}. * @param beginIndex the beginning index, inclusive. * @param endIndex the ending index, exclusive. * @return the integer represented by the subsequence in the * specified radix. */ static int parseInt(CharSequence s, int radix, int beginIndex, int endIndex) ? Thanks! /Claes > > Thanks, Roger > > > For example, > > > On 6/15/2014 6:22 PM, Claes Redestad wrote: >> I've updated the patch to use CharSequence in favor of String for all >> new methods, as well as ensuring all new methods are package private >> (for now): >> >> http://cr.openjdk.java.net/~redestad/8041972/webrev.2/ >> >> Reviews appreciated! >> >> /Claes >> >> On 2014-06-15 14:29, Claes Redestad wrote: >>> >>> On 2014-06-15 13:48, Remi Forax wrote: >>>> >>>> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> please review this patch to add offset based variants of >>>>> Integer.parseInt/parseUnsignedInt, >>>>> Long.parseLong/parseUnsignedLong and expose them through >>>>> JavaLangAccess along with formatUnsignedInt/-Long. This is >>>>> proposed to enable a number of minor optimizations, starting with >>>>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >>>> In my opinion, and as suggested in the description of 8041972, >>>> these methods should be public. >>> Ultimately, yes. The ulterior motive here is to be able to backport >>> these to 8u40 (maybe even 7) for internal JDK use, while updating to >>> public (and dropping the SharedSecrets) should be done in a later, >>> 9-only update. Adding public methods would require CCC approval, >>> more detailed javadocs and possibly be part of a JEP, so pushing a >>> back-portable internal patch as a first step seems reasonable. >>>> Having written my share of scanners/parsers in Java, these methods >>>> are really helpful but >>>> given that they only rely on charAt/length of String, I think they >>>> should take a CharSequence and not a String as first parameter, >>>> in order to support other storages of characters like by example a >>>> java.nio.CharBuffer. >>>> >>>> So for me, instead of adding a bunch of method in shared secrets, >>>> those method should be public and take a CharSequence. >>> I wouldn't mind switching over to CharSequence for the newly added >>> methods. I wasn't around last time[1] this was proposed for the >>> existing methods, but I know there were arguments that changing to a >>> (possibly) mutable input type might have problematic side effects >>> that would form a valid argument against this switch, while I >>> personally share the opinion that it's up to the caller to enforce >>> immutability when necessary and that text parsing methods should all >>> use CharSequence when possible. >>>> >>>> Miinor nits, Integer.parseInt(String,int,int) don't need to test if >>>> s is null given it delegated to parseInt(String, int, int, int), >>>> and Integer.parseInt(String) should directly call parseInt(s, 10, >>>> 0, s.length()) instead of calling parseInt(s, 10) that calls >>>> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >>>> >>>> cheers, >>>> R?mi >>> Not checking for null in parseInt(String, int, int) would mean we >>> would get a NPE calling s.length() in the call to parseInt(String, >>> int, int, int), so this is needed for compatibility. Microbenchmarks >>> suggests the extra check does not have any performance impact since >>> the JIT can easily prove that the inner null checks can be removed >>> when an outer method. >>> >>> Calling parseInt(s, 10, 0, s.length()) directly in place of >>> parseInt(s, 10, 0) would likewise require an earlier null check >>> (slightly more code duplication) while being performance neutral >>> either way. >>> >>> /Claes >>> >>> [1] >>> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html >> > From joe.darcy at oracle.com Mon Jun 16 23:38:18 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 16 Jun 2014 16:38:18 -0700 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539E1CB4.2050502@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> Message-ID: <539F7FEA.80302@oracle.com> Hello Claes, Instead of saying * Extend upon parseFoo(String, int) in the javadoc of the new methods paired with an * @see parseFoo(String, int) please use an {@link parseFoo} instead. Thanks, -Joe On 06/15/2014 03:22 PM, Claes Redestad wrote: > I've updated the patch to use CharSequence in favor of String for all > new methods, as well as ensuring all new methods are package private > (for now): > > http://cr.openjdk.java.net/~redestad/8041972/webrev.2/ > > Reviews appreciated! > > /Claes > > On 2014-06-15 14:29, Claes Redestad wrote: >> >> On 2014-06-15 13:48, Remi Forax wrote: >>> >>> On 06/15/2014 12:36 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch to add offset based variants of >>>> Integer.parseInt/parseUnsignedInt, Long.parseLong/parseUnsignedLong >>>> and expose them through JavaLangAccess along with >>>> formatUnsignedInt/-Long. This is proposed to enable a number of >>>> minor optimizations, starting with >>>> https://bugs.openjdk.java.net/browse/JDK-8006627 >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8041972/webrev.0/ >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> In my opinion, and as suggested in the description of 8041972, these >>> methods should be public. >> Ultimately, yes. The ulterior motive here is to be able to backport >> these to 8u40 (maybe even 7) for internal JDK use, while updating to >> public (and dropping the SharedSecrets) should be done in a later, >> 9-only update. Adding public methods would require CCC approval, more >> detailed javadocs and possibly be part of a JEP, so pushing a >> back-portable internal patch as a first step seems reasonable. >>> Having written my share of scanners/parsers in Java, these methods >>> are really helpful but >>> given that they only rely on charAt/length of String, I think they >>> should take a CharSequence and not a String as first parameter, >>> in order to support other storages of characters like by example a >>> java.nio.CharBuffer. >>> >>> So for me, instead of adding a bunch of method in shared secrets, >>> those method should be public and take a CharSequence. >> I wouldn't mind switching over to CharSequence for the newly added >> methods. I wasn't around last time[1] this was proposed for the >> existing methods, but I know there were arguments that changing to a >> (possibly) mutable input type might have problematic side effects >> that would form a valid argument against this switch, while I >> personally share the opinion that it's up to the caller to enforce >> immutability when necessary and that text parsing methods should all >> use CharSequence when possible. >>> >>> Miinor nits, Integer.parseInt(String,int,int) don't need to test if >>> s is null given it delegated to parseInt(String, int, int, int), >>> and Integer.parseInt(String) should directly call parseInt(s, 10, 0, >>> s.length()) instead of calling parseInt(s, 10) that calls >>> parseInt(s, 10, 0) that calls parseInt(s, 10, 0, s.length()). >>> >>> cheers, >>> R?mi >> Not checking for null in parseInt(String, int, int) would mean we >> would get a NPE calling s.length() in the call to parseInt(String, >> int, int, int), so this is needed for compatibility. Microbenchmarks >> suggests the extra check does not have any performance impact since >> the JIT can easily prove that the inner null checks can be removed >> when an outer method. >> >> Calling parseInt(s, 10, 0, s.length()) directly in place of >> parseInt(s, 10, 0) would likewise require an earlier null check >> (slightly more code duplication) while being performance neutral >> either way. >> >> /Claes >> >> [1] >> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg09694.html > From stuart.marks at oracle.com Mon Jun 16 23:52:05 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 16 Jun 2014 16:52:05 -0700 Subject: [9] RFR (XS): 8044730: small errors in ConcurrentHashMap and LongAdder docs Message-ID: <539F8325.5070803@oracle.com> Hi Martin, Thanks for augmenting my patch and pushing it into the JSR166 repo. Here's the patch rebased against jdk9-dev. Please review. s'marks # HG changeset patch # User smarks # Date 1402960663 25200 # Mon Jun 16 16:17:43 2014 -0700 # Node ID c8c2d902f3f1338b8074607367e7af8e294ae1c6 # Parent ade4491b571e65f28a6295b8be9679830a5e9a85 8044730: small errors in ConcurrentHashMap and LongAdder docs Reviewed-by: XXX diff -r ade4491b571e -r c8c2d902f3f1 src/share/classes/java/util/concurrent/ConcurrentHashMap.java --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Mon Jun 16 13:48:58 2014 -0400 +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Mon Jun 16 16:17:43 2014 -0700 @@ -133,12 +133,12 @@ * mapped values are (perhaps transiently) not used or all take the * same mapping value. * - *

A ConcurrentHashMap can be used as scalable frequency map (a + *

A ConcurrentHashMap can be used as a scalable frequency map (a * form of histogram or multiset) by using {@link * java.util.concurrent.atomic.LongAdder} values and initializing via * {@link #computeIfAbsent computeIfAbsent}. For example, to add a count * to a {@code ConcurrentHashMap freqs}, you can use - * {@code freqs.computeIfAbsent(k -> new LongAdder()).increment();} + * {@code freqs.computeIfAbsent(key, k -> new LongAdder()).increment();} * *

This class and its views and iterators implement all of the * optional methods of the {@link Map} and {@link Iterator} diff -r ade4491b571e -r c8c2d902f3f1 src/share/classes/java/util/concurrent/atomic/LongAdder.java --- a/src/share/classes/java/util/concurrent/atomic/LongAdder.java Mon Jun 16 13:48:58 2014 -0400 +++ b/src/share/classes/java/util/concurrent/atomic/LongAdder.java Mon Jun 16 16:17:43 2014 -0700 @@ -57,7 +57,7 @@ * frequency map (a form of histogram or multiset). For example, to * add a count to a {@code ConcurrentHashMap freqs}, * initializing if not already present, you can use {@code - * freqs.computeIfAbsent(k -> new LongAdder()).increment();} + * freqs.computeIfAbsent(key, k -> new LongAdder()).increment();} * *

This class extends {@link Number}, but does not define * methods such as {@code equals}, {@code hashCode} and {@code From martinrb at google.com Mon Jun 16 23:52:16 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Jun 2014 16:52:16 -0700 Subject: [9] RFR (XS): 8044730: small errors in ConcurrentHashMap and LongAdder docs In-Reply-To: <539F8325.5070803@oracle.com> References: <539F8325.5070803@oracle.com> Message-ID: Looks good! On Mon, Jun 16, 2014 at 4:52 PM, Stuart Marks wrote: > Hi Martin, > > Thanks for augmenting my patch and pushing it into the JSR166 repo. Here's > the patch rebased against jdk9-dev. Please review. > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1402960663 25200 > # Mon Jun 16 16:17:43 2014 -0700 > # Node ID c8c2d902f3f1338b8074607367e7af8e294ae1c6 > # Parent ade4491b571e65f28a6295b8be9679830a5e9a85 > 8044730: small errors in ConcurrentHashMap and LongAdder docs > Reviewed-by: XXX > > diff -r ade4491b571e -r c8c2d902f3f1 src/share/classes/java/util/ > concurrent/ConcurrentHashMap.java > --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java > Mon Jun 16 13:48:58 2014 -0400 > +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java > Mon Jun 16 16:17:43 2014 -0700 > @@ -133,12 +133,12 @@ > * mapped values are (perhaps transiently) not used or all take the > * same mapping value. > * > - *

A ConcurrentHashMap can be used as scalable frequency map (a > + *

A ConcurrentHashMap can be used as a scalable frequency map (a > * form of histogram or multiset) by using {@link > * java.util.concurrent.atomic.LongAdder} values and initializing via > * {@link #computeIfAbsent computeIfAbsent}. For example, to add a count > * to a {@code ConcurrentHashMap freqs}, you can use > - * {@code freqs.computeIfAbsent(k -> new LongAdder()).increment();} > + * {@code freqs.computeIfAbsent(key, k -> new LongAdder()).increment();} > * > *

This class and its views and iterators implement all of the > * optional methods of the {@link Map} and {@link Iterator} > diff -r ade4491b571e -r c8c2d902f3f1 src/share/classes/java/util/ > concurrent/atomic/LongAdder.java > --- a/src/share/classes/java/util/concurrent/atomic/LongAdder.java > Mon Jun 16 13:48:58 2014 -0400 > +++ b/src/share/classes/java/util/concurrent/atomic/LongAdder.java > Mon Jun 16 16:17:43 2014 -0700 > @@ -57,7 +57,7 @@ > * frequency map (a form of histogram or multiset). For example, to > * add a count to a {@code ConcurrentHashMap freqs}, > * initializing if not already present, you can use {@code > - * freqs.computeIfAbsent(k -> new LongAdder()).increment();} > + * freqs.computeIfAbsent(key, k -> new LongAdder()).increment();} > * > *

This class extends {@link Number}, but does not define > * methods such as {@code equals}, {@code hashCode} and {@code > From stuart.marks at oracle.com Tue Jun 17 00:35:00 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 16 Jun 2014 17:35:00 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <539896B5.1000102@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> Message-ID: <539F8D34.5020408@oracle.com> This is somewhat moot at this point, but.... I'd recommend against using paragraph end tags

. Paragraph end tags really are optional in HTML. I've heard some advocates of end tags, such as commenters on the linked web page, say that end tags are somehow "more correct" (wrong) or that end tags should be used "because XHTML" (javadoc is HTML4, not XHTML). The problem with using the

end tag is that it's easy for additional textual content to slip in afterward. This text would end up as part of the parent element. This might result in its being styled incorrectly or otherwise treated inconsistently with the rest of the text. For example, I happened to notice the following in one of the files in the patch, jaxp/src/javax/xml/namespace/QName.java: *

To workaround this issue, serialVersionUID is set with either * a default value or a compatibility value. To use the * compatibility value, set the system property:

* * com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 * *

This workaround was inspired by classes in the javax.management * package, e.g. ObjectName, etc. Note that the text enclosed in the element is outside of any paragraph. If the style sheet were to have a distinct style for code appearing within a paragraph, that style wouldn't apply to the text in this example. It turns out that this text is from a private field in the QName class (serialVersionUID) so it's usually not rendered anyway, but I'd guess that there are other places where text has accidentally ended up outside of paragraph elements because a paragraph end tag was used and a paragraph start tag (or block start tag) was missing. s'marks P.S. Note that the start tag for the element is optional and is implied by context. On 6/11/14 10:49 AM, huizhe wang wrote: > And, here is a good discussion on closing tags: > > http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm > > > -Joe > > On 6/11/2014 10:24 AM, Lance Andersen wrote: >> Hi Joe, >> >>

is what I am talking about. >> >> On the myriad of clean-ups that were needed to be done in JDBC, getting rid of >> these type of

blah

blocks was needed and just use

>> >> Best >> Lance >> On Jun 11, 2014, at 1:20 PM, huizhe wang > > wrote: >> >>> >>> On 6/11/2014 9:48 AM, Lance Andersen wrote: >>>> Hi Joe, >>>> >>>> please change >>>> >>>> dont >>>> >>>> to >>>> >>>> don't >>> >>> Oops, I committed too quickly. But this is a dev comment, so we can fix that >>> in the next patch. >>> >>>> >>>> I would get rid of the

>>> >>> Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: >>> If you have more than one paragraph in the doc comment, separate the >>> paragraphs with a |

|paragraph tag, as shown. >>> >>> [1] >>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html >>> >>> -Joe >>> >>>> >>>> otherwise it is OK >>>> >>>> Best >>>> Lance >>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>> > wrote: >>>> >>>>> Fix some typos in the JAXP documentation. Please review. >>>>> >>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>>>> >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> 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 huizhe.wang at oracle.com Tue Jun 17 04:33:25 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 16 Jun 2014 21:33:25 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <539F8D34.5020408@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com> Message-ID: <539FC515.9060600@oracle.com> On 6/16/2014 5:35 PM, Stuart Marks wrote: > This is somewhat moot at this point, but.... > > I'd recommend against using paragraph end tags

. Paragraph end > tags really are optional in HTML. I've heard some advocates of end > tags, such as commenters on the linked web page, say that end tags are > somehow "more correct" (wrong) or that end tags should be used > "because XHTML" (javadoc is HTML4, not XHTML). It's not xhmtl, but I would think closing tags is a good practice. Being explicit is always a good thing to do. It also provides a nice structure (NetBeans would auto-close it with an indentation), e.g.:

this is paragraph 1

although, the JAXP javadoc wasn't written with any good structure. > > The problem with using the

end tag is that it's easy for > additional textual content to slip in afterward. This text would end > up as part of the parent element. This might result in its being > styled incorrectly or otherwise treated inconsistently with the rest > of the text. That seems to be an argument for a closing tag. When a style is specified for

, closing tag makes it clear where exactly it would be applied -- it's content inside paragraphs, not the whole . If there's anything "slipped" outside of the P tags, it would be an error. > For example, I happened to notice the following in one of the files in > the patch, jaxp/src/javax/xml/namespace/QName.java: In this example, I think it was intentional by the author to add the closing tag to separate the paragraphs, otherwise he would have to add another

before . > > *

To workaround this issue, serialVersionUID is set with either > * a default value or a compatibility value. To use the > * compatibility value, set the system property:

> * > * > com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 > * > *

This workaround was inspired by classes in the javax.management > * package, e.g. ObjectName, etc. > > Note that the text enclosed in the element is outside of any > paragraph. If the style sheet were to have a distinct style for code > appearing within a paragraph, that style wouldn't apply to the text in > this example. with css, would have its own style. > > It turns out that this text is from a private field in the QName class > (serialVersionUID) so it's usually not rendered anyway, but I'd guess > that there are other places where text has accidentally ended up > outside of paragraph elements because a paragraph end tag was used and > a paragraph start tag (or block start tag) was missing. > > > > s'marks > > P.S. Note that the start tag for the element is optional > and is implied by context. haha, can be put to good use in our writings :-) -Joe > > > > > On 6/11/14 10:49 AM, huizhe wang wrote: >> And, here is a good discussion on closing tags: >> >> http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm >> >> >> >> -Joe >> >> On 6/11/2014 10:24 AM, Lance Andersen wrote: >>> Hi Joe, >>> >>>

is what I am talking about. >>> >>> On the myriad of clean-ups that were needed to be done in JDBC, >>> getting rid of >>> these type of

blah

blocks was needed and just use

>>> >>> Best >>> Lance >>> On Jun 11, 2014, at 1:20 PM, huizhe wang >> > wrote: >>> >>>> >>>> On 6/11/2014 9:48 AM, Lance Andersen wrote: >>>>> Hi Joe, >>>>> >>>>> please change >>>>> >>>>> dont >>>>> >>>>> to >>>>> >>>>> don't >>>> >>>> Oops, I committed too quickly. But this is a dev comment, so we >>>> can fix that >>>> in the next patch. >>>> >>>>> >>>>> I would get rid of the

>>>> >>>> Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: >>>> If you have more than one paragraph in the doc comment, separate the >>>> paragraphs with a |

|paragraph tag, as shown. >>>> >>>> [1] >>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html >>>> >>>> >>>> -Joe >>>> >>>>> >>>>> otherwise it is OK >>>>> >>>>> Best >>>>> Lance >>>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>>> > wrote: >>>>> >>>>>> Fix some typos in the JAXP documentation. Please review. >>>>>> >>>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 vladimir.x.ivanov at oracle.com Tue Jun 17 09:06:35 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 17 Jun 2014 13:06:35 +0400 Subject: [9] RFR (XS): 8046903: VM anonymous class members can't be statically invocable In-Reply-To: <0FAA661B-3C00-4303-AE6B-99E63293F8B8@oracle.com> References: <539F205F.9040005@oracle.com> <0FAA661B-3C00-4303-AE6B-99E63293F8B8@oracle.com> Message-ID: <53A0051B.6000005@oracle.com> Thank you, John. Best regards, Vladimir Ivanov On 6/16/14 10:07 PM, John Rose wrote: > Reviewed. ? John > > On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8046903 >> >> j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish between VM anonymous classes and ordinary classes. In some very specific circumstances (VM anonymous class declared in one of predefined core packages), it can consider a member of VM anonymous class as statically invocable and symbolically reference it from generated bytecode. It's wrong because such class can't be looked up by name and the attempt to run such code ends up with NoClassDefFoundError. >> >> The fix is to disable static invocation for members of VM anonymous classes. >> >> Testing: regression test. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From pavel.rappo at oracle.com Tue Jun 17 12:32:37 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 17 Jun 2014 13:32:37 +0100 Subject: RFR JDK-8046768: com/sun/jndi/ldap/LdapTimeoutTest.java fails intermittently In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: Hi everyone, Could you please review my change for JDK-8046768? http://cr.openjdk.java.net/~prappo/8046768/webrev.00/ This change doesn't fix the issue. It barely adds a diagnostic output (LdapTimeoutTest.java:167) for the case that is failing. During my investigation I haven't been able to reproduce the issue in more than 1,500 test runs. But I believe the missing stacktrace of the NamingException could be diagnostically valuable in this case. Thanks -Pavel From pavel.rappo at oracle.com Tue Jun 17 12:49:35 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 17 Jun 2014 13:49:35 +0100 Subject: RFR JDK-8046768: com/sun/jndi/ldap/LdapTimeoutTest.java fails intermittently In-Reply-To: References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <2652452C-6DA2-436B-863A-FC64F92F91CD@oracle.com> I will close this bug with resolution "Cannot Reproduce" and create a new one. I think this should be the right way to go. Apologies. -Pavel On 17 Jun 2014, at 13:32, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8046768? > > http://cr.openjdk.java.net/~prappo/8046768/webrev.00/ > > This change doesn't fix the issue. It barely adds a diagnostic output (LdapTimeoutTest.java:167) for the case that is failing. During my investigation I haven't been able to reproduce the issue in more than 1,500 test runs. But I believe the missing stacktrace of the NamingException could be diagnostically valuable in this case. > > Thanks > -Pavel From roger.riggs at oracle.com Tue Jun 17 13:04:13 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 17 Jun 2014 09:04:13 -0400 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <539FC515.9060600@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com> <539FC515.9060600@oracle.com> Message-ID: <53A03CCD.3030803@oracle.com> Hi, It is easier to read and maintain the source code if there is less clutter and markup. Previous consensus seemed to be to omit closing html when not required. Roger On 6/17/2014 12:33 AM, huizhe wang wrote: > > On 6/16/2014 5:35 PM, Stuart Marks wrote: >> This is somewhat moot at this point, but.... >> >> I'd recommend against using paragraph end tags

. Paragraph end >> tags really are optional in HTML. I've heard some advocates of end >> tags, such as commenters on the linked web page, say that end tags >> are somehow "more correct" (wrong) or that end tags should be used >> "because XHTML" (javadoc is HTML4, not XHTML). > > It's not xhmtl, but I would think closing tags is a good practice. > Being explicit is always a good thing to do. It also provides a nice > structure (NetBeans would auto-close it with an indentation), e.g.: >

> this is paragraph 1 >

> > although, the JAXP javadoc wasn't written with any good structure. > >> >> The problem with using the

end tag is that it's easy for >> additional textual content to slip in afterward. This text would end >> up as part of the parent element. This might result in its being >> styled incorrectly or otherwise treated inconsistently with the rest >> of the text. > > That seems to be an argument for a closing tag. When a style is > specified for

, closing tag makes it clear where exactly it would > be applied -- it's content inside paragraphs, not the whole . If > there's anything "slipped" outside of the P tags, it would be an error. > >> For example, I happened to notice the following in one of the files >> in the patch, jaxp/src/javax/xml/namespace/QName.java: > > In this example, I think it was intentional by the author to add the > closing tag to separate the paragraphs, otherwise he would have to add > another

before . > >> >> *

To workaround this issue, serialVersionUID is set with either >> * a default value or a compatibility value. To use the >> * compatibility value, set the system property:

>> * >> * >> com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 >> * >> *

This workaround was inspired by classes in the >> javax.management >> * package, e.g. ObjectName, etc. >> >> Note that the text enclosed in the element is outside of any >> paragraph. If the style sheet were to have a distinct style for code >> appearing within a paragraph, that style wouldn't apply to the text >> in this example. > > with css, would have its own style. > >> >> It turns out that this text is from a private field in the QName >> class (serialVersionUID) so it's usually not rendered anyway, but I'd >> guess that there are other places where text has accidentally ended >> up outside of paragraph elements because a paragraph end tag was used >> and a paragraph start tag (or block start tag) was missing. >> >> >> >> s'marks >> >> P.S. Note that the start tag for the element is optional >> and is implied by context. > > haha, can be put to good use in our writings :-) > > -Joe > >> >> >> >> >> On 6/11/14 10:49 AM, huizhe wang wrote: >>> And, here is a good discussion on closing tags: >>> >>> http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm >>> >>> >>> >>> -Joe >>> >>> On 6/11/2014 10:24 AM, Lance Andersen wrote: >>>> Hi Joe, >>>> >>>>

is what I am talking about. >>>> >>>> On the myriad of clean-ups that were needed to be done in JDBC, >>>> getting rid of >>>> these type of

blah

blocks was needed and just use

>>>> >>>> Best >>>> Lance >>>> On Jun 11, 2014, at 1:20 PM, huizhe wang >>> > wrote: >>>> >>>>> >>>>> On 6/11/2014 9:48 AM, Lance Andersen wrote: >>>>>> Hi Joe, >>>>>> >>>>>> please change >>>>>> >>>>>> dont >>>>>> >>>>>> to >>>>>> >>>>>> don't >>>>> >>>>> Oops, I committed too quickly. But this is a dev comment, so we >>>>> can fix that >>>>> in the next patch. >>>>> >>>>>> >>>>>> I would get rid of the

>>>>> >>>>> Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: >>>>> If you have more than one paragraph in the doc comment, separate the >>>>> paragraphs with a |

|paragraph tag, as shown. >>>>> >>>>> [1] >>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html >>>>> >>>>> >>>>> -Joe >>>>> >>>>>> >>>>>> otherwise it is OK >>>>>> >>>>>> Best >>>>>> Lance >>>>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>>>> > wrote: >>>>>> >>>>>>> Fix some typos in the JAXP documentation. Please review. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 pavel.rappo at oracle.com Tue Jun 17 13:06:19 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 17 Jun 2014 14:06:19 +0100 Subject: RFR JDK-8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <513E8F19-36C6-40C2-B968-CEAF69F78941@oracle.com> Hi everyone, Could you please review my change for JDK-8047062? http://cr.openjdk.java.net/~prappo/8047062/webrev.00/ Thanks -Pavel From vincent.x.ryan at oracle.com Tue Jun 17 13:08:12 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 17 Jun 2014 14:08:12 +0100 Subject: RFR JDK-8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java In-Reply-To: <513E8F19-36C6-40C2-B968-CEAF69F78941@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <513E8F19-36C6-40C2-B968-CEAF69F78941@oracle.com> Message-ID: <645559F9-E831-446C-8F4C-A03626662ADB@oracle.com> Looks fine Pavel. On 17 Jun 2014, at 14:06, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8047062? > > http://cr.openjdk.java.net/~prappo/8047062/webrev.00/ > > Thanks > -Pavel From pbenedict at apache.org Tue Jun 17 13:31:52 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 17 Jun 2014 08:31:52 -0500 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <539FC515.9060600@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com> <539FC515.9060600@oracle.com> Message-ID: This thread is a good reference on JDK 8's lint enforcement of HTML in javadoc. You can see the reasons behind not allowing self-enclosing tags and enforcing HTML: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/thread.html#19269 Cheers, Paul On Mon, Jun 16, 2014 at 11:33 PM, huizhe wang wrote: > > On 6/16/2014 5:35 PM, Stuart Marks wrote: > >> This is somewhat moot at this point, but.... >> >> I'd recommend against using paragraph end tags

. Paragraph end tags >> really are optional in HTML. I've heard some advocates of end tags, such as >> commenters on the linked web page, say that end tags are somehow "more >> correct" (wrong) or that end tags should be used "because XHTML" (javadoc >> is HTML4, not XHTML). >> > > It's not xhmtl, but I would think closing tags is a good practice. Being > explicit is always a good thing to do. It also provides a nice structure > (NetBeans would auto-close it with an indentation), e.g.: >

> this is paragraph 1 >

> > although, the JAXP javadoc wasn't written with any good structure. > > >> The problem with using the

end tag is that it's easy for additional >> textual content to slip in afterward. This text would end up as part of the >> parent element. This might result in its being styled incorrectly or >> otherwise treated inconsistently with the rest of the text. >> > > That seems to be an argument for a closing tag. When a style is specified > for

, closing tag makes it clear where exactly it would be applied -- > it's content inside paragraphs, not the whole . If there's anything > "slipped" outside of the P tags, it would be an error. > > For example, I happened to notice the following in one of the files in >> the patch, jaxp/src/javax/xml/namespace/QName.java: >> > > In this example, I think it was intentional by the author to add the > closing tag to separate the paragraphs, otherwise he would have to add > another

before . > > >> *

To workaround this issue, serialVersionUID is set with either >> * a default value or a compatibility value. To use the >> * compatibility value, set the system property:

>> * >> * com.sun.xml.namespace.QName.useCompatibleSerialVersionUID= >> 1.0 >> * >> *

This workaround was inspired by classes in the javax.management >> * package, e.g. ObjectName, etc. >> >> Note that the text enclosed in the element is outside of any >> paragraph. If the style sheet were to have a distinct style for code >> appearing within a paragraph, that style wouldn't apply to the text in this >> example. >> > > with css, would have its own style. > > >> It turns out that this text is from a private field in the QName class >> (serialVersionUID) so it's usually not rendered anyway, but I'd guess that >> there are other places where text has accidentally ended up outside of >> paragraph elements because a paragraph end tag was used and a paragraph >> start tag (or block start tag) was missing. >> >> >> >> s'marks >> >> P.S. Note that the start tag for the element is optional and >> is implied by context. >> > > haha, can be put to good use in our writings :-) > > -Joe > > >> >> >> >> On 6/11/14 10:49 AM, huizhe wang wrote: >> >>> And, here is a good discussion on closing tags: >>> >>> http://webdesign.about.com/od/htmltags/qt/optional-html-end- >>> tags-when-to-include-them.htm >>> >>> >>> -Joe >>> >>> On 6/11/2014 10:24 AM, Lance Andersen wrote: >>> >>>> Hi Joe, >>>> >>>>

is what I am talking about. >>>> >>>> On the myriad of clean-ups that were needed to be done in JDBC, getting >>>> rid of >>>> these type of

blah

blocks was needed and just use

>>>> >>>> Best >>>> Lance >>>> On Jun 11, 2014, at 1:20 PM, huizhe wang >>> > wrote: >>>> >>>> >>>>> On 6/11/2014 9:48 AM, Lance Andersen wrote: >>>>> >>>>>> Hi Joe, >>>>>> >>>>>> please change >>>>>> >>>>>> dont >>>>>> >>>>>> to >>>>>> >>>>>> don't >>>>>> >>>>> >>>>> Oops, I committed too quickly. But this is a dev comment, so we can >>>>> fix that >>>>> in the next patch. >>>>> >>>>> >>>>>> I would get rid of the

>>>>>> >>>>> >>>>> Guide[1] for JavaDoc Tool suggests using

to separate paragraphs: >>>>> If you have more than one paragraph in the doc comment, separate the >>>>> paragraphs with a |

|paragraph tag, as shown. >>>>> >>>>> [1] >>>>> http://www.oracle.com/technetwork/java/javase/ >>>>> documentation/index-137868.html >>>>> >>>>> -Joe >>>>> >>>>> >>>>>> otherwise it is OK >>>>>> >>>>>> Best >>>>>> Lance >>>>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>>>> > wrote: >>>>>> >>>>>> Fix some typos in the JAXP documentation. Please review. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> La >>>>>> nce.Andersen at oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> La >>>> nce.Andersen at oracle.com >>>> >>>> >>>> >>>> >>>> >>>> >>> > From roger.riggs at oracle.com Tue Jun 17 14:21:27 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 17 Jun 2014 10:21:27 -0400 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <539F4FCE.9080903@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> <539F4A6A.5020002@oracle.com> <539F4FCE.9080903@oracle.com> Message-ID: <53A04EE7.6090309@oracle.com> Yes, that looks more consistent with the current versions. Though you want to see these for 8u, the preferred pattern is to make the changes in 9 and then backport the result (in this case adding the shared secrets aspect). Roger On 6/16/2014 4:13 PM, Claes Redestad wrote: > ... >> The terminology used in java.lang.String for offsets and indexes into >> strings would >> be provide a consistent base for talking about substrings. > If we're taking cues from String.substring, I guess int beginIndex[, > int fromIndex] would be more appropriate. How about: > > /** > * Parses the character sequence argument in the specified {@code > radix}, > * beginning at the specified {@code beginIndex} and extending to the > * character at index {@code endIndex - 1}. > * > * @see java.lang.Integer#parseInt(String, int) > * @param s the {@code CharSequence} containing the integer > * representation to be parsed > * @param radix the radix to be used while parsing {@code s}. > * @param beginIndex the beginning index, inclusive. > * @param endIndex the ending index, exclusive. > * @return the integer represented by the subsequence in the > * specified radix. > */ > static int parseInt(CharSequence s, int radix, int beginIndex, int > endIndex) > > ? > > Thanks! > > /Claes From claes.redestad at oracle.com Tue Jun 17 15:43:32 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 17 Jun 2014 17:43:32 +0200 Subject: RFR [9] 8041972: Add improved parse/format methods for Long/Integer In-Reply-To: <53A04EE7.6090309@oracle.com> References: <539CCE6D.6040207@oracle.com> <539D8821.3070808@univ-mlv.fr> <539D91A0.9050901@oracle.com> <539E1CB4.2050502@oracle.com> <539F4A6A.5020002@oracle.com> <539F4FCE.9080903@oracle.com> <53A04EE7.6090309@oracle.com> Message-ID: <53A06224.1040600@oracle.com> Ok, I'm working on improving code and comments based on feedback. I'll split the SharedSecrets part out, make the methods public and post a new webrev soon. /Claes On 06/17/2014 04:21 PM, roger riggs wrote: > Yes, that looks more consistent with the current versions. > > Though you want to see these for 8u, the preferred pattern is to make > the changes > in 9 and then backport the result (in this case adding the shared > secrets aspect). > > Roger > > > On 6/16/2014 4:13 PM, Claes Redestad wrote: >> ... >>> The terminology used in java.lang.String for offsets and indexes >>> into strings would >>> be provide a consistent base for talking about substrings. >> If we're taking cues from String.substring, I guess int beginIndex[, >> int fromIndex] would be more appropriate. How about: >> >> /** >> * Parses the character sequence argument in the specified {@code >> radix}, >> * beginning at the specified {@code beginIndex} and extending to >> the >> * character at index {@code endIndex - 1}. >> * >> * @see java.lang.Integer#parseInt(String, int) >> * @param s the {@code CharSequence} containing the integer >> * representation to be parsed >> * @param radix the radix to be used while parsing {@code s}. >> * @param beginIndex the beginning index, inclusive. >> * @param endIndex the ending index, exclusive. >> * @return the integer represented by the subsequence in the >> * specified radix. >> */ >> static int parseInt(CharSequence s, int radix, int beginIndex, >> int endIndex) >> >> ? >> >> Thanks! >> >> /Claes > From joel.franck at oracle.com Tue Jun 17 16:52:17 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 17 Jun 2014 18:52:17 +0200 Subject: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value Message-ID: <1B51A5CD-A909-42C4-97D1-1F8F5DFE55D2@oracle.com> Hi, Can I get a review for this fix and javadoc clarification for https://bugs.openjdk.java.net/browse/JDK-8044629 The problem is with potentially annotated receiver parameters, they only exist for inner class constructors, so this fix makes sure that a ctor is for an inner class or returns null (as for a static method) otherwise. CCC has been approved. Webrev: http://cr.openjdk.java.net/~jfranck/8044629/webrev.00/ cheers /Joel From stuart.marks at oracle.com Tue Jun 17 17:08:45 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 Jun 2014 10:08:45 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com> <539FC515.9060600@oracle.com> Message-ID: <53A0761D.3020804@oracle.com> Hi Paul, That thread, while interesting -- maybe :-) -- is about a somewhat different issue: self-closing tags as opposed to optional end tags. Self-closing tags were never part of HTML4 and thus are strictly illegal. In practice many people use them and many browsers accept them, leading to a discussion about whether javadoc should issue warnings or errors when encountering them. There's no question about the legality of using or omitting end tags in the case where they're specified to be optional, as in the case of the

element. The question is about whether using them is or isn't good practice. s'marks On 6/17/14 6:31 AM, Paul Benedict wrote: > This thread is a good reference on JDK 8's lint enforcement of HTML in > javadoc. You can see the reasons behind not allowing self-enclosing tags and > enforcing HTML: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/thread.html#19269 > > > Cheers, > Paul > > > On Mon, Jun 16, 2014 at 11:33 PM, huizhe wang > wrote: > > > On 6/16/2014 5:35 PM, Stuart Marks wrote: > > This is somewhat moot at this point, but.... > > I'd recommend against using paragraph end tags

. Paragraph end > tags really are optional in HTML. I've heard some advocates of end > tags, such as commenters on the linked web page, say that end tags are > somehow "more correct" (wrong) or that end tags should be used > "because XHTML" (javadoc is HTML4, not XHTML). > > > It's not xhmtl, but I would think closing tags is a good practice. Being > explicit is always a good thing to do. It also provides a nice structure > (NetBeans would auto-close it with an indentation), e.g.: >

> this is paragraph 1 >

> > although, the JAXP javadoc wasn't written with any good structure. > > > The problem with using the

end tag is that it's easy for > additional textual content to slip in afterward. This text would end > up as part of the parent element. This might result in its being > styled incorrectly or otherwise treated inconsistently with the rest > of the text. > > > That seems to be an argument for a closing tag. When a style is specified > for

, closing tag makes it clear where exactly it would be applied -- > it's content inside paragraphs, not the whole . If there's anything > "slipped" outside of the P tags, it would be an error. > > For example, I happened to notice the following in one of the files in > the patch, jaxp/src/javax/xml/namespace/QName.java: > > > In this example, I think it was intentional by the author to add the > closing tag to separate the paragraphs, otherwise he would have to add > another

before . > > > *

To workaround this issue, serialVersionUID is set with either > * a default value or a compatibility value. To use the > * compatibility value, set the system property:

> * > * > com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 > * > *

This workaround was inspired by classes in the javax.management > * package, e.g. ObjectName, etc. > > Note that the text enclosed in the element is outside of any > paragraph. If the style sheet were to have a distinct style for code > appearing within a paragraph, that style wouldn't apply to the text in > this example. > > > with css, would have its own style. > > > It turns out that this text is from a private field in the QName class > (serialVersionUID) so it's usually not rendered anyway, but I'd guess > that there are other places where text has accidentally ended up > outside of paragraph elements because a paragraph end tag was used and > a paragraph start tag (or block start tag) was missing. > > > > s'marks > > P.S. Note that the start tag for the element is optional > and is implied by context. > > > haha, can be put to good use in our writings :-) > > -Joe > > > > > > On 6/11/14 10:49 AM, huizhe wang wrote: > > And, here is a good discussion on closing tags: > > http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm > > > > -Joe > > On 6/11/2014 10:24 AM, Lance Andersen wrote: > > Hi Joe, > >

is what I am talking about. > > On the myriad of clean-ups that were needed to be done in > JDBC, getting rid of > these type of

blah

blocks was needed and just use

> > Best > Lance > On Jun 11, 2014, at 1:20 PM, huizhe wang > > >> wrote: > > > On 6/11/2014 9:48 AM, Lance Andersen wrote: > > Hi Joe, > > please change > > dont > > to > > don't > > > Oops, I committed too quickly. But this is a dev comment, > so we can fix that > in the next patch. > > > I would get rid of the

> > > Guide[1] for JavaDoc Tool suggests using

to separate > paragraphs: > If you have more than one paragraph in the doc comment, > separate the > paragraphs with a |

|paragraph tag, as shown. > > [1] > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html > > > -Joe > > > otherwise it is OK > > Best > Lance > On Jun 11, 2014, at 11:54 AM, huizhe wang > > >> wrote: > > Fix some typos in the JAXP documentation. Please > review. > > http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ > > > > Thanks, > Joe > > > > > > > > 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 huizhe.wang at oracle.com Tue Jun 17 19:19:54 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 17 Jun 2014 12:19:54 -0700 Subject: RFR JDK-5077522 : Duration.compare incorrect for some values Message-ID: <53A094DA.1000905@oracle.com> Hi, This is a long time compatibility issue: Duration.compare returns equal for INDETERMINATE relations defined in XML Schema standard (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the following table: Relation P*1Y* > P*364D* <> P*365D* <> P*366D* < P*367D* P*1M* > P*27D* <> P*28D* <> P*29D* <> P*30D* <> P*31D* < P*32D* P*5M* > P*149D* <> P*150D* <> P*151D* <> P*152D* <> P*153D* < P*154D* The order-relation of two Duratoin values x and y is x < y iff s+x < s+y for each qualified datetime s listed below: * 1696-09-01T00:00:00Z * 1697-02-01T00:00:00Z * 1903-03-01T00:00:00Z * 1903-07-01T00:00:00Z The original implementation used Unix epoch, that is, 00:00:00 UTC on 1 January 1970, as s in the above calculation which violated the above specification. A patch during JDK 6 development added correct implementation of the spec, but it was unfortunately added after the original calculation using Epoch time. *The fix to the issue therefore is simply removing the calculation using Epoch time.* I also consolidated the tedious max field value checks into a method called checkMaxValue. *Patch:* http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/ Test: testCompareWithInderterminateRelation: this is a copy of the JCK test that tests INDETERMINATE relations. testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1 second to the original test cases. For example, to the original test: PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y" Below is the test result: Comparing P1Y and P365D: INDETERMINATE Comparing P1Y and P366D: INDETERMINATE Comparing P1M and P28D: INDETERMINATE Comparing P1M and P29D: INDETERMINATE Comparing P1M and P30D: INDETERMINATE Comparing P1M and P31D: INDETERMINATE Comparing P5M and P150D: INDETERMINATE Comparing P5M and P151D: INDETERMINATE Comparing P5M and P152D: INDETERMINATE Comparing P5M and P153D: INDETERMINATE Comparing PT2419200S and P1M: INDETERMINATE Comparing PT2678400S and P1M: INDETERMINATE Comparing PT31536000S and P1Y: INDETERMINATE Comparing PT31622400S and P1Y: INDETERMINATE Comparing PT525600M and P1Y: INDETERMINATE Comparing PT527040M and P1Y: INDETERMINATE Comparing PT8760H and P1Y: INDETERMINATE Comparing PT8784H and P1Y: INDETERMINATE Comparing P365D and P1Y: INDETERMINATE Comparing P1Y and P364D: expected: GREATER actual: GREATER Comparing P1Y and P367D: expected: LESSER actual: LESSER Comparing P1Y2D and P366D: expected: GREATER actual: GREATER Comparing P1M and P27D: expected: GREATER actual: GREATER Comparing P1M and P32D: expected: LESSER actual: LESSER Comparing P1M and P31DT1H: expected: LESSER actual: LESSER Comparing P5M and P149D: expected: GREATER actual: GREATER Comparing P5M and P154D: expected: LESSER actual: LESSER Comparing P5M and P153DT1H: expected: LESSER actual: LESSER Comparing PT2419199S and P1M: expected: LESSER actual: LESSER Comparing PT2678401S and P1M: expected: GREATER actual: GREATER Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER Number of tests passed: 36 Number of tests failed: 0 Thanks, Joe From stuart.marks at oracle.com Tue Jun 17 22:38:49 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 Jun 2014 15:38:49 -0700 Subject: RFR: 8046443 : A few typos in JAXP JavaDoc In-Reply-To: <539FC515.9060600@oracle.com> References: <53987BB9.50407@oracle.com> <81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com> <53988FEA.3090701@oracle.com> <8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com> <539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com> <539FC515.9060600@oracle.com> Message-ID: <53A0C379.5050404@oracle.com> On 6/16/14 9:33 PM, huizhe wang wrote: > It's not xhmtl, but I would think closing tags is a good practice. Being > explicit is always a good thing to do. Being explicit sounds good, but in this case it leads to errors; see below. >> The problem with using the

end tag is that it's easy for additional >> textual content to slip in afterward. This text would end up as part of the >> parent element. This might result in its being styled incorrectly or otherwise >> treated inconsistently with the rest of the text. > > That seems to be an argument for a closing tag. When a style is specified for >

, closing tag makes it clear where exactly it would be applied -- it's > content inside paragraphs, not the whole . If there's anything "slipped" > outside of the P tags, it would be an error. If content slips outside of a

element, it's indeed an error. (*1) But it's almost impossible for this to happen if you omit the

end tag. If one doesn't use

end tags, the

element can only be implicitly closed by a) closing its enclosing element, e.g.,

; or b) by starting a new block-level element such as a
,

, etc., or another

element. With this approach the text is always (*2) going to be within some block-level element. By contrast, if one were to use

end tags, there is the possibility between every paragraph for text to appear, which means that it would be outside of any paragraph element. The use of

end tags creates this possibility, and thus this increases the possibility of error. *1 - not an error in the sense of being a syntax error, or one that javadoc would warn or raise an error about, but a semantic error in that text would occur in an inappropriate place in the document structure. *2 - well, not always. It's possible for text to be outside of any block element at the very beginning of the element, such as after but before the first

or other block-level element. >> For example, I happened to notice the following in one of the files in the >> patch, jaxp/src/javax/xml/namespace/QName.java: > > In this example, I think it was intentional by the author to add the closing tag > to separate the paragraphs, otherwise he would have to add another

before > . > >> *

To workaround this issue, serialVersionUID is set with either >> * a default value or a compatibility value. To use the >> * compatibility value, set the system property:

>> * >> * com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 >> * >> *

This workaround was inspired by classes in the javax.management >> * package, e.g. ObjectName, etc. >> >> Note that the text enclosed in the element is outside of any paragraph. >> If the style sheet were to have a distinct style for code appearing within a >> paragraph, that style wouldn't apply to the text in this example. I'm not sure what the author's intent was, but it looks like a mistake to me. The problem is that is an inline element and can appear within a

or other block element. Unlike block elements, an inline element doesn't implicitly close a

element. The author might have thought that itself was a block element and thus didn't need to be enclosed by a block element, but this isn't the case. What's probably necessary here is for the text within to be enclosed within a block element, such as

,

, or 
.

> with css,  would have its own style.

It does, but it's possible for the style sheet to have styles for descendant 
(enclosed) elements, or for styles to inherit properties from enclosing 
elements. For example, a style sheet might have these declarations:

     p code { blag bleg blig; }
     pre code { bazz bizz buzz; }

This would style  text differently within 
 elements from  text 
within 
 elements. But these declarations would miss the  text from
QName.java, because it doesn't occur within these elements.

* * *

Now, this really is moot, since the offending example is on a private field that 
will almost never get rendered, the stylesheet doesn't in fact use that style of 
CSS selector, and the prevailing style of the javadoc in this area is to use 

 end tags. It's probably not worth it to go in and remove all the end tags, 
and it's certainly not worth it if we're taking code from upstream somewhere 
that is already marked-up this way. So don't consider this to be a proposal or 
an exhortation to clean out all the 
 end tags.

But if you're writing new javadoc, I recommend that you not use 
 end tags.

(Also, as Roger pointed out, they add clutter.)

s'marks



>
>>
>> It turns out that this text is from a private field in the QName class
>> (serialVersionUID) so it's usually not rendered anyway, but I'd guess that
>> there are other places where text has accidentally ended up outside of
>> paragraph elements because a paragraph end tag was used and a paragraph start
>> tag (or block start tag) was missing.
>>
>> 
>>
>> s'marks
>>
>> P.S. Note that the start tag for the  element is optional and is
>> implied by context.
>
> haha,  can be put to good use in our writings :-)
>
> -Joe
>
>>
>>
>>
>>
>> On 6/11/14 10:49 AM, huizhe wang wrote:
>>> And, here is a good discussion on closing tags:
>>>
>>> http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm
>>>
>>>
>>>
>>> -Joe
>>>
>>> On 6/11/2014 10:24 AM, Lance Andersen wrote:
>>>> Hi Joe,
>>>>
>>>> 
  is what I am talking about.
>>>>
>>>> On the myriad of clean-ups that were needed to be done in JDBC, getting rid of
>>>> these type of 
blah
 blocks was needed and just use 

>>>>
>>>> Best
>>>> Lance
>>>> On Jun 11, 2014, at 1:20 PM, huizhe wang >>> > wrote:
>>>>
>>>>>
>>>>> On 6/11/2014 9:48 AM, Lance Andersen wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> please change
>>>>>>
>>>>>> dont
>>>>>>
>>>>>> to
>>>>>>
>>>>>>  don't
>>>>>
>>>>> Oops, I committed too quickly.  But this is a dev comment, so we can fix that
>>>>> in the next patch.
>>>>>
>>>>>>
>>>>>> I would get rid of the 

>>>>>
>>>>> Guide[1] for JavaDoc Tool suggests using 
 to separate paragraphs:
>>>>> If you have more than one paragraph in the doc comment, separate the
>>>>> paragraphs with a |
|paragraph tag, as shown.
>>>>>
>>>>> [1]
>>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
>>>>>
>>>>> -Joe
>>>>>
>>>>>>
>>>>>> otherwise it is OK
>>>>>>
>>>>>> Best
>>>>>> Lance
>>>>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>>>> > wrote:
>>>>>>
>>>>>>> Fix some typos in the JAXP documentation.  Please review.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/
>>>>>>> 
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 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 david.holmes at oracle.com  Wed Jun 18 01:39:20 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jun 2014 11:39:20 +1000
Subject: contains for TreeSet
In-Reply-To: 
References: 
Message-ID: <53A0EDC8.1040109@oracle.com>

Moving your question to core-libs-dev, please drop build-dev from all 
future responses.

David

On 18/06/2014 10:56 AM, Su wrote:
> May I ask why "contains" method of TreeSet uses the comparator to decide if
> two objects are equals, but not the equals method of the object?
>
> Thank you.
>


From martinrb at google.com  Wed Jun 18 02:10:39 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 17 Jun 2014 19:10:39 -0700
Subject: contains for TreeSet
In-Reply-To: <53A0EDC8.1040109@oracle.com>
References: 
	<53A0EDC8.1040109@oracle.com>
Message-ID: 

It's explained in the TreeSet javadoc.


On Tue, Jun 17, 2014 at 6:39 PM, David Holmes 
wrote:

> Moving your question to core-libs-dev, please drop build-dev from all
> future responses.
>
> David
>
>
> On 18/06/2014 10:56 AM, Su wrote:
>
>> May I ask why "contains" method of TreeSet uses the comparator to decide
>> if
>> two objects are equals, but not the equals method of the object?
>>
>> Thank you.
>>
>>


From alexandr.scherbatiy at oracle.com  Wed Jun 18 10:44:31 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 18 Jun 2014 14:44:31 +0400
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53979C10.1080307@oracle.com>
References: <53979C10.1080307@oracle.com>
Message-ID: <53A16D8F.1060103@oracle.com>


   The fix looks good for me.

   Thanks,
   Alexandr.

On 6/11/2014 4:00 AM, Henry Jen wrote:
> Hi,
>
> Please review a trivial webrev that provides missing @since tag for 
> elements under javax.swing,
>
> Essentially it's simply add @since 1.2 for all 
> classes/interfaces/exception that are missing @since tag, as JDK 1.2 
> package.html has @since tag but was removed in 1.3.
>
> The @since tag is added to *.java instead of package.html so that we 
> can have javac report javadoc via 
> javax.lang.model.util.Elements.getDocComment(Element c).
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>
> Cheers,
> Henry



From otaviojava at java.net  Wed Jun 18 12:11:00 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Wed, 18 Jun 2014 09:11:00 -0300
Subject: Character, Byte, Short valueOf instead of new instance
In-Reply-To: 
References: 
Message-ID: 

Could anyone see my this path, please?



On Sat, Jun 14, 2014 at 1:38 PM, Ot?vio Gon?alves de Santana <
otaviojava at java.net> wrote:

> Reason: The Character, Byte, Short classes have cache and using it, will
> save memory and will faster than using create new instance.
>
> webrev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip
>
> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
>
> --
> 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 otaviojava at java.net  Wed Jun 18 12:11:16 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Wed, 18 Jun 2014 09:11:16 -0300
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
Message-ID: 

Could anyone see my this path, please?



On Sat, Jun 14, 2014 at 10:46 AM, Ot?vio Gon?alves de Santana <
otaviojava at java.net> wrote:

> Reason: The Long class has cache and using it, will save memory and will
> faster than using create new instance of Long.
>
> webrev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
>
> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> --
> 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 henry.jen at oracle.com  Wed Jun 18 16:16:50 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Jun 2014 09:16:50 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A16D8F.1060103@oracle.com>
References: <53979C10.1080307@oracle.com> <53A16D8F.1060103@oracle.com>
Message-ID: <53A1BB72.2060609@oracle.com>

Thanks, Alexander.

Cheers,
Henry

On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>
>    The fix looks good for me.
>
>    Thanks,
>    Alexandr.
>
> On 6/11/2014 4:00 AM, Henry Jen wrote:
>> Hi,
>>
>> Please review a trivial webrev that provides missing @since tag for
>> elements under javax.swing,
>>
>> Essentially it's simply add @since 1.2 for all
>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>> package.html has @since tag but was removed in 1.3.
>>
>> The @since tag is added to *.java instead of package.html so that we
>> can have javac report javadoc via
>> javax.lang.model.util.Elements.getDocComment(Element c).
>>
>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>
>> Cheers,
>> Henry
>


From huizhe.wang at oracle.com  Wed Jun 18 16:34:45 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 18 Jun 2014 09:34:45 -0700
Subject: writing JavaDoc-> Re: RFR: 8046443 : A few typos in JAXP JavaDoc
In-Reply-To: <53A0C379.5050404@oracle.com>
References: <53987BB9.50407@oracle.com>	<81AE8906-9B95-40B5-9ECB-460C3ED2795D@oracle.com>	<53988FEA.3090701@oracle.com>	<8D591278-90CB-4FF6-8273-F0673BD5439A@oracle.com>
	<539896B5.1000102@oracle.com> <539F8D34.5020408@oracle.com>
	<539FC515.9060600@oracle.com> <53A0C379.5050404@oracle.com>
Message-ID: <53A1BFA5.40406@oracle.com>

Thanks Stuart for the good discussion. It reminds us that optional tags 
may be not optional since we're writing Doc Comments that will become 
part of the spec and affect overall look of it.

The issues you pointed out below may be true generally when writing 
 
tag in a html file. However, we're talking about the JavaDoc here. The 
Doc Comments consist of two parts: a description followed by block tags. 
The JavaDoc tool will put the description in a 
 block, so no 
content will be outside of the block. (the block tags will be in 
Description List 
 by the way). In Doc Comments, a 
 tag serves 
only to separate paragraphs.

As for clutter, you probably hate xml then :-)  I consider html tags are 
generally short and tidy. But again, it's preference, if no 
 is the 
norm, I'll do the same.

-Joe

On 6/17/2014 3:38 PM, Stuart Marks wrote:
> On 6/16/14 9:33 PM, huizhe wang wrote:
>> It's not xhmtl, but I would think closing tags is a good practice. Being
>> explicit is always a good thing to do.
>
> Being explicit sounds good, but in this case it leads to errors; see 
> below.
>
>>> The problem with using the 
 end tag is that it's easy for 
>>> additional
>>> textual content to slip in afterward. This text would end up as part 
>>> of the
>>> parent element. This might result in its being styled incorrectly or 
>>> otherwise
>>> treated inconsistently with the rest of the text.
>>
>> That seems to be an argument for a closing tag. When a style is 
>> specified for
>> 
, closing tag makes it clear where exactly it would be applied -- 
>> it's
>> content inside paragraphs, not the whole . If there's anything 
>> "slipped"
>> outside of the P tags, it would be an error.
>
> If content slips outside of a 
 element, it's indeed an error. (*1) 
> But it's almost impossible for this to happen if you omit the 
 end 
> tag. If one doesn't use 
 end tags, the 
 element can only be 
> implicitly closed by a) closing its enclosing element, e.g., 
; or 
> b) by starting a new block-level element such as a 
, 
, etc., 
> or another 
 element. With this approach the text is always (*2) 
> going to be within some block-level element.
>
> By contrast, if one were to use 
 end tags, there is the 
> possibility between every paragraph for text to appear, which means 
> that it would be outside of any paragraph element. The use of 
 end 
> tags creates this possibility, and thus this increases the possibility 
> of error.
>
> *1 - not an error in the sense of being a syntax error, or one that 
> javadoc would warn or raise an error about, but a semantic error in 
> that text would occur in an inappropriate place in the document 
> structure.
>
> *2 - well, not always. It's possible for text to be outside of any 
> block element at the very beginning of the element, such as after 
>  but before the first 
 or other block-level element.
>
>>> For example, I happened to notice the following in one of the files 
>>> in the
>>> patch, jaxp/src/javax/xml/namespace/QName.java:
>>
>> In this example, I think it was intentional by the author to add the 
>> closing tag
>> to separate the paragraphs, otherwise he would have to add another 
>> 
 before
>> .
>>
>>>      * 
To workaround this issue, serialVersionUID is set with either
>>>      * a default value or a compatibility value.  To use the
>>>      * compatibility value, set the system property:

>>>      *
>>>      * 
>>> com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
>>>      *
>>>      * 
This workaround was inspired by classes in the 
>>> javax.management
>>>      * package, e.g. ObjectName, etc.
>>>
>>> Note that the text enclosed in the  element is outside of any 
>>> paragraph.
>>> If the style sheet were to have a distinct style for code appearing 
>>> within a
>>> paragraph, that style wouldn't apply to the text in this example.
>
> I'm not sure what the author's intent was, but it looks like a mistake 
> to me. The problem is that  is an inline element and can appear 
> within a 
 or other block element. Unlike block elements, an inline 
> element doesn't implicitly close a 
 element. The author might have 
> thought that  itself was a block element and thus didn't need to 
> be enclosed by a block element, but this isn't the case.
>
> What's probably necessary here is for the text within  to be 
> enclosed within a block element, such as 
, 
, or 
.
>
>> with css,  would have its own style.
>
> It does, but it's possible for the style sheet to have styles for 
> descendant (enclosed) elements, or for styles to inherit properties 
> from enclosing elements. For example, a style sheet might have these 
> declarations:
>
>     p code { blag bleg blig; }
>     pre code { bazz bizz buzz; }
>
> This would style  text differently within 
 elements from 
>  text within 
 elements. But these declarations would miss 
> the  text from
> QName.java, because it doesn't occur within these elements.
>
> * * *
>
> Now, this really is moot, since the offending example is on a private 
> field that will almost never get rendered, the stylesheet doesn't in 
> fact use that style of CSS selector, and the prevailing style of the 
> javadoc in this area is to use 
 end tags. It's probably not worth 
> it to go in and remove all the end tags, and it's certainly not worth 
> it if we're taking code from upstream somewhere that is already 
> marked-up this way. So don't consider this to be a proposal or an 
> exhortation to clean out all the 
 end tags.
>
> But if you're writing new javadoc, I recommend that you not use 
 
> end tags.
>
> (Also, as Roger pointed out, they add clutter.)
>
> s'marks
>
>
>
>>
>>>
>>> It turns out that this text is from a private field in the QName class
>>> (serialVersionUID) so it's usually not rendered anyway, but I'd 
>>> guess that
>>> there are other places where text has accidentally ended up outside of
>>> paragraph elements because a paragraph end tag was used and a 
>>> paragraph start
>>> tag (or block start tag) was missing.
>>>
>>> 
>>>
>>> s'marks
>>>
>>> P.S. Note that the start tag for the  element is optional 
>>> and is
>>> implied by context.
>>
>> haha,  can be put to good use in our writings :-)
>>
>> -Joe
>>
>>>
>>>
>>>
>>>
>>> On 6/11/14 10:49 AM, huizhe wang wrote:
>>>> And, here is a good discussion on closing tags:
>>>>
>>>> http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm 
>>>>
>>>>
>>>>
>>>>
>>>> -Joe
>>>>
>>>> On 6/11/2014 10:24 AM, Lance Andersen wrote:
>>>>> Hi Joe,
>>>>>
>>>>> 
  is what I am talking about.
>>>>>
>>>>> On the myriad of clean-ups that were needed to be done in JDBC, 
>>>>> getting rid of
>>>>> these type of 
blah
 blocks was needed and just use 

>>>>>
>>>>> Best
>>>>> Lance
>>>>> On Jun 11, 2014, at 1:20 PM, huizhe wang >>>> > wrote:
>>>>>
>>>>>>
>>>>>> On 6/11/2014 9:48 AM, Lance Andersen wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> please change
>>>>>>>
>>>>>>> dont
>>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>>  don't
>>>>>>
>>>>>> Oops, I committed too quickly.  But this is a dev comment, so we 
>>>>>> can fix that
>>>>>> in the next patch.
>>>>>>
>>>>>>>
>>>>>>> I would get rid of the 

>>>>>>
>>>>>> Guide[1] for JavaDoc Tool suggests using 
 to separate paragraphs:
>>>>>> If you have more than one paragraph in the doc comment, separate the
>>>>>> paragraphs with a |
|paragraph tag, as shown.
>>>>>>
>>>>>> [1]
>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html 
>>>>>>
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>>
>>>>>>> otherwise it is OK
>>>>>>>
>>>>>>> Best
>>>>>>> Lance
>>>>>>> On Jun 11, 2014, at 11:54 AM, huizhe wang >>>>>> > wrote:
>>>>>>>
>>>>>>>> Fix some typos in the JAXP documentation.  Please review.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/
>>>>>>>> 
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> 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 philip.race at oracle.com  Wed Jun 18 17:44:30 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Jun 2014 10:44:30 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A1BB72.2060609@oracle.com>
References: <53979C10.1080307@oracle.com> <53A16D8F.1060103@oracle.com>
	<53A1BB72.2060609@oracle.com>
Message-ID: <53A1CFFE.4070606@oracle.com>

Hello,

You say "under" javax.swing but you don't seem to be touching
any sub-packages. I notice there is at least one @since 1.7 you
added to the Painter interface - so they aren't all 1.2 - and yet
you didn't add the @since 1.7 to the sole class that implements
Painter - perhaps because its in a sub-package.

Also note that whilst @since 1.2 is strictly correct in terms of Java SE
but Swing was initially an unbundled library - somewhat analagous
to Java FX 2.x, and ran on JDK 1.1.x

-phil.

On 6/18/2014 9:16 AM, Henry Jen wrote:
> Thanks, Alexander.
>
> Cheers,
> Henry
>
> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>
>>    The fix looks good for me.
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a trivial webrev that provides missing @since tag for
>>> elements under javax.swing,
>>>
>>> Essentially it's simply add @since 1.2 for all
>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>> package.html has @since tag but was removed in 1.3.
>>>
>>> The @since tag is added to *.java instead of package.html so that we
>>> can have javac report javadoc via
>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>
>>> Cheers,
>>> Henry
>>



From henry.jen at oracle.com  Wed Jun 18 18:11:38 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Jun 2014 11:11:38 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A1CFFE.4070606@oracle.com>
References: <53979C10.1080307@oracle.com> <53A16D8F.1060103@oracle.com>
	<53A1BB72.2060609@oracle.com> <53A1CFFE.4070606@oracle.com>
Message-ID: <53A1D65A.9070701@oracle.com>



On 06/18/2014 10:44 AM, Phil Race wrote:
> Hello,
>
> You say "under" javax.swing but you don't seem to be touching
> any sub-packages.

No, sub-packages has @since in correponding package.html. I use * to 
mean entitiy in this package, and ** to signal subpackage as well.

If it helps, I can remove .* from the subject.

> I notice there is at least one @since 1.7 you
> added to the Painter interface - so they aren't all 1.2 - and yet
> you didn't add the @since 1.7 to the sole class that implements
> Painter - perhaps because its in a sub-package.
>

It's used in javax.swing.plaf.nimbus, which has @since 1.7.

> Also note that whilst @since 1.2 is strictly correct in terms of Java SE
> but Swing was initially an unbundled library - somewhat analagous
> to Java FX 2.x, and ran on JDK 1.1.x
>

Understood. We are focus to make sure @since has the first version since 
the inclusion in J2SE. Other version information, as Mark suggested, can 
be expressed after comma. In case Java FX is included in JDK9, we would 
expect it to have have @since 1.9, Java FX x.x.

As swing component currenly doesn't have that extra version information, 
we will simply mark the J2SE debut.

Cheers,
Henry

> -phil.
>
> On 6/18/2014 9:16 AM, Henry Jen wrote:
>> Thanks, Alexander.
>>
>> Cheers,
>> Henry
>>
>> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>>
>>>    The fix looks good for me.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>>> Hi,
>>>>
>>>> Please review a trivial webrev that provides missing @since tag for
>>>> elements under javax.swing,
>>>>
>>>> Essentially it's simply add @since 1.2 for all
>>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>>> package.html has @since tag but was removed in 1.3.
>>>>
>>>> The @since tag is added to *.java instead of package.html so that we
>>>> can have javac report javadoc via
>>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>>
>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>>
>>>> Cheers,
>>>> Henry
>>>
>


From mandy.chung at oracle.com  Wed Jun 18 18:22:08 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Jun 2014 11:22:08 -0700
Subject: Review request:  8044063: Remove com.sun.java.browser.* from jdk repo
Message-ID: <53A1D8D0.4060000@oracle.com>

com.sun.java.browser.dom and com.sun.java.browser.net classes
are legacy and only used by old plugin.  Time to remove them.

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/

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

Jon - having a second thought and decide to clean up
the CreateSymbols of the removal of these packages just for
completeness.  Can you review the langtools change?

Thanks
Mandy



From Alan.Bateman at oracle.com  Wed Jun 18 18:27:47 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Jun 2014 19:27:47 +0100
Subject: Review request:  8044063: Remove com.sun.java.browser.* from
	jdk repo
In-Reply-To: <53A1D8D0.4060000@oracle.com>
References: <53A1D8D0.4060000@oracle.com>
Message-ID: <53A1DA23.90107@oracle.com>

On 18/06/2014 19:22, Mandy Chung wrote:
> com.sun.java.browser.dom and com.sun.java.browser.net classes
> are legacy and only used by old plugin.  Time to remove them.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/
>
Good to see this being removed, the changes looks good to me.

-Alan.


From joe.darcy at oracle.com  Wed Jun 18 18:32:44 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 18 Jun 2014 11:32:44 -0700
Subject: Review request:  8044063: Remove com.sun.java.browser.* from
	jdk repo
In-Reply-To: <53A1DA23.90107@oracle.com>
References: <53A1D8D0.4060000@oracle.com> <53A1DA23.90107@oracle.com>
Message-ID: <53A1DB4C.6030302@oracle.com>

On 06/18/2014 11:27 AM, Alan Bateman wrote:
> On 18/06/2014 19:22, Mandy Chung wrote:
>> com.sun.java.browser.dom and com.sun.java.browser.net classes
>> are legacy and only used by old plugin.  Time to remove them.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/
>>
> Good to see this being removed, the changes looks good to me.
>
> -Alan.

Yes, good to see these legacy classes being removed!

-Joe


From philip.race at oracle.com  Wed Jun 18 21:42:51 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Jun 2014 14:42:51 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A1D65A.9070701@oracle.com>
References: <53979C10.1080307@oracle.com> <53A16D8F.1060103@oracle.com>
	<53A1BB72.2060609@oracle.com> <53A1CFFE.4070606@oracle.com>
	<53A1D65A.9070701@oracle.com>
Message-ID: <53A207DB.7020402@oracle.com>

So for the specific case of the nimbus class I can see that the entire
package was new in 1.7 so the individual classes added at that time
do not need an @since tag.

But my main question was whether you have inspected all
classes in all swing packages and none were fouhd in need of an
update .. I suppose its likely that after 1.2 people were more
diligent in adding these tags.

Assuming the answer is yes, then I'm OK. If no, then I'm OK
too although at least then we'd know you still had to do those
packages ..

-phil.

On 6/18/2014 11:11 AM, Henry Jen wrote:
>
>
> On 06/18/2014 10:44 AM, Phil Race wrote:
>> Hello,
>>
>> You say "under" javax.swing but you don't seem to be touching
>> any sub-packages.
>
> No, sub-packages has @since in correponding package.html. I use * to 
> mean entitiy in this package, and ** to signal subpackage as well.
>
> If it helps, I can remove .* from the subject.
>
>> I notice there is at least one @since 1.7 you
>> added to the Painter interface - so they aren't all 1.2 - and yet
>> you didn't add the @since 1.7 to the sole class that implements
>> Painter - perhaps because its in a sub-package.
>>
>
> It's used in javax.swing.plaf.nimbus, which has @since 1.7.
>
>> Also note that whilst @since 1.2 is strictly correct in terms of Java SE
>> but Swing was initially an unbundled library - somewhat analagous
>> to Java FX 2.x, and ran on JDK 1.1.x
>>
>
> Understood. We are focus to make sure @since has the first version 
> since the inclusion in J2SE. Other version information, as Mark 
> suggested, can be expressed after comma. In case Java FX is included 
> in JDK9, we would expect it to have have @since 1.9, Java FX x.x.
>
> As swing component currenly doesn't have that extra version 
> information, we will simply mark the J2SE debut.
>
> Cheers,
> Henry
>
>> -phil.
>>
>> On 6/18/2014 9:16 AM, Henry Jen wrote:
>>> Thanks, Alexander.
>>>
>>> Cheers,
>>> Henry
>>>
>>> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>>>
>>>>    The fix looks good for me.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>>>> Hi,
>>>>>
>>>>> Please review a trivial webrev that provides missing @since tag for
>>>>> elements under javax.swing,
>>>>>
>>>>> Essentially it's simply add @since 1.2 for all
>>>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>>>> package.html has @since tag but was removed in 1.3.
>>>>>
>>>>> The @since tag is added to *.java instead of package.html so that we
>>>>> can have javac report javadoc via
>>>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>>>
>>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>
>>



From henry.jen at oracle.com  Wed Jun 18 22:25:15 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Jun 2014 15:25:15 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A207DB.7020402@oracle.com>
References: <53979C10.1080307@oracle.com> <53A16D8F.1060103@oracle.com>
	<53A1BB72.2060609@oracle.com> <53A1CFFE.4070606@oracle.com>
	<53A1D65A.9070701@oracle.com> <53A207DB.7020402@oracle.com>
Message-ID: <53A211CB.5040009@oracle.com>

On 06/18/2014 02:42 PM, Phil Race wrote:
> So for the specific case of the nimbus class I can see that the entire
> package was new in 1.7 so the individual classes added at that time
> do not need an @since tag.
>
> But my main question was whether you have inspected all
> classes in all swing packages and none were fouhd in need of an
> update .. I suppose its likely that after 1.2 people were more
> diligent in adding these tags.
>
> Assuming the answer is yes, then I'm OK. If no, then I'm OK
> too although at least then we'd know you still had to do those
> packages ..
>

I inspected all APIs without a @since.
@since implies to enclosed entities, so if a package has @since tag, it 
implies all classes/interfaces has same @since if not otherwise 
specified, and class implies all member fields or methods.

 From the analysis by a tool I wrote, all classes in javax.swing now 
have @since excepted generated javax.swing.*BeanInfo.

Cheers,
Henry

> -phil.
>
> On 6/18/2014 11:11 AM, Henry Jen wrote:
>>
>>
>> On 06/18/2014 10:44 AM, Phil Race wrote:
>>> Hello,
>>>
>>> You say "under" javax.swing but you don't seem to be touching
>>> any sub-packages.
>>
>> No, sub-packages has @since in correponding package.html. I use * to
>> mean entitiy in this package, and ** to signal subpackage as well.
>>
>> If it helps, I can remove .* from the subject.
>>
>>> I notice there is at least one @since 1.7 you
>>> added to the Painter interface - so they aren't all 1.2 - and yet
>>> you didn't add the @since 1.7 to the sole class that implements
>>> Painter - perhaps because its in a sub-package.
>>>
>>
>> It's used in javax.swing.plaf.nimbus, which has @since 1.7.
>>
>>> Also note that whilst @since 1.2 is strictly correct in terms of Java SE
>>> but Swing was initially an unbundled library - somewhat analagous
>>> to Java FX 2.x, and ran on JDK 1.1.x
>>>
>>
>> Understood. We are focus to make sure @since has the first version
>> since the inclusion in J2SE. Other version information, as Mark
>> suggested, can be expressed after comma. In case Java FX is included
>> in JDK9, we would expect it to have have @since 1.9, Java FX x.x.
>>
>> As swing component currenly doesn't have that extra version
>> information, we will simply mark the J2SE debut.
>>
>> Cheers,
>> Henry
>>
>>> -phil.
>>>
>>> On 6/18/2014 9:16 AM, Henry Jen wrote:
>>>> Thanks, Alexander.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>    The fix looks good for me.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>
>>>>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review a trivial webrev that provides missing @since tag for
>>>>>> elements under javax.swing,
>>>>>>
>>>>>> Essentially it's simply add @since 1.2 for all
>>>>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>>>>> package.html has @since tag but was removed in 1.3.
>>>>>>
>>>>>> The @since tag is added to *.java instead of package.html so that we
>>>>>> can have javac report javadoc via
>>>>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>>>>
>>>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>
>>>
>


From joe.darcy at oracle.com  Thu Jun 19 00:31:58 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 18 Jun 2014 17:31:58 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A207DB.7020402@oracle.com>
References: <53979C10.1080307@oracle.com>
	<53A16D8F.1060103@oracle.com>	<53A1BB72.2060609@oracle.com>
	<53A1CFFE.4070606@oracle.com>	<53A1D65A.9070701@oracle.com>
	<53A207DB.7020402@oracle.com>
Message-ID: <53A22F7E.9000800@oracle.com>

FWIW, if I were reviewing code in a new package, I would want to see 
@since tags in all top-level types in the new package and not just on 
the package-info.java/package.html file.

Cheers,

-Joe

On 06/18/2014 02:42 PM, Phil Race wrote:
> So for the specific case of the nimbus class I can see that the entire
> package was new in 1.7 so the individual classes added at that time
> do not need an @since tag.
>
> But my main question was whether you have inspected all
> classes in all swing packages and none were fouhd in need of an
> update .. I suppose its likely that after 1.2 people were more
> diligent in adding these tags.
>
> Assuming the answer is yes, then I'm OK. If no, then I'm OK
> too although at least then we'd know you still had to do those
> packages ..
>
> -phil.
>
> On 6/18/2014 11:11 AM, Henry Jen wrote:
>>
>>
>> On 06/18/2014 10:44 AM, Phil Race wrote:
>>> Hello,
>>>
>>> You say "under" javax.swing but you don't seem to be touching
>>> any sub-packages.
>>
>> No, sub-packages has @since in correponding package.html. I use * to 
>> mean entitiy in this package, and ** to signal subpackage as well.
>>
>> If it helps, I can remove .* from the subject.
>>
>>> I notice there is at least one @since 1.7 you
>>> added to the Painter interface - so they aren't all 1.2 - and yet
>>> you didn't add the @since 1.7 to the sole class that implements
>>> Painter - perhaps because its in a sub-package.
>>>
>>
>> It's used in javax.swing.plaf.nimbus, which has @since 1.7.
>>
>>> Also note that whilst @since 1.2 is strictly correct in terms of 
>>> Java SE
>>> but Swing was initially an unbundled library - somewhat analagous
>>> to Java FX 2.x, and ran on JDK 1.1.x
>>>
>>
>> Understood. We are focus to make sure @since has the first version 
>> since the inclusion in J2SE. Other version information, as Mark 
>> suggested, can be expressed after comma. In case Java FX is included 
>> in JDK9, we would expect it to have have @since 1.9, Java FX x.x.
>>
>> As swing component currenly doesn't have that extra version 
>> information, we will simply mark the J2SE debut.
>>
>> Cheers,
>> Henry
>>
>>> -phil.
>>>
>>> On 6/18/2014 9:16 AM, Henry Jen wrote:
>>>> Thanks, Alexander.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>    The fix looks good for me.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>
>>>>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review a trivial webrev that provides missing @since tag for
>>>>>> elements under javax.swing,
>>>>>>
>>>>>> Essentially it's simply add @since 1.2 for all
>>>>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>>>>> package.html has @since tag but was removed in 1.3.
>>>>>>
>>>>>> The @since tag is added to *.java instead of package.html so that we
>>>>>> can have javac report javadoc via
>>>>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>>>>
>>>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>
>>>
>



From henry.jen at oracle.com  Thu Jun 19 02:44:19 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Jun 2014 19:44:19 -0700
Subject:  RFR: 8046485: Add missing @since tag under
	javax.swing.*
In-Reply-To: <53A22F7E.9000800@oracle.com>
References: <53979C10.1080307@oracle.com>
	<53A16D8F.1060103@oracle.com>	<53A1BB72.2060609@oracle.com>
	<53A1CFFE.4070606@oracle.com>	<53A1D65A.9070701@oracle.com>
	<53A207DB.7020402@oracle.com> <53A22F7E.9000800@oracle.com>
Message-ID: <53A24E83.1060609@oracle.com>

+1, for any new code, we should definitely do that. It would be nice to 
add them for existing classes, I can slightly modify the tool and clean 
it up in a separate round, which I prefer we do.

Cheers,
Henry

On 06/18/2014 05:31 PM, Joe Darcy wrote:
> FWIW, if I were reviewing code in a new package, I would want to see
> @since tags in all top-level types in the new package and not just on
> the package-info.java/package.html file.
>
> Cheers,
>
> -Joe
>
> On 06/18/2014 02:42 PM, Phil Race wrote:
>> So for the specific case of the nimbus class I can see that the entire
>> package was new in 1.7 so the individual classes added at that time
>> do not need an @since tag.
>>
>> But my main question was whether you have inspected all
>> classes in all swing packages and none were fouhd in need of an
>> update .. I suppose its likely that after 1.2 people were more
>> diligent in adding these tags.
>>
>> Assuming the answer is yes, then I'm OK. If no, then I'm OK
>> too although at least then we'd know you still had to do those
>> packages ..
>>
>> -phil.
>>
>> On 6/18/2014 11:11 AM, Henry Jen wrote:
>>>
>>>
>>> On 06/18/2014 10:44 AM, Phil Race wrote:
>>>> Hello,
>>>>
>>>> You say "under" javax.swing but you don't seem to be touching
>>>> any sub-packages.
>>>
>>> No, sub-packages has @since in correponding package.html. I use * to
>>> mean entitiy in this package, and ** to signal subpackage as well.
>>>
>>> If it helps, I can remove .* from the subject.
>>>
>>>> I notice there is at least one @since 1.7 you
>>>> added to the Painter interface - so they aren't all 1.2 - and yet
>>>> you didn't add the @since 1.7 to the sole class that implements
>>>> Painter - perhaps because its in a sub-package.
>>>>
>>>
>>> It's used in javax.swing.plaf.nimbus, which has @since 1.7.
>>>
>>>> Also note that whilst @since 1.2 is strictly correct in terms of
>>>> Java SE
>>>> but Swing was initially an unbundled library - somewhat analagous
>>>> to Java FX 2.x, and ran on JDK 1.1.x
>>>>
>>>
>>> Understood. We are focus to make sure @since has the first version
>>> since the inclusion in J2SE. Other version information, as Mark
>>> suggested, can be expressed after comma. In case Java FX is included
>>> in JDK9, we would expect it to have have @since 1.9, Java FX x.x.
>>>
>>> As swing component currenly doesn't have that extra version
>>> information, we will simply mark the J2SE debut.
>>>
>>> Cheers,
>>> Henry
>>>
>>>> -phil.
>>>>
>>>> On 6/18/2014 9:16 AM, Henry Jen wrote:
>>>>> Thanks, Alexander.
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>> On 06/18/2014 03:44 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>    The fix looks good for me.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>
>>>>>> On 6/11/2014 4:00 AM, Henry Jen wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review a trivial webrev that provides missing @since tag for
>>>>>>> elements under javax.swing,
>>>>>>>
>>>>>>> Essentially it's simply add @since 1.2 for all
>>>>>>> classes/interfaces/exception that are missing @since tag, as JDK 1.2
>>>>>>> package.html has @since tag but was removed in 1.3.
>>>>>>>
>>>>>>> The @since tag is added to *.java instead of package.html so that we
>>>>>>> can have javac report javadoc via
>>>>>>> javax.lang.model.util.Elements.getDocComment(Element c).
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Henry
>>>>>>
>>>>
>>
>


From martinrb at google.com  Thu Jun 19 04:25:30 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 18 Jun 2014 21:25:30 -0700
Subject: ThreadLocalRandom clinit troubles
Message-ID: 

ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get some
more machine-specific entropy in initialSeed().  This will fail if the
networking code ever recursively uses a (not yet functional)
ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
be run,

at
java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
at java.net.InetAddress$3.run(InetAddress.java:923)
at java.net.InetAddress$3.run(InetAddress.java:918)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.InetAddress.createNSProvider(InetAddress.java:917)
at java.net.InetAddress.(InetAddress.java:962)

if the sun.net.spi.nameservice.provider system property is defined.

The current strategy of ThreadLocalRandom relying on other java code for
initialization seems risky.  Safer would be to have native code provide
some entropy at program startup for use by ThreadLocalRandom.  I don't have
a clean solution for this problem (other than to rip out initialSeed()).
 Strictly more reliable would be to mix in the entropy from the system at
the end of ThreadLocalRandom's clinit instead of the beginning, but the
basic problem remains.


From peter.levart at gmail.com  Thu Jun 19 07:49:43 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Jun 2014 09:49:43 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 
Message-ID: <53A29617.4080606@gmail.com>

Hi Martin,

What version of TLR are you looking at? As far as I remmember, the 
InetAddress-related code to obtain initial seed has been replaced by 
NetworkInterface.getHardwareAddress(). Is this still triggering the 
initialization of InetAddress or is this the case of using 
"java.util.secureRandomSeed" set to "true" ? Can you show the whole 
stack trace?

On 06/19/2014 06:25 AM, Martin Buchholz wrote:
 > ThreadLocalRandom's clinit method creates an intermediate broken state of
 > ThreadLocalRandom and then proceeds to run some networking code to 
get some
 > more machine-specific entropy in initialSeed().
 >   This will fail if the
 > networking code ever recursively uses a (not yet functional)
 > ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary 
code to
 > be run,
 >
 > at
 > 
java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
 > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
 > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
 > at java.net.InetAddress$3.run(InetAddress.java:923)
 > at java.net.InetAddress$3.run(InetAddress.java:918)
 > at java.security.AccessController.doPrivileged(Native Method)
 > at java.net.InetAddress.createNSProvider(InetAddress.java:917)
 > at java.net.InetAddress.(InetAddress.java:962)
 >
 > if the sun.net.spi.nameservice.provider system property is defined.
 >
 > The current strategy of ThreadLocalRandom relying on other java code for
 > initialization seems risky.  Safer would be to have native code provide
 > some entropy at program startup for use by ThreadLocalRandom. I don't 
have
 > a clean solution for this problem (other than to rip out initialSeed()).
 >   Strictly more reliable would be to mix in the entropy from the 
system at
 > the end of ThreadLocalRandom's clinit instead of the beginning, but the
 > basic problem remains.

Would it be acceptable for TLR to be functional even when invoked during 
it's clinit, but using a less randomized "seeder" (based only on current 
time) and after the "networking" or SecureRandom code is finished, 
complete the initialization of "seeder" state and clear the thread-local 
probe so that TLR's thread state is re-initialized afterwards. for example:

http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR.seeder/webrev.01/

Regards, Peter



From peter.levart at gmail.com  Thu Jun 19 08:02:44 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Jun 2014 10:02:44 +0200
Subject: [concurrency-interest] ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 
	
Message-ID: <53A29924.4020804@gmail.com>

On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote:
> I wonder why just don't use the /dev/random if available on *nix -
> implemented by sun.security.provider.NativePRNG or
> sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
> Both support SecureRandomSpi.engineGenerateSeed(int) that provides an
> arbitrary amount of entropy.
> Although the approach would cause some more classes to load, no arbitrary
> providers should be initialized.

I think this is waht you get when you set "java.util.secureRandomSeed" 
system property to "true". TLR uses 
java.security.SecureRandom.getSeed(8) in this case.

Regards, Peter

>
> Stanimir
>
>
>
> On Thu, Jun 19, 2014 at 7:25 AM, Martin Buchholz 
> wrote:
>
>> ThreadLocalRandom's clinit method creates an intermediate broken state of
>> ThreadLocalRandom and then proceeds to run some networking code to get some
>> more machine-specific entropy in initialSeed().  This will fail if the
>> networking code ever recursively uses a (not yet functional)
>> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
>> be run,
>>
>> at
>> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
>> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
>>   at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
>> at java.net.InetAddress$3.run(InetAddress.java:923)
>>   at java.net.InetAddress$3.run(InetAddress.java:918)
>> at java.security.AccessController.doPrivileged(Native Method)
>>   at java.net.InetAddress.createNSProvider(InetAddress.java:917)
>> at java.net.InetAddress.(InetAddress.java:962)
>>
>> if the sun.net.spi.nameservice.provider system property is defined.
>>
>> The current strategy of ThreadLocalRandom relying on other java code for
>> initialization seems risky.  Safer would be to have native code provide
>> some entropy at program startup for use by ThreadLocalRandom.  I don't have
>> a clean solution for this problem (other than to rip out initialSeed()).
>>   Strictly more reliable would be to mix in the entropy from the system at
>> the end of ThreadLocalRandom's clinit instead of the beginning, but the
>> basic problem remains.
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From Alan.Bateman at oracle.com  Thu Jun 19 08:22:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jun 2014 09:22:29 +0100
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 
Message-ID: <53A29DC5.1030605@oracle.com>

On 19/06/2014 05:25, Martin Buchholz wrote:
> ThreadLocalRandom's clinit method creates an intermediate broken state of
> ThreadLocalRandom and then proceeds to run some networking code to get some
> more machine-specific entropy in initialSeed().  This will fail if the
> networking code ever recursively uses a (not yet functional)
> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
> be run,
>
> at
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at java.net.InetAddress$3.run(InetAddress.java:923)
> at java.net.InetAddress$3.run(InetAddress.java:918)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.InetAddress.createNSProvider(InetAddress.java:917)
> at java.net.InetAddress.(InetAddress.java:962)
>
> if the sun.net.spi.nameservice.provider system property is defined.
>
> The current strategy of ThreadLocalRandom relying on other java code for
> initialization seems risky.
Using a name service provider other than the default is going to 
interact badly here. So is this configured to use the JNDI-DNS provider 
("dns,sun") or something else? This provider mechanism has been a source 
of many problems, recursive initialization and stack overflow mostly 
because any custom provider is likely going to use the network and 
resolve host names. It can interact very badly with security when the 
provider doesn't have AllPermision because attempts to establish 
connections involve security checks that often need to do lookups too.

So I'm curious if there is more to this stack trace to put more context 
on the issue. It may be another example to back a suggestion to just 
drop the JDK-internal name service provider mechanism. But in general, I 
think you are right, it's not good for TLR initialization to trigger 
arbitrary code to execute.

-Alan.


From peter.levart at gmail.com  Thu Jun 19 08:37:41 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Jun 2014 10:37:41 +0200
Subject: ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed
Message-ID: <53A2A155.3040509@gmail.com>

Hi,

I noticed an inconsistency in calling TLR.localInit() method. Everywhere 
it's called conditionaly if thread-local "probe" is zero except in 
TLR.nextSecondarySeed() where it's called if "secondary" seed is zero. 
This re-initializes the "probe" and "seed" even though they might have 
already been initialized. It's not a big deal, because this happens at 
most once per thread, but it would be more consistent to call 
localInit() conditionaly, I think:


diff -r 5b45a5efe417 
src/share/classes/java/util/concurrent/ThreadLocalRandom.java
--- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue 
May 20 10:11:23 2014 +0400
+++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu 
Jun 19 10:34:18 2014 +0200
@@ -1034,7 +1034,8 @@
              r ^= r << 5;
}
          else {
- localInit();
+            if (UNSAFE.getInt(t, PROBE) == 0)
+ localInit();
              if ((r = (int)UNSAFE.getLong(t, SEED)) == 0)
                  r = 1; // avoid zero
          }



Regards, Peter



From peter.levart at gmail.com  Thu Jun 19 08:48:24 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Jun 2014 10:48:24 +0200
Subject: ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed
In-Reply-To: <53A2A155.3040509@gmail.com>
References: <53A2A155.3040509@gmail.com>
Message-ID: <53A2A3D8.8000602@gmail.com>

Or, even better, why not just using the next value from the "seeder" 
sequence for the initial value of "secondary" seed and avoid interaction 
with TLR's main seed/probe:


diff -r 5b45a5efe417 
src/share/classes/java/util/concurrent/ThreadLocalRandom.java
--- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue 
May 20 10:11:23 2014 +0400
+++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu 
Jun 19 10:45:25 2014 +0200
@@ -1034,8 +1034,7 @@
              r ^= r << 5;
          }
          else {
-            localInit();
-            if ((r = (int)UNSAFE.getLong(t, SEED)) == 0)
+            if ((r = (int)mix64(seeder.getAndAdd(SEEDER_INCREMENT))) == 0)
                  r = 1; // avoid zero
          }
          UNSAFE.putInt(t, SECONDARY, r);


Regards, Peter

On 06/19/2014 10:37 AM, Peter Levart wrote:
> Hi,
>
> I noticed an inconsistency in calling TLR.localInit() method. 
> Everywhere it's called conditionaly if thread-local "probe" is zero 
> except in TLR.nextSecondarySeed() where it's called if "secondary" 
> seed is zero. This re-initializes the "probe" and "seed" even though 
> they might have already been initialized. It's not a big deal, because 
> this happens at most once per thread, but it would be more consistent 
> to call localInit() conditionaly, I think:
>
>
> diff -r 5b45a5efe417 
> src/share/classes/java/util/concurrent/ThreadLocalRandom.java
> --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java 
> Tue May 20 10:11:23 2014 +0400
> +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java 
> Thu Jun 19 10:34:18 2014 +0200
> @@ -1034,7 +1034,8 @@
>              r ^= r << 5;
> }
>          else {
> - localInit();
> +            if (UNSAFE.getInt(t, PROBE) == 0)
> + localInit();
>              if ((r = (int)UNSAFE.getLong(t, SEED)) == 0)
>                  r = 1; // avoid zero
>          }
>
>
>
> Regards, Peter
>



From dl at cs.oswego.edu  Thu Jun 19 12:02:06 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 19 Jun 2014 08:02:06 -0400
Subject: [concurrency-interest] ThreadLocalRandom.nextSecondarySeed()
	re-initializes TLR's seed
In-Reply-To: <53A2A3D8.8000602@gmail.com>
References: <53A2A155.3040509@gmail.com> <53A2A3D8.8000602@gmail.com>
Message-ID: <53A2D13E.4020006@cs.oswego.edu>

On 06/19/2014 04:48 AM, Peter Levart wrote:
> Or, even better, why not just using the next value from the "seeder" sequence
> for the initial value of "secondary" seed and avoid interaction with TLR's main
> seed/probe:

Thanks! Or better, just use mix32:

>
> +            if ((r = (int)mix64(seeder.getAndAdd(SEEDER_INCREMENT))) == 0)
=>
      if ((r = mix32(seeder.getAndAdd(SEEDER_INCREMENT))) == 0)

I committed this to jsr166 cvs. As you noted, this only addresses
an uncommon performance glitch. I don't have any further ideas
since we discussed last year the tradeoffs between computing
decent quality initial seeds versus class-loading.
I still think we have the best practical compromise in place.

-Doug

>           }
>           UNSAFE.putInt(t, SECONDARY, r);
>
>
> Regards, Peter
>
> On 06/19/2014 10:37 AM, Peter Levart wrote:
>> Hi,
>>
>> I noticed an inconsistency in calling TLR.localInit() method. Everywhere it's
>> called conditionaly if thread-local "probe" is zero except in
>> TLR.nextSecondarySeed() where it's called if "secondary" seed is zero. This
>> re-initializes the "probe" and "seed" even though they might have already been
>> initialized. It's not a big deal, because this happens at most once per
>> thread, but it would be more consistent to call localInit() conditionaly, I
>> think:
>>
>>
>> diff -r 5b45a5efe417
>> src/share/classes/java/util/concurrent/ThreadLocalRandom.java
>> --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue May 20
>> 10:11:23 2014 +0400
>> +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu Jun 19
>> 10:34:18 2014 +0200
>> @@ -1034,7 +1034,8 @@
>>              r ^= r << 5;
>> }
>>          else {
>> - localInit();
>> +            if (UNSAFE.getInt(t, PROBE) == 0)
>> + localInit();
>>              if ((r = (int)UNSAFE.getLong(t, SEED)) == 0)
>>                  r = 1; // avoid zero
>>          }
>>
>>
>>
>> Regards, Peter
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



From forax at univ-mlv.fr  Thu Jun 19 12:53:09 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 19 Jun 2014 14:53:09 +0200
Subject: lambda reference to inner class in base class causes
	LambdaConversionException
Message-ID: <53A2DD35.8020608@univ-mlv.fr>

I've just take a look to bug 8047341 [1] and I think it's a javac bug 
and not a bug in the lambda meta-factory,
moreover, Eclipse generates a code which doesn't throw an exception at 
runtime.

In list.stream().forEach(TestString::new), TestString::new reference the 
constructor of TestString
which is an inner class (non static) of FooBase, so the constructor 
takes a hidden FooBase parameter
so the method reference should refer to TestString(FooBase, String).

The code generated by javac is:
   14: aload_0
   15: invokedynamic #5,  0              // InvokeDynamic 
#0:accept:(LFoo;)Ljava/util/function/Consumer;
   20: invokeinterface #6,  2            // InterfaceMethod 
java/util/stream/Stream.forEach:(Ljava/util/function/Consumer;)V

while Eclipse ecj generates:
   14: aload_0
   15: invokedynamic #27,  0             // InvokeDynamic 
#0:accept:(LFooBase;)Ljava/util/function/Consumer;
   20: invokeinterface #28,  2           // InterfaceMethod 
java/util/stream/Stream.forEach:(Ljava/util/function/Consumer;)V

as you can see, javac generate an invokedynamic call with a Foo instead 
of a FooBase which I think is the correct behavior.

So for me, it's a bug in javac, not in the meta-factory.

cheers,
R?mi

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




From maurizio.cimadamore at oracle.com  Thu Jun 19 13:00:41 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 19 Jun 2014 14:00:41 +0100
Subject: lambda reference to inner class in base class causes
	LambdaConversionException
In-Reply-To: <53A2DD35.8020608@univ-mlv.fr>
References: <53A2DD35.8020608@univ-mlv.fr>
Message-ID: <53A2DEF9.8040804@oracle.com>


On 19/06/14 13:53, Remi Forax wrote:
> as you can see, javac generate an invokedynamic call with a Foo 
> instead of a FooBase which I think is the correct behavior. 
You mean the other way around?

Maurizio


From forax at univ-mlv.fr  Thu Jun 19 13:05:36 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 19 Jun 2014 15:05:36 +0200
Subject: lambda reference to inner class in base class causes
	LambdaConversionException
In-Reply-To: <53A2DEF9.8040804@oracle.com>
References: <53A2DD35.8020608@univ-mlv.fr> <53A2DEF9.8040804@oracle.com>
Message-ID: <53A2E020.8070802@univ-mlv.fr>


On 06/19/2014 03:00 PM, Maurizio Cimadamore wrote:
>
> On 19/06/14 13:53, Remi Forax wrote:
>> as you can see, javac generate an invokedynamic call with a Foo 
>> instead of a FooBase which I think is the correct behavior. 
> You mean the other way around?

oops,
s/the correct/not the correct

>
> Maurizio

R?mi



From vincent.x.ryan at oracle.com  Thu Jun 19 16:59:20 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 19 Jun 2014 17:59:20 +0100
Subject: [9] request for review 8047353: Improve error message when a JAR with
	invalid signatures is loaded
Message-ID: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com>

Please review the following simple changeset to identify the offending JAR file following a signature verification error.
Previously, only the offending entry in the JAR was identified.

This helps during troubleshooting when several JAR files being processed.

The request was originally submitted by Aaron Digulla.


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




From claes.redestad at oracle.com  Thu Jun 19 17:39:15 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 19 Jun 2014 19:39:15 +0200
Subject: RFR [9] 8041972: Add improved parse/format methods for
	Long/Integer
In-Reply-To: <53A06224.1040600@oracle.com>
References: <539CCE6D.6040207@oracle.com>	<539D8821.3070808@univ-mlv.fr>	<539D91A0.9050901@oracle.com>	<539E1CB4.2050502@oracle.com>	<539F4A6A.5020002@oracle.com>	<539F4FCE.9080903@oracle.com>	<53A04EE7.6090309@oracle.com>
	<53A06224.1040600@oracle.com>
Message-ID: <53A32043.7070008@oracle.com>

Hi,

an updated webrev with reworked, public methods is available here:
http://cr.openjdk.java.net/~redestad/8041972/webrev.8/

Reviews are yet again appreciated!

/Claes

On 06/17/2014 05:43 PM, Claes Redestad wrote:
> Ok, I'm working on improving code and comments based on feedback. I'll 
> split the SharedSecrets part out, make the methods public and post a 
> new webrev soon.
>
> /Claes
>
> On 06/17/2014 04:21 PM, roger riggs wrote:
>> Yes, that looks more consistent with the current versions.
>>
>> Though you want to see these for 8u, the preferred pattern is to make 
>> the changes
>> in 9 and then backport the result (in this case adding the shared 
>> secrets aspect).
>>
>> Roger
>>
>>
>> On 6/16/2014 4:13 PM, Claes Redestad wrote:
>>> ...
>>>> The terminology used in java.lang.String for offsets and indexes 
>>>> into strings would
>>>> be provide a consistent base for talking about substrings.
>>> If we're taking cues from String.substring, I guess int beginIndex[, 
>>> int fromIndex] would be more appropriate. How about:
>>>
>>>     /**
>>>      * Parses the character sequence argument in the specified 
>>> {@code radix},
>>>      * beginning at the specified {@code beginIndex} and extending 
>>> to the
>>>      * character at index {@code endIndex - 1}.
>>>      *
>>>      * @see java.lang.Integer#parseInt(String, int)
>>>      * @param      s   the {@code CharSequence} containing the integer
>>>      *                  representation to be parsed
>>>      * @param      radix   the radix to be used while parsing {@code 
>>> s}.
>>>      * @param      beginIndex   the beginning index, inclusive.
>>>      * @param      endIndex     the ending index, exclusive.
>>>      * @return     the integer represented by the subsequence in the
>>>      *             specified radix.
>>>      */
>>>     static int parseInt(CharSequence s, int radix, int beginIndex, 
>>> int endIndex)
>>>
>>> ?
>>>
>>> Thanks!
>>>
>>> /Claes
>>
>



From martinrb at google.com  Thu Jun 19 18:04:19 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Jun 2014 11:04:19 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A29DC5.1030605@oracle.com>
References: 
	<53A29DC5.1030605@oracle.com>
Message-ID: 

On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman 
wrote:

> On 19/06/2014 05:25, Martin Buchholz wrote:
>
>> ThreadLocalRandom's clinit method creates an intermediate broken state of
>> ThreadLocalRandom and then proceeds to run some networking code to get
>> some
>> more machine-specific entropy in initialSeed().  This will fail if the
>> networking code ever recursively uses a (not yet functional)
>> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
>> be run,
>>
>> at
>> java.util.ServiceLoader$LazyIterator.hasNextService(
>> ServiceLoader.java:354)
>> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
>> at java.net.InetAddress$3.run(InetAddress.java:923)
>> at java.net.InetAddress$3.run(InetAddress.java:918)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.InetAddress.createNSProvider(InetAddress.java:917)
>> at java.net.InetAddress.(InetAddress.java:962)
>>
>> if the sun.net.spi.nameservice.provider system property is defined.
>>
>> The current strategy of ThreadLocalRandom relying on other java code for
>> initialization seems risky.
>>
> Using a name service provider other than the default is going to interact
> badly here. So is this configured to use the JNDI-DNS provider ("dns,sun")
> or something else? This provider mechanism has been a source of many
> problems, recursive initialization and stack overflow mostly because any
> custom provider is likely going to use the network and resolve host names.
> It can interact very badly with security when the provider doesn't have
> AllPermision because attempts to establish connections involve security
> checks that often need to do lookups too.
>
> So I'm curious if there is more to this stack trace to put more context on
> the issue.


The way we are actually seeing this is:
- there are jdk8 jtreg tests that set the sun.net.spi.nameservice.provider
property.  Grepping:

./java/net/Inet4Address/textToNumericFormat.java
./java/net/URLPermission/nstest/lookup.sh
./sun/net/InetAddress/nameservice/dns/cname.sh
./sun/net/InetAddress/nameservice/deadlock/Hang.java
./sun/net/InetAddress/nameservice/chaining/Providers.java
./sun/net/InetAddress/nameservice/simple/DefaultCaching.java
./sun/net/InetAddress/nameservice/simple/CacheTest.java
./sun/security/krb5/auto/KDC.java
./sun/security/krb5/canonicalize/Test.java

- we have local modifications to classloading that happen to use TLR
via ConcurrentSkipListMap - a "reasonable" thing to do.  Probably the
simplest way to provoke a failure is to try to use a TLR from e.g.
URLClassPath.

In general, any core library boot class should try hard to avoid
loading/invoking code from the user's classpath.


> It may be another example to back a suggestion to just drop the
> JDK-internal name service provider mechanism. But in general, I think you
> are right, it's not good for TLR initialization to trigger arbitrary code
> to execute.
>
> -Alan.
>


From roger.riggs at oracle.com  Thu Jun 19 20:42:23 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 19 Jun 2014 16:42:23 -0400
Subject: RFR: JDK-8042369 Remove duplicated java.time classes in
	build.tools.tzdb
In-Reply-To: <539F22B5.90409@oracle.com>
References: <53672CB4.3050708@oracle.com>
	<537A4980.5050603@oracle.com>	<537BC093.40102@oracle.com>
	<539F22B5.90409@oracle.com>
Message-ID: <53A34B2F.1090703@oracle.com>

Hi Sherman,

Looks ok.

Thanks, Roger

On 6/16/2014 1:00 PM, Xueming Shen wrote:
> OK, let's go the non-controversial approach. The webrev has been 
> updated to simply remove
> those redundant/duplicated class files from the builder and use the 
> updated version of the tzdb
> builder.
>
> http://cr.openjdk.java.net/~sherman/8042369/webrev
>
> Thanks!
> -Sherman
>
> On 5/20/2014 1:52 PM, roger riggs wrote:
>> Hi Sherman,
>>
>> Even though it has well defined content, checking in the tar.gz seems 
>> not quite right.
>> Can the tests reconstruct the tar file from the contents or directly use
>> the IANA data on demand from the IANA site?
>>
>> From a maintenance point of view,  functions added to the JDK should be
>> well used and maintained and be well supported.
>>
>> TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still 
>> mentions "-srcdir".
>>
>>  :+153; the commented out message should be removed
>>
>>
>> Roger
>>
>>
>> On 5/19/2014 2:12 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> I've not got any feedback so far, so I assume it's good:-)
>>>
>>> Anyway, I'm going a little further to throw in a TarInputStream so 
>>> now we just build the
>>> tzdb data directly on  the tzdata201xy.tar.gz from iana site. I'm 
>>> not sure if it is OK to
>>> check in the original .tar.gz file into the jdk repository though.
>>>
>>> There are also more improvements in this version, it is much faster 
>>> now. It might
>>> not matter as it is only used during build time, though:-)
>>>
>>> http://cr.openjdk.java.net/~sherman/8042369/webrev
>>>
>>> -Sherman
>>>
>>> Btw, I'm still trying to sell the idea of checking in a second tzdb 
>>> provider implementation
>>> into the jdk, which directly loads in the tzdb data by using the 
>>> iana original source data,
>>> with the assumption that this might be useful at least in certain 
>>> circumstance (such as
>>> one gov pushes a tz change, and some of your big jdk customers need 
>>> their apps run with
>>> the new data in next 24 hrs...) in the future.
>>>
>>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev
>>>
>>>
>>> On 05/04/2014 11:16 PM, Xueming Shen wrote:
>>>> Hi
>>>>
>>>> Please help review the change for #8042369
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042369
>>>> Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev
>>>>
>>>> In jdk8 we had to duplicate dozen java.time classes in build.tools 
>>>> to build the timezone data
>>>> for the new JSR310 timezone data compiler, which uses the new jdk8 
>>>> java.time classes (these
>>>> classes don't exit in the < 8 boot jdk). JDK9 has switched to use 
>>>> the jdk8 as the boot jdk,  so
>>>> most of these duplicated classes are no longer needed, with 
>>>> ZoneRules as the only exception.
>>>> The ZoneRules is still needed to help the tzdb compiler to output 
>>>> the tzdb data in the
>>>> serialization forms of those transitions and rules. The proposed 
>>>> change here is to remove
>>>> those unneeded duplicated classes.
>>>>
>>>> I also took the opportunity to re-organize/re-wrote the "builder" 
>>>> classes to have a faster, simpler
>>>> and and straightforward implementation, with the goal of migrating 
>>>> it into a second default
>>>> ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses 
>>>> the tzdb source data from the
>>>> IANA directly. One of the benefits of such a provider is that the 
>>>> end user may just drop the latest
>>>> timezone data file into the jdk/jre and go, without waiting for the 
>>>> latest timezone binary bits from
>>>> Oracle.
>>>>
>>>> Here is the webrev for the idea
>>>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/
>>>>
>>>> The only disadvantage appears to be the possible "slowdown" of 
>>>> startup time because of
>>>> the reading and compiling of the 200k tzdb source data...(we need 
>>>> another new "bridge" for
>>>>  j.u.TimeZone, if we go with this direction)
>>>>
>>>> Thanks!
>>>> -Sherman
>>>>
>>>>
>>>
>>
>



From vincent.x.ryan at oracle.com  Thu Jun 19 21:21:59 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 19 Jun 2014 22:21:59 +0100
Subject: [9] request for review 8047353: Improve error message when a JAR
	with invalid signatures is loaded
In-Reply-To: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com>
References: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com>
Message-ID: 


I shortened the output to display only the JAR filename to avoid leaking filesystem information.
I?ve updated the webrev in-place.

Thanks.


On 19 Jun 2014, at 17:59, Vincent Ryan  wrote:

> Please review the following simple changeset to identify the offending JAR file following a signature verification error.
> Previously, only the offending entry in the JAR was identified.
> 
> This helps during troubleshooting when several JAR files being processed.
> 
> The request was originally submitted by Aaron Digulla.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8047353
> Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/
> 
> 



From joe.darcy at oracle.com  Thu Jun 19 21:49:32 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 19 Jun 2014 14:49:32 -0700
Subject: [9] request for review 8047353: Improve error message when a
	JAR with invalid signatures is loaded
In-Reply-To: 
References: <226F571D-7710-4E93-AF33-D472D60253F7@oracle.com>
	
Message-ID: <53A35AEC.9080708@oracle.com>

Hello,

I'd prefer to see the CheckJarSigError.sh as a Java program.

Cheers,

-Joe

On 06/19/2014 02:21 PM, Vincent Ryan wrote:
> I shortened the output to display only the JAR filename to avoid leaking filesystem information.
> I?ve updated the webrev in-place.
>
> Thanks.
>
>
> On 19 Jun 2014, at 17:59, Vincent Ryan  wrote:
>
>> Please review the following simple changeset to identify the offending JAR file following a signature verification error.
>> Previously, only the offending entry in the JAR was identified.
>>
>> This helps during troubleshooting when several JAR files being processed.
>>
>> The request was originally submitted by Aaron Digulla.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047353
>> Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/
>>
>>



From neil.toda at oracle.com  Fri Jun 20 00:29:28 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 19 Jun 2014 17:29:28 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
Message-ID: <53A38068.6010200@oracle.com>


Launcher support for modified Native Memory Tracking mechanism in JVM in 
JDK9.

Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
CCC         : http://ccc.us.oracle.com/8042469

Thanks.

-neil



From vitalyd at gmail.com  Fri Jun 20 00:39:46 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Jun 2014 20:39:46 -0400
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A38068.6010200@oracle.com>
References: <53A38068.6010200@oracle.com>
Message-ID: 

Hi Neil,

1054                     envName = malloc(pbuflen);

envName is never freed looks like.  Probably not a big deal since this runs
only if launcher is traced, but thought I'd mention it.

Sent from my phone
On Jun 19, 2014 8:30 PM, "Neil Toda"  wrote:

>
> Launcher support for modified Native Memory Tracking mechanism in JVM in
> JDK9.
>
> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
> CCC         : http://ccc.us.oracle.com/8042469
>
> Thanks.
>
> -neil
>
>


From neil.toda at oracle.com  Fri Jun 20 00:42:52 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 19 Jun 2014 17:42:52 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: 
References: <53A38068.6010200@oracle.com>
	
Message-ID: <53A3838C.4030906@oracle.com>


Thanks Vitaly.  Best to cleanup.  I'll make that change.

-neil

On 6/19/2014 5:39 PM, Vitaly Davidovich wrote:
>
> Hi Neil,
>
> 1054                     envName = malloc(pbuflen);
>
> envName is never freed looks like.  Probably not a big deal since this 
> runs only if launcher is traced, but thought I'd mention it.
>
> Sent from my phone
>
> On Jun 19, 2014 8:30 PM, "Neil Toda"  > wrote:
>
>
>     Launcher support for modified Native Memory Tracking mechanism in
>     JVM in JDK9.
>
>     Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>     
>     bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>     CCC         : http://ccc.us.oracle.com/8042469
>
>     Thanks.
>
>     -neil
>



From peter.levart at gmail.com  Fri Jun 20 08:42:31 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Jun 2014 10:42:31 +0200
Subject: [concurrency-interest] ThreadLocalRandom.nextSecondarySeed()
	re-initializes TLR's seed
In-Reply-To: <53A2D13E.4020006@cs.oswego.edu>
References: <53A2A155.3040509@gmail.com> <53A2A3D8.8000602@gmail.com>
	<53A2D13E.4020006@cs.oswego.edu>
Message-ID: <53A3F3F7.9010506@gmail.com>

Hi Doug,

On 06/19/2014 02:02 PM, Doug Lea wrote:
> On 06/19/2014 04:48 AM, Peter Levart wrote:
>> Or, even better, why not just using the next value from the "seeder" 
>> sequence
>> for the initial value of "secondary" seed and avoid interaction with 
>> TLR's main
>> seed/probe:
>
> Thanks! Or better, just use mix32:
>
>>
>> +            if ((r = (int)mix64(seeder.getAndAdd(SEEDER_INCREMENT))) 
>> == 0)
> =>
>      if ((r = mix32(seeder.getAndAdd(SEEDER_INCREMENT))) == 0)

That's right.

>
> I committed this to jsr166 cvs. As you noted, this only addresses
> an uncommon performance glitch. 

Not so performance as the "expected" behaviour. I'm assuming the aim of 
TLR.nextSecondarySeed() as a java.util.concurrent private thread-local 
source of random numbers is:
- enough quality for it's purpose
- fast
- does not "disturb" the sequence of the primary public TLR sequence.

I was concerned about the last point only.

> I don't have any further ideas
> since we discussed last year the tradeoffs between computing
> decent quality initial seeds versus class-loading.
> I still think we have the best practical compromise in place.

This pertains to the other thread (ThreadLocalRandom clinit troubles) 
started by Martin Buchholz, right? He's making a valid point. The 
"seeder" static field is still uninitialized during either 
NetworkInterface class initialization (as a result of 
NetworkInterface.getNetworkInterfaces() call) or during 
SecureRandom.getSeed() call. Either of which can execute user code in 
some configurations which might in turn use ThreadLocalRandom. If this 
happens, TLR.current() throws a NPE. I proposed a re-arrangement of 
class initialization that allows TLR to be fully functional even during 
it's initialization, albeit with a less randomized seed, and does not 
change the behaviour otherwise (since it triggers re-initialization at 
the end). See the proposed patch in the other thread.

Regards, Peter

>
> -Doug
>
>>           }
>>           UNSAFE.putInt(t, SECONDARY, r);
>>
>>
>> Regards, Peter
>>
>> On 06/19/2014 10:37 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> I noticed an inconsistency in calling TLR.localInit() method. 
>>> Everywhere it's
>>> called conditionaly if thread-local "probe" is zero except in
>>> TLR.nextSecondarySeed() where it's called if "secondary" seed is 
>>> zero. This
>>> re-initializes the "probe" and "seed" even though they might have 
>>> already been
>>> initialized. It's not a big deal, because this happens at most once per
>>> thread, but it would be more consistent to call localInit() 
>>> conditionaly, I
>>> think:
>>>
>>>
>>> diff -r 5b45a5efe417
>>> src/share/classes/java/util/concurrent/ThreadLocalRandom.java
>>> --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>>> Tue May 20
>>> 10:11:23 2014 +0400
>>> +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>>> Thu Jun 19
>>> 10:34:18 2014 +0200
>>> @@ -1034,7 +1034,8 @@
>>>              r ^= r << 5;
>>> }
>>>          else {
>>> - localInit();
>>> +            if (UNSAFE.getInt(t, PROBE) == 0)
>>> + localInit();
>>>              if ((r = (int)UNSAFE.getLong(t, SEED)) == 0)
>>>                  r = 1; // avoid zero
>>>          }
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>



From peter.levart at gmail.com  Fri Jun 20 09:10:10 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Jun 2014 11:10:10 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 	<53A29DC5.1030605@oracle.com>
	
Message-ID: <53A3FA72.3060706@gmail.com>

On 06/19/2014 08:04 PM, Martin Buchholz wrote:
> On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman 
> wrote:
>
>> On 19/06/2014 05:25, Martin Buchholz wrote:
>>
>>> ThreadLocalRandom's clinit method creates an intermediate broken state of
>>> ThreadLocalRandom and then proceeds to run some networking code to get
>>> some
>>> more machine-specific entropy in initialSeed().  This will fail if the
>>> networking code ever recursively uses a (not yet functional)
>>> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
>>> be run,
>>>
>>> at
>>> java.util.ServiceLoader$LazyIterator.hasNextService(
>>> ServiceLoader.java:354)
>>> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
>>> at java.net.InetAddress$3.run(InetAddress.java:923)
>>> at java.net.InetAddress$3.run(InetAddress.java:918)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at java.net.InetAddress.createNSProvider(InetAddress.java:917)
>>> at java.net.InetAddress.(InetAddress.java:962)
>>>
>>> if the sun.net.spi.nameservice.provider system property is defined.
>>>
>>> The current strategy of ThreadLocalRandom relying on other java code for
>>> initialization seems risky.
>>>
>> Using a name service provider other than the default is going to interact
>> badly here. So is this configured to use the JNDI-DNS provider ("dns,sun")
>> or something else? This provider mechanism has been a source of many
>> problems, recursive initialization and stack overflow mostly because any
>> custom provider is likely going to use the network and resolve host names.
>> It can interact very badly with security when the provider doesn't have
>> AllPermision because attempts to establish connections involve security
>> checks that often need to do lookups too.
>>
>> So I'm curious if there is more to this stack trace to put more context on
>> the issue.
>
> The way we are actually seeing this is:
> - there are jdk8 jtreg tests that set the sun.net.spi.nameservice.provider
> property.  Grepping:
>
> ./java/net/Inet4Address/textToNumericFormat.java
> ./java/net/URLPermission/nstest/lookup.sh
> ./sun/net/InetAddress/nameservice/dns/cname.sh
> ./sun/net/InetAddress/nameservice/deadlock/Hang.java
> ./sun/net/InetAddress/nameservice/chaining/Providers.java
> ./sun/net/InetAddress/nameservice/simple/DefaultCaching.java
> ./sun/net/InetAddress/nameservice/simple/CacheTest.java
> ./sun/security/krb5/auto/KDC.java
> ./sun/security/krb5/canonicalize/Test.java
>
> - we have local modifications to classloading that happen to use TLR
> via ConcurrentSkipListMap - a "reasonable" thing to do.  Probably the
> simplest way to provoke a failure is to try to use a TLR from e.g.
> URLClassPath.
>
> In general, any core library boot class should try hard to avoid
> loading/invoking code from the user's classpath.

Hi Martin,

Does my proposed patch solve these issues or does the 
"sun.net.spi.nameservice.provider" triggered changed initialization 
order provoke other failures. I can imagine there might be other issues. 
Perhaps a more lazy initialization of NetworkInterface class that does 
not trigger initialization of NS providers could help. We just need to 
invoke two methods on NetworkInterface:

- static NetworkInterface.getNetworkInterfaces()
- instance NetworkInterface.getHardwareAddress()

both of which could provide the result without the need of NS providers, 
I think.

This would solve the most general case of using TLR. The case that 
doesn't involve SecureRandom's help which I think is rarely needed and 
not default.


Regards, Peter

>
>
>> It may be another example to back a suggestion to just drop the
>> JDK-internal name service provider mechanism. But in general, I think you
>> are right, it's not good for TLR initialization to trigger arbitrary code
>> to execute.
>>
>> -Alan.
>>



From Alan.Bateman at oracle.com  Fri Jun 20 09:26:21 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jun 2014 10:26:21 +0100
Subject: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo
In-Reply-To: <53A3F40B.1040108@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
	<53A3301B.7070405@oracle.com> <53A3F40B.1040108@oracle.com>
Message-ID: <53A3FE3D.7050008@oracle.com>

On 20/06/2014 09:42, Patrick Zhang wrote:
> Hi Team,
>
> 8035490 is one task used to track xml code colocation from sqe repo 
> into jaxp repo.
> As one initial change set, it includes below materials:
> 1. TEST.ROOT to declare test code location.
> 2. ProblemList.txt to exclude 6 tests which have been discussed on past.
> 3. One Makefile to support future jprt/aurora execution.
> 4. test code located in bugxxx dir. All are based on testNG.
>
>
> webrev:
> http://cr.openjdk.java.net/~pzhang/xml_colocation/8035490/webrev/
>
> :
>
(Moving this thread this to core-libs-dev).

At a high-level then it's good to have the tests for JAXP in the same 
repository as the code. I've only skimmed over these webrev (not a 
review) and they look like they are mostly regression tests for specific 
bugs - is that right?

One thing that concerns me a bit is that none of the .java files that I 
looked at have any comments to say what the test does. Is there anything 
that could be brought over from the original issue in JIRA to explain 
what each of these tests is about?

Is Hello.wsdl.data a binary file? Have any alternatives been looked at?

As you mention ProblemList.txt then I see that it has headings that 
don't make sense in the jaxp repository, maybe they should be removed.

The webrev only has the changes for jaxp repository, will there be 
follow-on changes to make it runnable at the top level, JPRT 
configuration, etc.

-Alan


From daniel.fuchs at oracle.com  Fri Jun 20 10:02:40 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Jun 2014 12:02:40 +0200
Subject: RFR JDK-5077522 : Duration.compare incorrect for some values
In-Reply-To: <53A094DA.1000905@oracle.com>
References: <53A094DA.1000905@oracle.com>
Message-ID: <53A406C0.2060709@oracle.com>

Hi Joe,

Thanks for the detailed explanation.
It really helps reviewing the fix!

This looks reasonable to me. One minor nit is that you
could turn:

769         BigInteger maxintAsBigInteger = BigInteger.valueOf((long) 
Integer.MAX_VALUE);

into a static final constant in the class.

best regards,

-- daniel

On 6/17/14 9:19 PM, huizhe wang wrote:
> Hi,
>
> This is a long time compatibility issue: Duration.compare returns equal
> for INDETERMINATE relations defined in XML Schema standard
> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
> following table:
>
>      Relation
> P*1Y*     > P*364D*     <> P*365D*         <> P*366D*     < P*367D*
> P*1M*     > P*27D*     <> P*28D*     <> P*29D*     <> P*30D*     <>
> P*31D*     < P*32D*
> P*5M*     > P*149D*     <> P*150D*     <> P*151D*     <> P*152D*     <>
> P*153D*     < P*154D*
>
>
>
> The order-relation of two Duratoin values x and y is x < y iff s+x < s+y
> for each qualified datetime s listed below:
>
>   * 1696-09-01T00:00:00Z
>   * 1697-02-01T00:00:00Z
>   * 1903-03-01T00:00:00Z
>   * 1903-07-01T00:00:00Z
>
>
> The original implementation used Unix epoch, that is, 00:00:00 UTC on 1
> January 1970, as s in the above calculation which violated the above
> specification. A patch during JDK 6 development added correct
> implementation of the spec, but it was unfortunately added after the
> original calculation using Epoch time.
>
> *The fix to the issue therefore is simply removing the calculation using
> Epoch time.* I also consolidated the tedious max field value checks into
> a method called checkMaxValue.
>
> *Patch:*
> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>
> Test:
> testCompareWithInderterminateRelation: this is a copy of the JCK test
> that tests INDETERMINATE relations.
> testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1
> second to the original test cases. For example, to the original test:
> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>
> Below is the test result:
> Comparing P1Y and P365D: INDETERMINATE
> Comparing P1Y and P366D: INDETERMINATE
> Comparing P1M and P28D: INDETERMINATE
> Comparing P1M and P29D: INDETERMINATE
> Comparing P1M and P30D: INDETERMINATE
> Comparing P1M and P31D: INDETERMINATE
> Comparing P5M and P150D: INDETERMINATE
> Comparing P5M and P151D: INDETERMINATE
> Comparing P5M and P152D: INDETERMINATE
> Comparing P5M and P153D: INDETERMINATE
> Comparing PT2419200S and P1M: INDETERMINATE
> Comparing PT2678400S and P1M: INDETERMINATE
> Comparing PT31536000S and P1Y: INDETERMINATE
> Comparing PT31622400S and P1Y: INDETERMINATE
> Comparing PT525600M and P1Y: INDETERMINATE
> Comparing PT527040M and P1Y: INDETERMINATE
> Comparing PT8760H and P1Y: INDETERMINATE
> Comparing PT8784H and P1Y: INDETERMINATE
> Comparing P365D and P1Y: INDETERMINATE
> Comparing P1Y and P364D: expected: GREATER actual: GREATER
> Comparing P1Y and P367D: expected: LESSER actual: LESSER
> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
> Comparing P1M and P27D: expected: GREATER actual: GREATER
> Comparing P1M and P32D: expected: LESSER actual: LESSER
> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
> Comparing P5M and P149D: expected: GREATER actual: GREATER
> Comparing P5M and P154D: expected: LESSER actual: LESSER
> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>
> Number of tests passed: 36
> Number of tests failed: 0
>
> Thanks,
> Joe
>



From peter.levart at gmail.com  Fri Jun 20 11:20:18 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Jun 2014 13:20:18 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A3FA72.3060706@gmail.com>
References: 	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com>
Message-ID: <53A418F2.3080201@gmail.com>

On 06/20/2014 11:10 AM, Peter Levart wrote:
> Perhaps a more lazy initialization of NetworkInterface class that does 
> not trigger initialization of NS providers could help. We just need to 
> invoke two methods on NetworkInterface:
>
> - static NetworkInterface.getNetworkInterfaces()
> - instance NetworkInterface.getHardwareAddress()
>
> both of which could provide the result without the need of NS 
> providers, I think.
>
> This would solve the most general case of using TLR. The case that 
> doesn't involve SecureRandom's help which I think is rarely needed and 
> not default.
>
>
> Regards, Peter 

Hi,

A patch that solves this is a patch to InetAddress. We can't suppress 
initialization of InetAddress as part of NetworkInterface 
initialization, but we can suppress initialization of NameService 
providers as part of InetAddress initialization by moving them into a 
nested class called NameServices:

http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.NameServices/webrev.01/

This should solve Martin's issue, but the patch to TLR initialization 
could be applied nevertheless, since it might help overcome possible 
issues when using SecureRandom for TLR's seed.

Regards, Peter



From zhengyu.gu at oracle.com  Fri Jun 20 12:01:08 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 20 Jun 2014 08:01:08 -0400
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A38068.6010200@oracle.com>
References: <53A38068.6010200@oracle.com>
Message-ID: <53A42284.4020707@oracle.com>

Neil,

Thanks for quick implementation.

java.c:
   Did not check return values of malloc(), I wonder if source code 
analyzers will complain.

-Zhengyu

On 6/19/2014 8:29 PM, Neil Toda wrote:
>
> Launcher support for modified Native Memory Tracking mechanism in JVM 
> in JDK9.
>
> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
> CCC         : http://ccc.us.oracle.com/8042469
>
> Thanks.
>
> -neil
>



From vincent.x.ryan at oracle.com  Fri Jun 20 12:21:46 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 20 Jun 2014 13:21:46 +0100
Subject: [9] request for review 8047353: Improve error message when a JAR
	with invalid signatures is loaded
In-Reply-To: <26b8-53a40600-d-41ced200@248413781>
References: <26b8-53a40600-d-41ced200@248413781>
Message-ID: 

Hello Aaron,

I considered using your testcase that manually generates the necessary malformed JAR
but as there was a suitable signed JAR already in the test suite I decided to re-use that.

I think it makes sense to re-work the test as a Java program. Unfortunately I?ll be on vacation
from today but I?ll return to this issue when I get back.

Thanks.



On 20 Jun 2014, at 11:00, Aaron Digulla  wrote:

> Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy  schrieb:
> 
>> I'd prefer to see the CheckJarSigError.sh as a Java program.
> 
> There original bug report contains a full self-contained test case in Java. Why was that split into several files?
> 
> I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used.
> 
> That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much.
> 
> 
> At least add a command line option / system property which allows to see the full path.
> 
> Regards,
> 
> --
> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
> "It's not the universe that's limited, it's our imagination.
> Follow me and I'll show you something beyond the limits."
> http://blog.pdark.de/



From chris.hegarty at oracle.com  Fri Jun 20 12:50:06 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Jun 2014 13:50:06 +0100
Subject: [concurrency-interest] ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>
	<53A418F2.3080201@gmail.com>
	
Message-ID: <53A42DFE.4080402@oracle.com>

I'm in favor of Peters approach ( I would need to do a more detailed 
review though ).

Looking up name service providers during initialization of InetAddress 
has been the cause of several issues in the past.

I agree with Stanimir's point about TCCL, but I don't think we should 
try to do anything about it. If some application depends on having a 
particular thread, with a "special" TCCL set, initialize InetAddress, 
then it is just broken.

I would prefer to keep this code as simple as possible, and stashing the 
TCCL for later use just adds complication.

-Chris.

On 20/06/14 13:16, Stanimir Simeonoff wrote:
> Hi Peter,
> Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses
> Thread.contextClassLoader to load the services. Depending how late the
> NameServices is getting initialized, perhaps it can be used to
> circumvent the loader available at clinit of InetAddress.
>
> I am not sure it could be a real security concern (as the caller has to
> be authorized to create custom classloaders), yet the behavior is not
> exactly the same. Storing Thread.currentThread().getContextClassLoader()
> during clinit in a WeakRefernce (and clearing on use) should be closest
> to the original code.
>
> Cheers,
> Stanimir
>
>
>
> On Fri, Jun 20, 2014 at 2:20 PM, Peter Levart  > wrote:
>
>     On 06/20/2014 11:10 AM, Peter Levart wrote:
>
>         Perhaps a more lazy initialization of NetworkInterface class
>         that does not trigger initialization of NS providers could help.
>         We just need to invoke two methods on NetworkInterface:
>
>         - static NetworkInterface.__getNetworkInterfaces()
>         - instance NetworkInterface.__getHardwareAddress()
>
>         both of which could provide the result without the need of NS
>         providers, I think.
>
>         This would solve the most general case of using TLR. The case
>         that doesn't involve SecureRandom's help which I think is rarely
>         needed and not default.
>
>
>         Regards, Peter
>
>
>     Hi,
>
>     A patch that solves this is a patch to InetAddress. We can't
>     suppress initialization of InetAddress as part of NetworkInterface
>     initialization, but we can suppress initialization of NameService
>     providers as part of InetAddress initialization by moving them into
>     a nested class called NameServices:
>
>     http://cr.openjdk.java.net/~__plevart/jdk9-dev/InetAddress.__NameServices/webrev.01/
>     
>
>     This should solve Martin's issue, but the patch to TLR
>     initialization could be applied nevertheless, since it might help
>     overcome possible issues when using SecureRandom for TLR's seed.
>
>     Regards, Peter
>
>
>     _________________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.__oswego.edu
>     
>     http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>     
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


From Alan.Bateman at oracle.com  Fri Jun 20 13:00:05 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jun 2014 14:00:05 +0100
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A418F2.3080201@gmail.com>
References: 	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
Message-ID: <53A43055.5070803@oracle.com>

On 20/06/2014 12:20, Peter Levart wrote:
>
> Hi,
>
> A patch that solves this is a patch to InetAddress. We can't suppress 
> initialization of InetAddress as part of NetworkInterface 
> initialization, but we can suppress initialization of NameService 
> providers as part of InetAddress initialization by moving them into a 
> nested class called NameServices:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.NameServices/webrev.01/ 
>
>
> This should solve Martin's issue, but the patch to TLR initialization 
> could be applied nevertheless, since it might help overcome possible 
> issues when using SecureRandom for TLR's seed.
That should work. An alternative is to just get rid of this mechanism. 
Way back then it was useful for running on systems that has NIS/YP 
configured as it wasn't always possible get to the fully qualified host 
name. It was also used as a workaround to long timeouts on Windows doing 
NetBIOS lookups. I don't think if either of these cases it interesting 
these days so it might be the simplest thing to just get rid of it. The 
other thing is that it was never meant to be a general service provider 
mechanism, it's not usable outside of the JDK without extending 
JDK-internal classes for example.

-Alan


From vincent.x.ryan at oracle.com  Fri Jun 20 12:58:00 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 20 Jun 2014 13:58:00 +0100
Subject: [9] request for review 8047353: Improve error message when a JAR
	with invalid signatures is loaded
In-Reply-To: 
References: <26b8-53a40600-d-41ced200@248413781>
	
Message-ID: 

There is precedence for revealing the full pathname only when a security manager is not running.
Would that be acceptable?


On 20 Jun 2014, at 13:21, Vincent Ryan  wrote:

> Hello Aaron,
> 
> I considered using your testcase that manually generates the necessary malformed JAR
> but as there was a suitable signed JAR already in the test suite I decided to re-use that.
> 
> I think it makes sense to re-work the test as a Java program. Unfortunately I?ll be on vacation
> from today but I?ll return to this issue when I get back.
> 
> Thanks.
> 
> 
> 
> On 20 Jun 2014, at 11:00, Aaron Digulla  wrote:
> 
>> Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy  schrieb:
>> 
>>> I'd prefer to see the CheckJarSigError.sh as a Java program.
>> 
>> There original bug report contains a full self-contained test case in Java. Why was that split into several files?
>> 
>> I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used.
>> 
>> That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much.
>> 
>> 
>> At least add a command line option / system property which allows to see the full path.
>> 
>> Regards,
>> 
>> --
>> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
>> "It's not the universe that's limited, it's our imagination.
>> Follow me and I'll show you something beyond the limits."
>> http://blog.pdark.de/
> 



From otaviojava at java.net  Fri Jun 20 13:12:14 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Fri, 20 Jun 2014 10:12:14 -0300
Subject: Optimizations to create instances in Number classes and Character
Message-ID: 

The Number classes (Integer, Short, Byte, Long) and Character have cache
and it is used when is called the valueOf method, this way it creates new
instances when is necessary. Using the valueOf, when the value is in the
cache, beyond save memory will faster than always create new instances.

[1] WebDrev:
https://dl.dropboxusercontent.com/u/16109193/open_jdk/number_character.zip



Benchmark                                  (size)   Mode   Samples
Mean   Mean error    Units
m.InstancesBenchmark.newInstanceByte      1000000  thrpt        10
 295.250        3.964    ops/s
m.InstancesBenchmark.newInstanceChar      1000000  thrpt        10
 290.962        6.096    ops/s
m.InstancesBenchmark.newInstanceInteger   1000000  thrpt        10
 280.035        5.997    ops/s
m.InstancesBenchmark.newInstanceLong      1000000  thrpt        10
 195.535        5.326    ops/s
m.InstancesBenchmark.newInstanceShort     1000000  thrpt        10
 289.213        6.920    ops/s
m.InstancesBenchmark.valueOfByte          1000000  thrpt        10
 457.773        0.788    ops/s
m.InstancesBenchmark.valueOfChar          1000000  thrpt        10
 343.380        1.364    ops/s
m.InstancesBenchmark.valueOfInteger       1000000  thrpt        10
 332.707        1.771    ops/s
m.InstancesBenchmark.valueOfLong          1000000  thrpt        10
 336.833        3.318    ops/s
m.InstancesBenchmark.valueOfShort         1000000  thrpt        10
 333.420        0.651    ops/s


[1]

import java.util.ArrayList;
import java.util.List;
import java.util.Random;
import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.GenerateMicroBenchmark;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.logic.BlackHole;

@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.SECONDS)
public class InstancesBenchmark {

    @Param("1000000")
    private int size;

    private Random random;

    private short[] shorts;
    private byte[] bytes;
    private int[] interges;
    private long[] longs;
    private char[] chars;

    @Setup
    public void s() {
        random = new Random();
        shorts = new short[size];
        bytes = new byte[size];
        interges = new int[size];
        longs = new long[size];
        chars = new char[size];
        for (int i = 0; i < size; i++) {
            int value = random.nextInt();
            longs[i] = (long) value;
            interges[i] = value;
            shorts[i] = (short) value;
            bytes[i] = (byte) value;
            chars[i] = (char) value;
        }

    }

    @GenerateMicroBenchmark
    public void valueOfInteger(BlackHole bh) {
        for (int value : interges) {
            Integer number = value;
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void newInstanceInteger(BlackHole bh) {
        for (int value : interges) {
            Integer number = new Integer(value);
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void valueOfLong(BlackHole bh) {
        for (long value : longs) {
            Long number = value;
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void newInstanceLong(BlackHole bh) {
        for (long value : longs) {
            Long number = new Long(value);
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void valueOfByte(BlackHole bh) {
        for (byte value : bytes) {
            Byte number = value;
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void newInstanceByte(BlackHole bh) {
        for (byte value : bytes) {
            Byte number = new Byte(value);
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void valueOfShort(BlackHole bh) {
        for (short value : shorts) {
            Short number = value;
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void newInstanceShort(BlackHole bh) {
        for (short value : shorts) {
            Short number = new Short(value);
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void valueOfChar(BlackHole bh) {
        for (char value : chars) {
            Character number = value;
            bh.consume(number);
        }
    }

    @GenerateMicroBenchmark
    public void newInstanceChar(BlackHole bh) {
        for (char value : chars) {
            Character number = new Character(value);
            bh.consume(number);
        }
    }

}

-- 
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 d02b062bc827 src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java
--- a/src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java	Fri Jun 20 09:57:19 2014 -0300
@@ -461,10 +461,10 @@
                         if ((currentBreakPositions.size() == 0 ||
                              currentBreakPositions.peek().intValue() != text.getIndex())
                             && text.getIndex() != startPos) {
-                            currentBreakPositions.push(new Integer(text.getIndex()));
+                            currentBreakPositions.push(text.getIndex());
                         }
                         getNext();
-                        currentBreakPositions.push(new Integer(text.getIndex()));
+                        currentBreakPositions.push(text.getIndex());
                     }
                 }
 
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/tools/asm/Assembler.java
--- a/src/share/classes/sun/tools/asm/Assembler.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/asm/Assembler.java	Fri Jun 20 09:57:19 2014 -0300
@@ -558,7 +558,7 @@
               case opc_tableswitch: {
                 SwitchData sw = (SwitchData)inst.value;
                 for (int i = sw.minValue; i <= sw.maxValue; i++) {
-                     TableLot.addElement(new Cover(CT_CASE, sw.whereCase(new Integer(i)), inst.pc));
+                     TableLot.addElement(new Cover(CT_CASE, sw.whereCase(i), inst.pc));
                      count++;
                 }
                 if (!sw.getDefault()) {
diff -r d02b062bc827 src/share/classes/sun/tools/asm/Instruction.java
--- a/src/share/classes/sun/tools/asm/Instruction.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/asm/Instruction.java	Fri Jun 20 09:57:19 2014 -0300
@@ -142,7 +142,7 @@
             // Don't keep the LocalVariable info around, unless we
             // are actually going to generate a local variable table.
             if ((value instanceof LocalVariable) && !env.debug_vars()) {
-                value = new Integer(((LocalVariable)value).slot);
+                value = ((LocalVariable)value).slot;
             }
             break;
 
diff -r d02b062bc827 src/share/classes/sun/tools/java/BinaryConstantPool.java
--- a/src/share/classes/sun/tools/java/BinaryConstantPool.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/java/BinaryConstantPool.java	Fri Jun 20 09:57:19 2014 -0300
@@ -60,13 +60,13 @@
                 break;
 
               case CONSTANT_INTEGER:
-                cpool[i] = new Integer(in.readInt());
+                cpool[i] = in.readInt();
                 break;
               case CONSTANT_FLOAT:
                 cpool[i] = new Float(in.readFloat());
                 break;
               case CONSTANT_LONG:
-                cpool[i++] = new Long(in.readLong());
+                cpool[i++] = in.readLong();
                 break;
               case CONSTANT_DOUBLE:
                 cpool[i++] = new Double(in.readDouble());
@@ -76,7 +76,7 @@
               case CONSTANT_STRING:
                 // JVM 4.4.3 CONSTANT_String_info.string_index
                 // or JVM 4.4.1 CONSTANT_Class_info.name_index
-                cpool[i] = new Integer(in.readUnsignedShort());
+                cpool[i] = in.readUnsignedShort();
                 break;
 
               case CONSTANT_FIELD:
@@ -84,7 +84,7 @@
               case CONSTANT_INTERFACEMETHOD:
               case CONSTANT_NAMEANDTYPE:
                 // JVM 4.4.2 CONSTANT_*ref_info.class_index & name_and_type_index
-                cpool[i] = new Integer((in.readUnsignedShort() << 16) | in.readUnsignedShort());
+                cpool[i] = (in.readUnsignedShort() << 16) | in.readUnsignedShort();
                 break;
 
               case CONSTANT_METHODHANDLE:
@@ -260,7 +260,7 @@
         Integer result = (Integer)indexHashAscii.get(string);
         if (result == null) {
             if (MoreStuff == null) MoreStuff = new Vector();
-            result = new Integer(cpool.length + MoreStuff.size());
+            result = cpool.length + MoreStuff.size();
             MoreStuff.addElement(string);
             indexHashAscii.put(string, result);
         }
@@ -277,10 +277,10 @@
         indexHashAscii = new Hashtable();
         for (int i = 1; i < cpool.length; i++) {
             if (types[i] == CONSTANT_UTF8) {
-                indexHashAscii.put(cpool[i], new Integer(i));
+                indexHashAscii.put(cpool[i], i);
             } else {
                 try {
-                    indexHashObject.put(getConstant(i, env), new Integer(i));
+                    indexHashObject.put(getConstant(i, env), i);
                 } catch (ClassFormatError e) { }
             }
         }
diff -r d02b062bc827 src/share/classes/sun/tools/java/Identifier.java
--- a/src/share/classes/sun/tools/java/Identifier.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/java/Identifier.java	Fri Jun 20 09:57:19 2014 -0300
@@ -106,7 +106,7 @@
      * Set the type of the identifier.
      */
     void setType(int t) {
-        value = new Integer(t);
+        value = t;
         //System.out.println("type(" + this + ")=" + t);
     }
 
diff -r d02b062bc827 src/share/classes/sun/tools/javac/BatchEnvironment.java
--- a/src/share/classes/sun/tools/javac/BatchEnvironment.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/javac/BatchEnvironment.java	Fri Jun 20 09:57:19 2014 -0300
@@ -1172,7 +1172,7 @@
                     if (!hitErrorLimit) {
                         hitErrorLimit = true;
                         output(errorString("too.many.errors",
-                                           new Integer(errorLimit),null,null));
+                                           errorLimit,null,null));
                     }
                     return;
                 }
diff -r d02b062bc827 src/share/classes/sun/tools/javac/Main.java
--- a/src/share/classes/sun/tools/javac/Main.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/javac/Main.java	Fri Jun 20 09:57:19 2014 -0300
@@ -668,19 +668,18 @@
             Object file1 = env.deprecationFiles.elementAt(0);
             if (env.deprecation()) {
                 if (ndepfiles > 1) {
-                    env.error(0, "warn.note.deprecations",
-                              new Integer(ndepfiles), new Integer(ndeps));
+					env.error(0, "warn.note.deprecations", ndepfiles, ndeps);
                 } else {
                     env.error(0, "warn.note.1deprecation",
-                              file1, new Integer(ndeps));
+                              file1, ndeps);
                 }
             } else {
                 if (ndepfiles > 1) {
                     env.error(0, "warn.note.deprecations.silent",
-                              new Integer(ndepfiles), new Integer(ndeps));
+                              ndepfiles, ndeps);
                 } else {
                     env.error(0, "warn.note.1deprecation.silent",
-                              file1, new Integer(ndeps));
+                              file1, ndeps);
                 }
             }
         }
diff -r d02b062bc827 src/share/classes/sun/tools/javac/SourceMember.java
--- a/src/share/classes/sun/tools/javac/SourceMember.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/javac/SourceMember.java	Fri Jun 20 09:57:19 2014 -0300
@@ -885,7 +885,7 @@
                     // instance initializers.  Code for these is generated
                     // in the makeVarInits() method of the class
                     // MethodExpression.
-                    asm.add(getWhere(), opc_aload, new Integer(0));
+                    asm.add(getWhere(), opc_aload, 0);
                     e.codeValue(env, ctx, asm);
                     asm.add(getWhere(), opc_putfield, this);
                 }
diff -r d02b062bc827 src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java
--- a/src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java	Fri Jun 20 09:57:19 2014 -0300
@@ -56,7 +56,7 @@
                 ObjectName mbeanName = new ObjectName(GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE +
                                                       ",name=" + name);
                 if (client.isRegistered(mbeanName)) {
-                    gcMBeans.put(mbeanName, new Long(0));
+                    gcMBeans.put(mbeanName, 0L);
                 }
             } catch (Exception e) {
                 assert false;
@@ -97,7 +97,7 @@
             Long gcCount = e.getValue();
             Long newCount = gc.getCollectionCount();
             if (newCount > gcCount) {
-                gcMBeans.put(e.getKey(), new Long(newCount));
+                gcMBeans.put(e.getKey(), newCount);
                 lastGcInfo = gc.getLastGcInfo();
                 if (lastGcInfo.getEndTime() > lastGcEndTime) {
                     gcId = lastGcInfo.getId();
diff -r d02b062bc827 src/share/classes/sun/tools/jconsole/inspector/Utils.java
--- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java	Fri Jun 20 09:57:19 2014 -0300
@@ -342,14 +342,14 @@
         Object result;
         if (primitiveToWrapper.containsKey(type)) {
             if (type.equals(Character.TYPE.getName())) {
-                result = new Character(value.charAt(0));
+                result = value.charAt(0);
             } else {
                 result = newStringConstructor(
                         ((Class) primitiveToWrapper.get(type)).getName(),
                         value);
             }
         } else if (type.equals(Character.class.getName())) {
-            result = new Character(value.charAt(0));
+            result = value.charAt(0);
         } else if (Number.class.isAssignableFrom(Utils.getClass(type))) {
             result = createNumberFromStringValue(value);
         } else if (value == null || value.equals("null")) {
diff -r d02b062bc827 src/share/classes/sun/tools/jstat/Jstat.java
--- a/src/share/classes/sun/tools/jstat/Jstat.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/jstat/Jstat.java	Fri Jun 20 09:57:19 2014 -0300
@@ -158,7 +158,7 @@
         // handle target termination events for targets other than ourself
         HostListener terminator = new HostListener() {
             public void vmStatusChanged(VmStatusChangeEvent ev) {
-                Integer lvmid = new Integer(vmId.getLocalVmId());
+                Integer lvmid = vmId.getLocalVmId();
                 if (ev.getTerminated().contains(lvmid)) {
                     logger.stopLogging();
                 } else if (!ev.getActive().contains(lvmid)) {
diff -r d02b062bc827 src/share/classes/sun/tools/jstatd/RemoteHostImpl.java
--- a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java	Fri Jun 20 09:57:19 2014 -0300
@@ -62,7 +62,7 @@
 
     public RemoteVm attachVm(int lvmid, String mode)
                     throws RemoteException, MonitorException {
-        Integer v = new Integer(lvmid);
+        Integer v = lvmid;
         RemoteVm stub = null;
         StringBuffer sb = new StringBuffer();
 
diff -r d02b062bc827 src/share/classes/sun/tools/tree/ArrayExpression.java
--- a/src/share/classes/sun/tools/tree/ArrayExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/ArrayExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -92,16 +92,16 @@
      */
     public void codeValue(Environment env, Context ctx, Assembler asm) {
         int t = 0;
-        asm.add(where, opc_ldc, new Integer(args.length));
+        asm.add(where, opc_ldc, args.length);
         switch (type.getElementType().getTypeCode()) {
-          case TC_BOOLEAN:      asm.add(where, opc_newarray, new Integer(T_BOOLEAN));   break;
-          case TC_BYTE:         asm.add(where, opc_newarray, new Integer(T_BYTE));      break;
-          case TC_SHORT:        asm.add(where, opc_newarray, new Integer(T_SHORT));     break;
-          case TC_CHAR:         asm.add(where, opc_newarray, new Integer(T_CHAR));      break;
-          case TC_INT:          asm.add(where, opc_newarray, new Integer(T_INT));       break;
-          case TC_LONG:         asm.add(where, opc_newarray, new Integer(T_LONG));      break;
-          case TC_FLOAT:        asm.add(where, opc_newarray, new Integer(T_FLOAT));     break;
-          case TC_DOUBLE:       asm.add(where, opc_newarray, new Integer(T_DOUBLE));    break;
+          case TC_BOOLEAN:      asm.add(where, opc_newarray, T_BOOLEAN);   break;
+          case TC_BYTE:         asm.add(where, opc_newarray, T_BYTE);      break;
+          case TC_SHORT:        asm.add(where, opc_newarray, T_SHORT);     break;
+          case TC_CHAR:         asm.add(where, opc_newarray, T_CHAR);      break;
+          case TC_INT:          asm.add(where, opc_newarray, T_INT);       break;
+          case TC_LONG:         asm.add(where, opc_newarray, T_LONG);      break;
+          case TC_FLOAT:        asm.add(where, opc_newarray, T_FLOAT);     break;
+          case TC_DOUBLE:       asm.add(where, opc_newarray, T_DOUBLE);    break;
 
           case TC_ARRAY:
             asm.add(where, opc_anewarray, type.getElementType());
@@ -122,7 +122,7 @@
             if (args[i].equalsDefault()) continue;
 
             asm.add(where, opc_dup);
-            asm.add(where, opc_ldc, new Integer(i));
+            asm.add(where, opc_ldc, i);
             args[i].codeValue(env, ctx, asm);
             switch (type.getElementType().getTypeCode()) {
               case TC_BOOLEAN:
diff -r d02b062bc827 src/share/classes/sun/tools/tree/BinaryExpression.java
--- a/src/share/classes/sun/tools/tree/BinaryExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/BinaryExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -212,10 +212,10 @@
             Label l2 = new Label();
 
             codeBranch(env, ctx, asm, l1, true);
-            asm.add(true, where, opc_ldc, new Integer(0));
+            asm.add(true, where, opc_ldc, 0);
             asm.add(true, where, opc_goto, l2);
             asm.add(l1);
-            asm.add(true, where, opc_ldc, new Integer(1));
+            asm.add(true, where, opc_ldc, 1);
             asm.add(l2);
         } else {
             left.codeValue(env, ctx, asm);
diff -r d02b062bc827 src/share/classes/sun/tools/tree/BitNotExpression.java
--- a/src/share/classes/sun/tools/tree/BitNotExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/BitNotExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -80,10 +80,10 @@
     public void codeValue(Environment env, Context ctx, Assembler asm) {
         right.codeValue(env, ctx, asm);
         if (type.isType(TC_INT)) {
-            asm.add(where, opc_ldc, new Integer(-1));
+            asm.add(where, opc_ldc, -1);
             asm.add(where, opc_ixor);
         } else {
-            asm.add(where, opc_ldc2_w, new Long(-1));
+            asm.add(where, opc_ldc2_w, -1L);
             asm.add(where, opc_lxor);
         }
     }
diff -r d02b062bc827 src/share/classes/sun/tools/tree/BooleanExpression.java
--- a/src/share/classes/sun/tools/tree/BooleanExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/BooleanExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -52,7 +52,7 @@
      * Get the value
      */
     public Object getValue() {
-        return new Integer(value ? 1 : 0);
+        return value ? 1 : 0;
     }
 
     /**
@@ -106,7 +106,7 @@
         }
     }
     public void codeValue(Environment env, Context ctx, Assembler asm) {
-        asm.add(where, opc_ldc, new Integer(value ? 1 : 0));
+        asm.add(where, opc_ldc, value ? 1 : 0);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/tools/tree/Expression.java
--- a/src/share/classes/sun/tools/tree/Expression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/Expression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -432,10 +432,10 @@
             Label l2 = new Label();
 
             codeBranch(env, ctx, asm, l1, true);
-            asm.add(true, where, opc_ldc, new Integer(0));
+            asm.add(true, where, opc_ldc, 0);
             asm.add(true, where, opc_goto, l2);
             asm.add(l1);
-            asm.add(true, where, opc_ldc, new Integer(1));
+            asm.add(true, where, opc_ldc, 1);
             asm.add(l2);
         } else {
             throw new CompilerError("codeValue");
diff -r d02b062bc827 src/share/classes/sun/tools/tree/FinallyStatement.java
--- a/src/share/classes/sun/tools/tree/FinallyStatement.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/FinallyStatement.java	Fri Jun 20 09:57:19 2014 -0300
@@ -287,8 +287,8 @@
             // allocate space for the exception and return address
             f1 = new LocalMember(where, thisClass, 0, Type.tObject, null);
             f2 = new LocalMember(where, thisClass, 0, Type.tInt, null);
-            num1 = new Integer(ctx.declare(env, f1));
-            num2 = new Integer(ctx.declare(env, f2));
+            num1 = ctx.declare(env, f1);
+            num2 = ctx.declare(env, f2);
         }
 
         TryData td = new TryData();
diff -r d02b062bc827 src/share/classes/sun/tools/tree/IdentifierExpression.java
--- a/src/share/classes/sun/tools/tree/IdentifierExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/IdentifierExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -452,7 +452,7 @@
     }
     void codeLoad(Environment env, Context ctx, Assembler asm) {
         asm.add(where, opc_iload + type.getTypeCodeOffset(),
-                new Integer(((LocalMember)field).number));
+                ((LocalMember)field).number);
     }
     void codeStore(Environment env, Context ctx, Assembler asm) {
         LocalMember local = (LocalMember)field;
diff -r d02b062bc827 src/share/classes/sun/tools/tree/IncDecExpression.java
--- a/src/share/classes/sun/tools/tree/IncDecExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/IncDecExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -112,26 +112,26 @@
     private void codeIncDecOp(Assembler asm, boolean inc) {
         switch (type.getTypeCode()) {
           case TC_BYTE:
-            asm.add(where, opc_ldc, new Integer(1));
+            asm.add(where, opc_ldc, 1);
             asm.add(where, inc ? opc_iadd : opc_isub);
             asm.add(where, opc_i2b);
             break;
           case TC_SHORT:
-            asm.add(where, opc_ldc, new Integer(1));
+            asm.add(where, opc_ldc, 1);
             asm.add(where, inc ? opc_iadd : opc_isub);
             asm.add(where, opc_i2s);
             break;
           case TC_CHAR:
-            asm.add(where, opc_ldc, new Integer(1));
+            asm.add(where, opc_ldc, 1);
             asm.add(where, inc ? opc_iadd : opc_isub);
             asm.add(where, opc_i2c);
             break;
           case TC_INT:
-            asm.add(where, opc_ldc, new Integer(1));
+            asm.add(where, opc_ldc, 1);
             asm.add(where, inc ? opc_iadd : opc_isub);
             break;
           case TC_LONG:
-            asm.add(where, opc_ldc2_w, new Long(1));
+            asm.add(where, opc_ldc2_w, 1L);
             asm.add(where, inc ? opc_ladd : opc_lsub);
             break;
           case TC_FLOAT:
diff -r d02b062bc827 src/share/classes/sun/tools/tree/InlineNewInstanceExpression.java
--- a/src/share/classes/sun/tools/tree/InlineNewInstanceExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/InlineNewInstanceExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -93,11 +93,11 @@
             LocalMember v = (LocalMember)field.getArguments().elementAt(0);
             CodeContext newctx = new CodeContext(ctx, this);
             newctx.declare(env, v);
-            asm.add(where, opc_astore, new Integer(v.number));
+            asm.add(where, opc_astore, v.number);
             body.code(env, newctx, asm);
             asm.add(newctx.breakLabel);
             if (forValue) {
-                asm.add(where, opc_aload, new Integer(v.number));
+                asm.add(where, opc_aload, v.number);
             }
         }
     }
diff -r d02b062bc827 src/share/classes/sun/tools/tree/IntegerExpression.java
--- a/src/share/classes/sun/tools/tree/IntegerExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/IntegerExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -70,7 +70,7 @@
      * Get the value
      */
     public Object getValue() {
-        return new Integer(value);
+        return value;
     }
 
     /**
@@ -91,6 +91,6 @@
      * Code
      */
     public void codeValue(Environment env, Context ctx, Assembler asm) {
-        asm.add(where, opc_ldc, new Integer(value));
+        asm.add(where, opc_ldc, value);
     }
 }
diff -r d02b062bc827 src/share/classes/sun/tools/tree/LongExpression.java
--- a/src/share/classes/sun/tools/tree/LongExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/LongExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -50,7 +50,7 @@
      * Get the value
      */
     public Object getValue() {
-        return new Long(value);
+        return value;
     }
 
     /**
@@ -71,7 +71,7 @@
      * Code
      */
     public void codeValue(Environment env, Context ctx, Assembler asm) {
-        asm.add(where, opc_ldc2_w, new Long(value));
+        asm.add(where, opc_ldc2_w, value);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/tools/tree/MethodExpression.java
--- a/src/share/classes/sun/tools/tree/MethodExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/MethodExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -857,7 +857,7 @@
                 right.code(env, ctx, asm);
             }
         } else if (right == null) {
-            asm.add(where, opc_aload, new Integer(0));
+            asm.add(where, opc_aload, 0);
         } else if (right.op == SUPER) {
             // 'super.(...)', 'super(...)', or '.super(...)'
             /*****
diff -r d02b062bc827 src/share/classes/sun/tools/tree/NewArrayExpression.java
--- a/src/share/classes/sun/tools/tree/NewArrayExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/NewArrayExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -133,21 +133,21 @@
 
         switch (type.getElementType().getTypeCode()) {
             case TC_BOOLEAN:
-                asm.add(where, opc_newarray, new Integer(T_BOOLEAN));   break;
+                asm.add(where, opc_newarray, T_BOOLEAN);   break;
             case TC_BYTE:
-                asm.add(where, opc_newarray, new Integer(T_BYTE));      break;
+                asm.add(where, opc_newarray, T_BYTE);      break;
             case TC_SHORT:
-                asm.add(where, opc_newarray, new Integer(T_SHORT));     break;
+                asm.add(where, opc_newarray, T_SHORT);     break;
             case TC_CHAR:
-                asm.add(where, opc_newarray, new Integer(T_CHAR));      break;
+                asm.add(where, opc_newarray, T_CHAR);      break;
             case TC_INT:
-                asm.add(where, opc_newarray, new Integer(T_INT));       break;
+                asm.add(where, opc_newarray, T_INT);       break;
             case TC_LONG:
-                asm.add(where, opc_newarray, new Integer(T_LONG));      break;
+                asm.add(where, opc_newarray, T_LONG);      break;
             case TC_FLOAT:
-                asm.add(where, opc_newarray, new Integer(T_FLOAT));     break;
+                asm.add(where, opc_newarray, T_FLOAT);     break;
             case TC_DOUBLE:
-                asm.add(where, opc_newarray, new Integer(T_DOUBLE));    break;
+                asm.add(where, opc_newarray, T_DOUBLE);    break;
             case TC_ARRAY:
                 asm.add(where, opc_anewarray, type.getElementType());   break;
             case TC_CLASS:
diff -r d02b062bc827 src/share/classes/sun/tools/tree/NotExpression.java
--- a/src/share/classes/sun/tools/tree/NotExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/NotExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -139,7 +139,7 @@
      */
     public void codeValue(Environment env, Context ctx, Assembler asm) {
         right.codeValue(env, ctx, asm);
-        asm.add(where, opc_ldc, new Integer(1));
+        asm.add(where, opc_ldc, 1);
         asm.add(where, opc_ixor);
     }
 
diff -r d02b062bc827 src/share/classes/sun/tools/tree/Statement.java
--- a/src/share/classes/sun/tools/tree/Statement.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/Statement.java	Fri Jun 20 09:57:19 2014 -0300
@@ -249,7 +249,7 @@
                 // Save the return value in the register which should have
                 // been reserved.
                 LocalMember lf = ctx.getLocalField(idFinallyReturnValue);
-                num = new Integer(lf.number);
+                num = lf.number;
                 asm.add(where, opc_istore + save.getTypeCodeOffset(), num);
             } else {
                 // Pop the return value.
diff -r d02b062bc827 src/share/classes/sun/tools/tree/SynchronizedStatement.java
--- a/src/share/classes/sun/tools/tree/SynchronizedStatement.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/SynchronizedStatement.java	Fri Jun 20 09:57:19 2014 -0300
@@ -125,8 +125,8 @@
 
         LocalMember f1 = new LocalMember(where, clazz, 0, Type.tObject, null);
         LocalMember f2 = new LocalMember(where, clazz, 0, Type.tInt, null);
-        Integer num1 = new Integer(ctx.declare(env, f1));
-        Integer num2 = new Integer(ctx.declare(env, f2));
+        Integer num1 = ctx.declare(env, f1);
+        Integer num2 = ctx.declare(env, f2);
 
         Label endLabel = new Label();
 
diff -r d02b062bc827 src/share/classes/sun/tools/tree/ThisExpression.java
--- a/src/share/classes/sun/tools/tree/ThisExpression.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/tools/tree/ThisExpression.java	Fri Jun 20 09:57:19 2014 -0300
@@ -169,7 +169,7 @@
      * Code
      */
     public void codeValue(Environment env, Context ctx, Assembler asm) {
-        asm.add(where, opc_aload, new Integer(field.number));
+        asm.add(where, opc_aload, field.number);
     }
 
     /**
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/swing/PrintingStatus.java
--- a/src/share/classes/sun/swing/PrintingStatus.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/swing/PrintingStatus.java	Fri Jun 20 09:57:18 2014 -0300
@@ -295,7 +295,7 @@
         private void updateStatusOnEDT(int pageIndex) {
             assert SwingUtilities.isEventDispatchThread();
             Object[] pageNumber = new Object[]{
-                new Integer(pageIndex + 1)};
+                pageIndex + 1};
             statusLabel.setText(statusFormat.format(pageNumber));
         }
     }
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/security/action/GetIntegerAction.java
--- a/src/share/classes/sun/security/action/GetIntegerAction.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/action/GetIntegerAction.java	Fri Jun 20 09:57:18 2014 -0300
@@ -107,7 +107,7 @@
     public Integer run() {
         Integer value = Integer.getInteger(theProp);
         if ((value == null) && defaultSet)
-            return new Integer(defaultVal);
+            return defaultVal;
         return value;
     }
 }
diff -r d02b062bc827 src/share/classes/sun/security/action/GetLongAction.java
--- a/src/share/classes/sun/security/action/GetLongAction.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/action/GetLongAction.java	Fri Jun 20 09:57:18 2014 -0300
@@ -106,7 +106,7 @@
     public Long run() {
         Long value = Long.getLong(theProp);
         if ((value == null) && defaultSet)
-            return new Long(defaultVal);
+            return defaultVal;
         return value;
     }
 }
diff -r d02b062bc827 src/share/classes/sun/security/jgss/krb5/ServiceCreds.java
--- a/src/share/classes/sun/security/jgss/krb5/ServiceCreds.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/jgss/krb5/ServiceCreds.java	Fri Jun 20 09:57:18 2014 -0300
@@ -231,7 +231,7 @@
         for (int i=0; i 0) {
             if (((byte) (der.getData().peekByte()) & (byte) 0x1F) == (byte) 0x01) {
                 subDer = der.getData().getDerValue();
-                nonce = new Integer(subDer.getData().getBigInteger().intValue());
+                nonce = subDer.getData().getBigInteger().intValue();
             }
         }
         if (der.getData().available() > 0) {
@@ -149,7 +149,7 @@
         if (der.getData().available() > 0) {
             if (((byte) (der.getData().peekByte()) & (byte) 0x1F) == (byte) 0x03) {
                 subDer = der.getData().getDerValue();
-                usec = new Integer(subDer.getData().getBigInteger().intValue());
+                usec = subDer.getData().getBigInteger().intValue();
             }
         }
         if (der.getData().available() > 0) {
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/EncKrbPrivPart.java
--- a/src/share/classes/sun/security/krb5/internal/EncKrbPrivPart.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/EncKrbPrivPart.java	Fri Jun 20 09:57:18 2014 -0300
@@ -115,13 +115,13 @@
         timestamp = KerberosTime.parse(der.getData(), (byte) 0x01, true);
         if ((der.getData().peekByte() & 0x1F) == 0x02) {
             subDer = der.getData().getDerValue();
-            usec = new Integer(subDer.getData().getBigInteger().intValue());
+            usec = subDer.getData().getBigInteger().intValue();
         } else {
             usec = null;
         }
         if ((der.getData().peekByte() & 0x1F) == 0x03) {
             subDer = der.getData().getDerValue();
-            seqNumber = new Integer(subDer.getData().getBigInteger().intValue());
+            seqNumber = subDer.getData().getBigInteger().intValue();
         } else {
             seqNumber = null;
         }
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/KRBError.java
--- a/src/share/classes/sun/security/krb5/internal/KRBError.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/KRBError.java	Fri Jun 20 09:57:18 2014 -0300
@@ -335,7 +335,7 @@
         cTime = KerberosTime.parse(der.getData(), (byte)0x02, true);
         if ((der.getData().peekByte() & 0x1F) == 0x03) {
             subDer = der.getData().getDerValue();
-            cuSec = new Integer(subDer.getData().getBigInteger().intValue());
+            cuSec = subDer.getData().getBigInteger().intValue();
         }
         else cuSec = null;
         sTime = KerberosTime.parse(der.getData(), (byte)0x04, false);
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/KRBSafeBody.java
--- a/src/share/classes/sun/security/krb5/internal/KRBSafeBody.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/KRBSafeBody.java	Fri Jun 20 09:57:18 2014 -0300
@@ -104,11 +104,11 @@
         timestamp = KerberosTime.parse(encoding.getData(), (byte)0x01, true);
         if ((encoding.getData().peekByte() & 0x1F) == 0x02) {
             der = encoding.getData().getDerValue();
-            usec = new Integer(der.getData().getBigInteger().intValue());
+            usec = der.getData().getBigInteger().intValue();
         }
         if ((encoding.getData().peekByte() & 0x1F) == 0x03) {
             der = encoding.getData().getDerValue();
-            seqNumber = new Integer(der.getData().getBigInteger().intValue());
+            seqNumber = der.getData().getBigInteger().intValue();
         }
         sAddress = HostAddress.parse(encoding.getData(), (byte)0x04, false);
         if (encoding.getData().available() > 0)
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/KerberosTime.java
--- a/src/share/classes/sun/security/krb5/internal/KerberosTime.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/KerberosTime.java	Fri Jun 20 09:57:18 2014 -0300
@@ -188,7 +188,7 @@
     }
 
     public int getMicroSeconds() {
-        Long temp_long = new Long((kerberosTime % 1000L) * 1000L);
+        Long temp_long = (kerberosTime % 1000L) * 1000L;
         return temp_long.intValue() + microSeconds;
     }
 
@@ -250,7 +250,7 @@
     }
 
     public int getSeconds() {
-        Long temp_long = new Long(kerberosTime / 1000L);
+        Long temp_long = kerberosTime / 1000L;
         return temp_long.intValue();
     }
 
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java
--- a/src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java	Fri Jun 20 09:57:18 2014 -0300
@@ -67,7 +67,7 @@
     public PAEncTSEnc() {
         KerberosTime now = KerberosTime.now();
         pATimeStamp = now;
-        pAUSec = new Integer(now.getMicroSeconds());
+        pAUSec = now.getMicroSeconds();
     }
 
     /**
@@ -85,7 +85,7 @@
         if (encoding.getData().available() > 0) {
             der = encoding.getData().getDerValue();
             if ((der.getTag() & 0x1F) == 0x01) {
-                pAUSec = new Integer(der.getData().getBigInteger().intValue());
+                pAUSec = der.getData().getBigInteger().intValue();
             }
             else throw new Asn1Exception(Krb5.ASN1_BAD_ID);
         }
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
--- a/src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java	Fri Jun 20 09:57:18 2014 -0300
@@ -94,8 +94,8 @@
             taglen = read(2);
             switch (tag) {
             case FCC_TAG_DELTATIME:
-                time_offset = new Integer(read(4));
-                usec_offset = new Integer(read(4));
+                time_offset = read(4);
+                usec_offset = read(4);
                 break;
             default:
             }
@@ -186,7 +186,7 @@
             read(2); /* keytype recorded twice in fvno 3 */
         keyLen = read(4);
         byte[] bytes = IOUtils.readFully(this, keyLen, true);
-        return new EncryptionKey(bytes, keyType, new Integer(version));
+        return new EncryptionKey(bytes, keyType, version);
     }
 
     long[] readTimes() throws IOException {
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
--- a/src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java	Fri Jun 20 09:57:18 2014 -0300
@@ -297,7 +297,7 @@
                 if (EType.isSupported(entry.keyType)) {
                     key = new EncryptionKey(entry.keyblock,
                                         entry.keyType,
-                                        new Integer(entry.keyVersion));
+                                        entry.keyVersion);
                     keys.add(key);
                     if (DEBUG) {
                         System.out.println("Added key: " + entry.keyType +
diff -r d02b062bc827 src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
--- a/src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java	Fri Jun 20 09:57:18 2014 -0300
@@ -68,7 +68,7 @@
     public EncryptionKey getKey() {
         EncryptionKey key = new EncryptionKey(keyblock,
                                               keyType,
-                                              new Integer(keyVersion));
+                                              keyVersion);
         return key;
     }
 
diff -r d02b062bc827 src/share/classes/sun/security/pkcs/PKCS9Attribute.java
--- a/src/share/classes/sun/security/pkcs/PKCS9Attribute.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/pkcs/PKCS9Attribute.java	Fri Jun 20 09:57:18 2014 -0300
@@ -309,26 +309,26 @@
      */
     private static final Byte[][] PKCS9_VALUE_TAGS = {
         null,
-        {new Byte(DerValue.tag_IA5String)},   // EMailAddress
-        {new Byte(DerValue.tag_IA5String),   // UnstructuredName
-         new Byte(DerValue.tag_PrintableString)},
-        {new Byte(DerValue.tag_ObjectId)},    // ContentType
-        {new Byte(DerValue.tag_OctetString)}, // MessageDigest
-        {new Byte(DerValue.tag_UtcTime)},     // SigningTime
-        {new Byte(DerValue.tag_Sequence)},    // Countersignature
-        {new Byte(DerValue.tag_PrintableString),
-         new Byte(DerValue.tag_T61String)},   // ChallengePassword
-        {new Byte(DerValue.tag_PrintableString),
-         new Byte(DerValue.tag_T61String)},   // UnstructuredAddress
-        {new Byte(DerValue.tag_SetOf)},       // ExtendedCertificateAttributes
-        {new Byte(DerValue.tag_Sequence)},    // issuerAndSerialNumber
+        {DerValue.tag_IA5String},   // EMailAddress
+        {DerValue.tag_IA5String,   // UnstructuredName
+         DerValue.tag_PrintableString},
+        {DerValue.tag_ObjectId},    // ContentType
+        {DerValue.tag_OctetString}, // MessageDigest
+        {DerValue.tag_UtcTime},     // SigningTime
+        {DerValue.tag_Sequence},    // Countersignature
+        {DerValue.tag_PrintableString,
+         DerValue.tag_T61String},   // ChallengePassword
+        {DerValue.tag_PrintableString,
+         DerValue.tag_T61String},   // UnstructuredAddress
+        {DerValue.tag_SetOf},       // ExtendedCertificateAttributes
+        {DerValue.tag_Sequence},    // issuerAndSerialNumber
         null,
         null,
         null,
-        {new Byte(DerValue.tag_Sequence)},    // extensionRequest
-        {new Byte(DerValue.tag_Sequence)},    // SMIMECapability
-        {new Byte(DerValue.tag_Sequence)},    // SigningCertificate
-        {new Byte(DerValue.tag_Sequence)}     // SignatureTimestampToken
+        {DerValue.tag_Sequence},    // extensionRequest
+        {DerValue.tag_Sequence},    // SMIMECapability
+        {DerValue.tag_Sequence},    // SigningCertificate
+        {DerValue.tag_Sequence}     // SignatureTimestampToken
     };
 
     private static final Class[] VALUE_CLASSES = new Class[18];
@@ -511,7 +511,7 @@
         // check for illegal element tags
         Byte tag;
         for (int i=0; i < elems.length; i++) {
-            tag = new Byte(elems[i].tag);
+            tag = elems[i].tag;
 
             if (indexOf(tag, PKCS9_VALUE_TAGS[index], 0) == -1)
                 throwTagException(tag);
diff -r d02b062bc827 src/share/classes/sun/security/provider/ConfigFile.java
--- a/src/share/classes/sun/security/provider/ConfigFile.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/provider/ConfigFile.java	Fri Jun 20 09:57:18 2014 -0300
@@ -531,7 +531,7 @@
                 } else {
                     throw ioException(
                         "Configuration.Error.Line.line.expected.expect.found.value.",
-                        new Integer(linenum), expect, st.sval);
+                        linenum, expect, st.sval);
                 }
                 break;
 
@@ -541,7 +541,7 @@
                 } else {
                     throw ioException(
                         "Configuration.Error.Line.line.expected.expect.",
-                        new Integer(linenum), expect, st.sval);
+                        linenum, expect, st.sval);
                 }
                 break;
 
@@ -551,7 +551,7 @@
                 } else {
                     throw ioException(
                         "Configuration.Error.Line.line.expected.expect.",
-                        new Integer(linenum), expect, st.sval);
+                        linenum, expect, st.sval);
                 }
                 break;
 
@@ -561,7 +561,7 @@
                 } else {
                     throw ioException(
                         "Configuration.Error.Line.line.expected.expect.",
-                        new Integer(linenum), expect, st.sval);
+                        linenum, expect, st.sval);
                 }
                 break;
 
@@ -571,14 +571,14 @@
                 } else {
                     throw ioException(
                         "Configuration.Error.Line.line.expected.expect.",
-                        new Integer(linenum), expect, st.sval);
+                        linenum, expect, st.sval);
                 }
                 break;
 
             default:
                 throw ioException(
                     "Configuration.Error.Line.line.expected.expect.found.value.",
-                    new Integer(linenum), expect, st.sval);
+                    linenum, expect, st.sval);
             }
             return value;
         }
@@ -655,7 +655,7 @@
             if (s == null || s.length() == 0) {
                 throw ioException(
                     "Configuration.Error.Line.line.system.property.value.expanded.to.empty.value",
-                    new Integer(linenum), value);
+                    linenum, value);
             }
             return s;
         }
diff -r d02b062bc827 src/share/classes/sun/security/provider/PolicyParser.java
--- a/src/share/classes/sun/security/provider/PolicyParser.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/provider/PolicyParser.java	Fri Jun 20 09:57:18 2014 -0300
@@ -1405,7 +1405,7 @@
             super("line " + line + ": " + msg);
             MessageFormat form = new MessageFormat
                 (ResourcesMgr.getString("line.number.msg"));
-            Object[] source = {new Integer(line), msg};
+            Object[] source = {line, msg};
             i18nMessage = form.format(source);
         }
 
@@ -1414,7 +1414,7 @@
                 "], found [" + actual + "]");
             MessageFormat form = new MessageFormat(ResourcesMgr.getString
                 ("line.number.expected.expect.found.actual."));
-            Object[] source = {new Integer(line), expect, actual};
+            Object[] source = {line, expect, actual};
             i18nMessage = form.format(source);
         }
 
diff -r d02b062bc827 src/share/classes/sun/security/tools/keytool/Main.java
--- a/src/share/classes/sun/security/tools/keytool/Main.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/tools/keytool/Main.java	Fri Jun 20 09:57:18 2014 -0300
@@ -1531,7 +1531,7 @@
             if (verbose) {
                 MessageFormat form = new MessageFormat(rb.getString
                     ("Generated.keysize.bit.keyAlgName.secret.key"));
-                Object[] source = {new Integer(keysize),
+                Object[] source = {keysize,
                                     secKey.getAlgorithm()};
                 System.err.println(form.format(source));
             }
@@ -1626,10 +1626,10 @@
         if (verbose) {
             MessageFormat form = new MessageFormat(rb.getString
                 ("Generating.keysize.bit.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.validality.days.for"));
-            Object[] source = {new Integer(keysize),
+            Object[] source = {keysize,
                                 privKey.getAlgorithm(),
                                 chain[0].getSigAlgName(),
-                                new Long(validity),
+                                validity,
                                 x500Name};
             System.err.println(form.format(source));
         }
@@ -1787,7 +1787,7 @@
                     for (int i = 0; i < chain.length; i ++) {
                         MessageFormat form = new MessageFormat
                                 (rb.getString("Certificate.i.1."));
-                        Object[] source = {new Integer((i + 1))};
+                        Object[] source = {(i + 1)};
                         out.println(form.format(source));
                         if (verbose && (chain[i] instanceof X509Certificate)) {
                             printX509Cert((X509Certificate)(chain[i]), out);
@@ -2062,7 +2062,7 @@
                         ("Your.keystore.contains.keyStore.size.entry")) :
                 new MessageFormat(rb.getString
                         ("Your.keystore.contains.keyStore.size.entries"));
-        Object[] source = {new Integer(keyStore.size())};
+        Object[] source = {keyStore.size()};
         out.println(form.format(source));
         out.println();
 
@@ -2334,7 +2334,7 @@
             if (certs.length > 1) {
                 MessageFormat form = new MessageFormat
                         (rb.getString("Certificate.i.1."));
-                Object[] source = {new Integer(i + 1)};
+                Object[] source = {i + 1};
                 out.println(form.format(source));
             }
             if (rfc)
diff -r d02b062bc827 src/share/classes/sun/security/util/DerIndefLenConverter.java
--- a/src/share/classes/sun/security/util/DerIndefLenConverter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/util/DerIndefLenConverter.java	Fri Jun 20 09:57:18 2014 -0300
@@ -150,7 +150,7 @@
             return curLen;
         int lenByte = data[dataPos++] & 0xff;
         if (isIndefinite(lenByte)) {
-            ndefsList.add(new Integer(dataPos));
+            ndefsList.add(dataPos);
             unresolved++;
             return curLen;
         }
diff -r d02b062bc827 src/share/classes/sun/security/x509/AVA.java
--- a/src/share/classes/sun/security/x509/AVA.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/x509/AVA.java	Fri Jun 20 09:57:18 2014 -0300
@@ -517,7 +517,7 @@
             if (hexDigits.indexOf(Character.toUpperCase((char)c2)) >= 0) {
                 int hi = Character.digit((char)c1, 16);
                 int lo = Character.digit((char)c2, 16);
-                return new Byte((byte)((hi<<4) + lo));
+                return (byte)((hi<<4) + lo);
             } else {
                 throw new IOException
                         ("escaped hex value must include two valid digits");
diff -r d02b062bc827 src/share/classes/sun/security/x509/CRLReasonCodeExtension.java
--- a/src/share/classes/sun/security/x509/CRLReasonCodeExtension.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/x509/CRLReasonCodeExtension.java	Fri Jun 20 09:57:18 2014 -0300
@@ -125,7 +125,7 @@
      */
     public Integer get(String name) throws IOException {
         if (name.equalsIgnoreCase(REASON)) {
-            return new Integer(reasonCode);
+            return reasonCode;
         } else {
             throw new IOException
                 ("Name not supported by CRLReasonCodeExtension");
diff -r d02b062bc827 src/share/classes/sun/security/x509/CertificateVersion.java
--- a/src/share/classes/sun/security/x509/CertificateVersion.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/x509/CertificateVersion.java	Fri Jun 20 09:57:18 2014 -0300
@@ -193,7 +193,7 @@
      */
     public Integer get(String name) throws IOException {
         if (name.equalsIgnoreCase(VERSION)) {
-            return(new Integer(getVersion()));
+            return(getVersion());
         } else {
             throw new IOException("Attribute name not recognized by " +
                                   "CertAttrSet: CertificateVersion.");
diff -r d02b062bc827 src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java
--- a/src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java	Fri Jun 20 09:57:18 2014 -0300
@@ -217,7 +217,7 @@
      */
     public Integer get(String name) throws IOException {
         if (name.equalsIgnoreCase(SKIP_CERTS))
-            return (new Integer(skipCerts));
+            return (skipCerts);
         else
             throw new IOException("Attribute name not recognized by " +
                                   "CertAttrSet:InhibitAnyPolicy.");
diff -r d02b062bc827 src/share/classes/sun/security/x509/PolicyConstraintsExtension.java
--- a/src/share/classes/sun/security/x509/PolicyConstraintsExtension.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/security/x509/PolicyConstraintsExtension.java	Fri Jun 20 09:57:18 2014 -0300
@@ -233,9 +233,9 @@
      */
     public Integer get(String name) throws IOException {
         if (name.equalsIgnoreCase(REQUIRE)) {
-            return new Integer(require);
+            return require;
         } else if (name.equalsIgnoreCase(INHIBIT)) {
-            return new Integer(inhibit);
+            return inhibit;
         } else {
           throw new IOException("Attribute name not recognized by " +
                                 "CertAttrSet:PolicyConstraints.");
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/rmi/rmic/RMIGenerator.java
--- a/src/share/classes/sun/rmi/rmic/RMIGenerator.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/rmi/rmic/RMIGenerator.java	Fri Jun 20 09:57:18 2014 -0300
@@ -63,9 +63,9 @@
 
     private static final Hashtable versionOptions = new Hashtable<>();
     static {
-        versionOptions.put("-v1.1", new Integer(STUB_VERSION_1_1));
-        versionOptions.put("-vcompat", new Integer(STUB_VERSION_FAT));
-        versionOptions.put("-v1.2", new Integer(STUB_VERSION_1_2));
+        versionOptions.put("-v1.1", STUB_VERSION_1_1);
+        versionOptions.put("-vcompat", STUB_VERSION_FAT);
+        versionOptions.put("-v1.2", STUB_VERSION_1_2);
     }
 
     /**
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/print/ServiceDialog.java
--- a/src/share/classes/sun/print/ServiceDialog.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/print/ServiceDialog.java	Fri Jun 20 09:57:18 2014 -0300
@@ -1017,8 +1017,8 @@
             format.setParseIntegerOnly(true);
             format.setDecimalSeparatorAlwaysShown(false);
             NumberFormatter nf = new NumberFormatter(format);
-            nf.setMinimum(new Integer(1));
-            nf.setMaximum(new Integer(Integer.MAX_VALUE));
+            nf.setMinimum(1);
+            nf.setMaximum(Integer.MAX_VALUE);
             nf.setAllowsInvalid(true);
             nf.setCommitsOnValidEdit(true);
             tfRangeFrom = new JFormattedTextField(nf);
@@ -1110,12 +1110,12 @@
 
             if (min < 1) {
                 min = 1;
-                tfRangeFrom.setValue(new Integer(1));
+                tfRangeFrom.setValue(1);
             }
 
             if (max < min) {
                 max = min;
-                tfRangeTo.setValue(new Integer(min));
+                tfRangeTo.setValue(min);
             }
 
             PageRanges pr = new PageRanges(min, max);
@@ -1165,8 +1165,8 @@
             } else { // RANGE
                 rbPages.setSelected(true);
             }
-            tfRangeFrom.setValue(new Integer(min));
-            tfRangeTo.setValue(new Integer(max));
+            tfRangeFrom.setValue(min);
+            tfRangeTo.setValue(max);
             rbAll.setEnabled(prSupported);
             rbPages.setEnabled(prSupported);
             setupRangeWidgets();
@@ -1275,14 +1275,14 @@
                 min = 1;
                 max = Integer.MAX_VALUE;
             }
-            snModel.setMinimum(new Integer(min));
-            snModel.setMaximum(new Integer(max));
+            snModel.setMinimum(min);
+            snModel.setMaximum(max);
 
             int value = cp.getValue();
             if ((value < min) || (value > max)) {
                 value = min;
             }
-            snModel.setValue(new Integer(value));
+            snModel.setValue(value);
 
             // setup Collate checkbox
             if (psCurrent.isAttributeCategorySupported(scCategory)) {
@@ -2763,7 +2763,7 @@
             if ((value < 1) || (value > 100)) {
                 value = 1;
             }
-            snModel.setValue(new Integer(value));
+            snModel.setValue(value);
             lblPriority.setEnabled(jpSupported);
             spinPriority.setEnabled(jpSupported);
 
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/nio/ch/Util.java
--- a/src/share/classes/sun/nio/ch/Util.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/nio/ch/Util.java	Fri Jun 20 09:57:18 2014 -0300
@@ -328,8 +328,8 @@
             initDBBConstructor();
         try {
             dbb = (MappedByteBuffer)directByteBufferConstructor.newInstance(
-              new Object[] { new Integer(size),
-                             new Long(addr),
+              new Object[] { size,
+                             addr,
                              fd,
                              unmapper });
         } catch (InstantiationException |
@@ -373,8 +373,8 @@
             initDBBRConstructor();
         try {
             dbb = (MappedByteBuffer)directByteBufferRConstructor.newInstance(
-              new Object[] { new Integer(size),
-                             new Long(addr),
+              new Object[] { size,
+                             addr,
                              fd,
                              unmapper });
         } catch (InstantiationException |
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/net/NetProperties.java
--- a/src/share/classes/sun/net/NetProperties.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/net/NetProperties.java	Fri Jun 20 09:57:18 2014 -0300
@@ -123,7 +123,7 @@
             } catch (NumberFormatException ex) {
             }
         }
-        return new Integer(defval);
+        return defval;
     }
 
     /**
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/misc/ProxyGenerator.java
--- a/src/share/classes/sun/misc/ProxyGenerator.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/misc/ProxyGenerator.java	Fri Jun 20 09:57:18 2014 -0300
@@ -1743,7 +1743,7 @@
          * Get or assign the index for a CONSTANT_Integer entry.
          */
         public short getInteger(int i) {
-            return getValue(new Integer(i));
+            return getValue(i);
         }
 
         /**
@@ -1885,7 +1885,7 @@
                         "late constant pool addition: " + key);
                 }
                 short i = addEntry(new ValueEntry(key));
-                map.put(key, new Short(i));
+                map.put(key, i);
                 return i;
             }
         }
@@ -1903,7 +1903,7 @@
                     throw new InternalError("late constant pool addition");
                 }
                 short i = addEntry(e);
-                map.put(e, new Short(i));
+                map.put(e, i);
                 return i;
             }
         }
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/management/GcInfoCompositeData.java
--- a/src/share/classes/sun/management/GcInfoCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/GcInfoCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -105,10 +105,10 @@
 
         try {
             baseGcInfoItemValues = new Object[] {
-                new Long(info.getId()),
-                new Long(info.getStartTime()),
-                new Long(info.getEndTime()),
-                new Long(info.getDuration()),
+                info.getId(),
+                info.getStartTime(),
+                info.getEndTime(),
+                info.getDuration(),
                 memoryUsageMapType.toOpenTypeData(info.getMemoryUsageBeforeGc()),
                 memoryUsageMapType.toOpenTypeData(info.getMemoryUsageAfterGc()),
             };
diff -r d02b062bc827 src/share/classes/sun/management/HotspotThread.java
--- a/src/share/classes/sun/management/HotspotThread.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/HotspotThread.java	Fri Jun 20 09:57:18 2014 -0300
@@ -60,7 +60,7 @@
         int numThreads = getInternalThreadTimes0(names, times);
         Map result = new HashMap<>(numThreads);
         for (int i = 0; i < numThreads; i++) {
-            result.put(names[i], new Long(times[i]));
+            result.put(names[i], times[i]);
         }
         return result;
     }
diff -r d02b062bc827 src/share/classes/sun/management/LockInfoCompositeData.java
--- a/src/share/classes/sun/management/LockInfoCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/LockInfoCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -61,7 +61,7 @@
         // lockInfoItemNames!
         final Object[] lockInfoItemValues = {
             new String(lock.getClassName()),
-            new Integer(lock.getIdentityHashCode()),
+            lock.getIdentityHashCode(),
         };
 
         try {
diff -r d02b062bc827 src/share/classes/sun/management/MemoryNotifInfoCompositeData.java
--- a/src/share/classes/sun/management/MemoryNotifInfoCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/MemoryNotifInfoCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -60,7 +60,7 @@
         final Object[] memoryNotifInfoItemValues = {
             memoryNotifInfo.getPoolName(),
             MemoryUsageCompositeData.toCompositeData(memoryNotifInfo.getUsage()),
-            new Long(memoryNotifInfo.getCount()),
+            memoryNotifInfo.getCount(),
         };
 
         try {
diff -r d02b062bc827 src/share/classes/sun/management/MemoryUsageCompositeData.java
--- a/src/share/classes/sun/management/MemoryUsageCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/MemoryUsageCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -56,10 +56,10 @@
         // CONTENTS OF THIS ARRAY MUST BE SYNCHRONIZED WITH
         // memoryUsageItemNames!
         final Object[] memoryUsageItemValues = {
-            new Long(usage.getInit()),
-            new Long(usage.getUsed()),
-            new Long(usage.getCommitted()),
-            new Long(usage.getMax()),
+            usage.getInit(),
+            usage.getUsed(),
+            usage.getCommitted(),
+            usage.getMax(),
         };
 
         try {
diff -r d02b062bc827 src/share/classes/sun/management/MonitorInfoCompositeData.java
--- a/src/share/classes/sun/management/MonitorInfoCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/MonitorInfoCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -69,7 +69,7 @@
                                                toCompositeData(ste)
                                          : null);
             } else if (item.equals(LOCKED_STACK_DEPTH)) {
-                values[i] = new Integer(lock.getLockedStackDepth());
+                values[i] = lock.getLockedStackDepth();
             } else {
                 values[i] = li.get(item);
             }
diff -r d02b062bc827 src/share/classes/sun/management/StackTraceElementCompositeData.java
--- a/src/share/classes/sun/management/StackTraceElementCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/StackTraceElementCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -67,7 +67,7 @@
             ste.getClassName(),
             ste.getMethodName(),
             ste.getFileName(),
-            new Integer(ste.getLineNumber()),
+            ste.getLineNumber(),
             ste.isNativeMethod(),
         };
         try {
diff -r d02b062bc827 src/share/classes/sun/management/ThreadInfoCompositeData.java
--- a/src/share/classes/sun/management/ThreadInfoCompositeData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/ThreadInfoCompositeData.java	Fri Jun 20 09:57:18 2014 -0300
@@ -108,16 +108,16 @@
         // CONTENTS OF THIS ARRAY MUST BE SYNCHRONIZED WITH
         // threadInfoItemNames!
         final Object[] threadInfoItemValues = {
-            new Long(threadInfo.getThreadId()),
+            threadInfo.getThreadId(),
             threadInfo.getThreadName(),
             threadInfo.getThreadState().name(),
-            new Long(threadInfo.getBlockedTime()),
-            new Long(threadInfo.getBlockedCount()),
-            new Long(threadInfo.getWaitedTime()),
-            new Long(threadInfo.getWaitedCount()),
+            threadInfo.getBlockedTime(),
+            threadInfo.getBlockedCount(),
+            threadInfo.getWaitedTime(),
+            threadInfo.getWaitedCount(),
             lockInfoData,
             threadInfo.getLockName(),
-            new Long(threadInfo.getLockOwnerId()),
+            threadInfo.getLockOwnerId(),
             threadInfo.getLockOwnerName(),
             stackTraceData,
                 threadInfo.isSuspended(),
diff -r d02b062bc827 src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java
--- a/src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/counter/perf/LongCounterSnapshot.java	Fri Jun 20 09:57:18 2014 -0300
@@ -43,7 +43,7 @@
     }
 
     public Object getValue() {
-        return new Long(value);
+        return Long.valueOf(value);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/counter/perf/PerfLongCounter.java
--- a/src/share/classes/sun/management/counter/perf/PerfLongCounter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/counter/perf/PerfLongCounter.java	Fri Jun 20 09:57:18 2014 -0300
@@ -42,7 +42,7 @@
     }
 
     public Object getValue() {
-        return new Long(lb.get(0));
+        return Long.valueOf(lb.get(0));
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/jdp/JdpController.java
--- a/src/share/classes/sun/management/jdp/JdpController.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/jdp/JdpController.java	Fri Jun 20 09:57:18 2014 -0300
@@ -204,7 +204,7 @@
         packet.setRmiHostname(rmiHostname);
 
         // Set broadcast interval
-        packet.setBroadcastInterval(new Integer(pause).toString());
+        packet.setBroadcastInterval(Integer.valueOf(pause).toString());
 
         // Set process id
         Integer pid = getProcessId();
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmClassLoadingImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -129,21 +129,21 @@
      * Getter for the "JvmClassesUnloadedCount" variable.
      */
     public Long getJvmClassesUnloadedCount() throws SnmpStatusException {
-        return new Long(getClassLoadingMXBean().getUnloadedClassCount());
+        return getClassLoadingMXBean().getUnloadedClassCount();
     }
 
     /**
      * Getter for the "JvmClassesTotalLoadedCount" variable.
      */
     public Long getJvmClassesTotalLoadedCount() throws SnmpStatusException {
-        return new Long(getClassLoadingMXBean().getTotalLoadedClassCount());
+        return getClassLoadingMXBean().getTotalLoadedClassCount();
     }
 
     /**
      * Getter for the "JvmClassesLoadedCount" variable.
      */
     public Long getJvmClassesLoadedCount() throws SnmpStatusException {
-        return new Long(getClassLoadingMXBean().getLoadedClassCount());
+        return (long)getClassLoadingMXBean().getLoadedClassCount();
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmCompilationImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -115,7 +115,7 @@
             t = getCompilationMXBean().getTotalCompilationTime();
         else
             t = 0;
-        return new Long(t);
+        return t;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemGCEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -70,7 +70,7 @@
      */
     // Don't bother to uses the request contextual cache for this.
     public Long getJvmMemGCTimeMs() throws SnmpStatusException {
-        return new Long(gcm.getCollectionTime());
+        return gcm.getCollectionTime();
     }
 
     /**
@@ -78,14 +78,14 @@
      */
     // Don't bother to uses the request contextual cache for this.
     public Long getJvmMemGCCount() throws SnmpStatusException {
-        return new Long(gcm.getCollectionCount());
+        return gcm.getCollectionCount();
     }
 
     /**
      * Getter for the "JvmMemManagerIndex" variable.
      */
     public Integer getJvmMemManagerIndex() throws SnmpStatusException {
-        return new Integer(JvmMemManagerIndex);
+        return JvmMemManagerIndex;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -79,7 +79,7 @@
      * Getter for the "JvmMemManagerIndex" variable.
      */
     public Integer getJvmMemManagerIndex() throws SnmpStatusException {
-        return new Integer(JvmMemManagerIndex);
+        return JvmMemManagerIndex;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -92,14 +92,14 @@
      * Getter for the "JvmMemManagerIndex" variable.
      */
     public Integer getJvmMemManagerIndex() throws SnmpStatusException {
-        return new Integer(JvmMemManagerIndex);
+        return JvmMemManagerIndex;
     }
 
     /**
      * Getter for the "JvmMemPoolIndex" variable.
      */
     public Integer getJvmMemPoolIndex() throws SnmpStatusException {
-        return new Integer(JvmMemPoolIndex);
+        return JvmMemPoolIndex;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -191,7 +191,7 @@
      */
     public Long getJvmMemPoolMaxSize() throws SnmpStatusException {
         final long val = getMemoryUsage().getMax();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -200,7 +200,7 @@
      */
     public Long getJvmMemPoolUsed() throws SnmpStatusException {
         final long val = getMemoryUsage().getUsed();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -209,7 +209,7 @@
      */
     public Long getJvmMemPoolInitSize() throws SnmpStatusException {
         final long val = getMemoryUsage().getInit();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -218,7 +218,7 @@
      */
     public Long getJvmMemPoolCommitted() throws SnmpStatusException {
         final long val = getMemoryUsage().getCommitted();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -227,7 +227,7 @@
      */
     public Long getJvmMemPoolPeakMaxSize() throws SnmpStatusException {
         final long val = getPeakMemoryUsage().getMax();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -236,7 +236,7 @@
      */
     public Long getJvmMemPoolPeakUsed() throws SnmpStatusException {
         final long val = getPeakMemoryUsage().getUsed();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -245,7 +245,7 @@
      */
     public Long getJvmMemPoolPeakCommitted() throws SnmpStatusException {
         final long val = getPeakMemoryUsage().getCommitted();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -254,7 +254,7 @@
      */
     public Long getJvmMemPoolCollectMaxSize() throws SnmpStatusException {
         final long val = getCollectMemoryUsage().getMax();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -263,7 +263,7 @@
      */
     public Long getJvmMemPoolCollectUsed() throws SnmpStatusException {
         final long val = getCollectMemoryUsage().getUsed();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -272,7 +272,7 @@
      */
     public Long getJvmMemPoolCollectCommitted() throws SnmpStatusException {
         final long val = getCollectMemoryUsage().getCommitted();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -283,7 +283,7 @@
         if (!pool.isUsageThresholdSupported())
             return JvmMemoryImpl.Long0;
         final long val = pool.getUsageThreshold();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -334,7 +334,7 @@
         if (!pool.isUsageThresholdSupported())
             return JvmMemoryImpl.Long0;
         final long val = pool.getUsageThresholdCount();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -345,7 +345,7 @@
         if (!pool.isCollectionUsageThresholdSupported())
             return JvmMemoryImpl.Long0;
         final long val = pool.getCollectionUsageThreshold();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -399,7 +399,7 @@
         if (!pool.isCollectionUsageThresholdSupported())
             return JvmMemoryImpl.Long0;
         final long val = pool.getCollectionUsageThresholdCount();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return JvmMemoryImpl.Long0;
     }
 
@@ -430,7 +430,7 @@
      * Getter for the "JvmMemPoolIndex" variable.
      */
     public Integer getJvmMemPoolIndex() throws SnmpStatusException {
-        return new Integer(jvmMemPoolIndex);
+        return jvmMemPoolIndex;
     }
 
 
@@ -450,7 +450,7 @@
      */
     public synchronized Long getJvmMemPoolPeakReset()
         throws SnmpStatusException {
-        return new Long(jvmMemPoolPeakReset);
+        return jvmMemPoolPeakReset;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -222,7 +222,7 @@
         }
     }
 
-    static final Long Long0 = new Long(0);
+    static final Long Long0 = 0L;
 
     /**
      * Getter for the "JvmMemoryNonHeapMaxSize" variable.
@@ -230,7 +230,7 @@
     public Long getJvmMemoryNonHeapMaxSize()
         throws SnmpStatusException {
         final long val = getNonHeapMemoryUsage().getMax();
-        if (val > -1) return  new Long(val);
+        if (val > -1) return  val;
         else return Long0;
     }
 
@@ -239,7 +239,7 @@
      */
     public Long getJvmMemoryNonHeapCommitted() throws SnmpStatusException {
         final long val = getNonHeapMemoryUsage().getCommitted();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -248,7 +248,7 @@
      */
     public Long getJvmMemoryNonHeapUsed() throws SnmpStatusException {
         final long val = getNonHeapMemoryUsage().getUsed();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -257,7 +257,7 @@
      */
     public Long getJvmMemoryNonHeapInitSize() throws SnmpStatusException {
         final long val = getNonHeapMemoryUsage().getInit();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -266,7 +266,7 @@
      */
     public Long getJvmMemoryHeapMaxSize() throws SnmpStatusException {
         final long val = getHeapMemoryUsage().getMax();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -320,7 +320,7 @@
      */
     public Long getJvmMemoryHeapCommitted() throws SnmpStatusException {
         final long val = getHeapMemoryUsage().getCommitted();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -359,7 +359,7 @@
      */
     public Long getJvmMemoryHeapUsed() throws SnmpStatusException {
         final long val = getHeapMemoryUsage().getUsed();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -368,7 +368,7 @@
      */
     public Long getJvmMemoryHeapInitSize() throws SnmpStatusException {
         final long val = getHeapMemoryUsage().getInit();
-        if (val > -1) return new Long(val);
+        if (val > -1) return val;
         else return Long0;
     }
 
@@ -380,11 +380,11 @@
         final long val = ManagementFactory.getMemoryMXBean().
             getObjectPendingFinalizationCount();
 
-        if (val > -1) return new Long((int)val);
+        if (val > -1) return val;
 
         // Should never happen... but stay safe all the same.
         //
-        else return new Long(0);
+        else return 0L;
     }
 
     static final MibLogger log = new MibLogger(JvmMemoryImpl.class);
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -82,7 +82,7 @@
      * Getter for the "JvmRTProcessorCount" variable.
      */
     public Integer getJvmOSProcessorCount() throws SnmpStatusException {
-        return new Integer(getOSMBean().getAvailableProcessors());
+        return getOSMBean().getAvailableProcessors();
 
     }
 
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -72,7 +72,7 @@
      * Getter for the "JvmRTBootClassPathIndex" variable.
      */
     public Integer getJvmRTBootClassPathIndex() throws SnmpStatusException {
-        return new Integer(index);
+        return index;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -71,7 +71,7 @@
      * Getter for the "JvmRTClassPathIndex" variable.
      */
     public Integer getJvmRTClassPathIndex() throws SnmpStatusException {
-        return new Integer(index);
+        return index;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -71,7 +71,7 @@
      * Getter for the "JvmRTInputArgsIndex" variable.
      */
     public Integer getJvmRTInputArgsIndex() throws SnmpStatusException {
-        return new Integer(index);
+        return index;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -71,7 +71,7 @@
      * Getter for the "JvmRTLibraryPathIndex" variable.
      */
     public Integer getJvmRTLibraryPathIndex() throws SnmpStatusException {
-        return new Integer(index);
+        return index;
     }
 
 }
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -241,7 +241,7 @@
 
         final String[] args = getInputArguments(JvmContextFactory.
                                                 getUserData());
-        return new Integer(args.length);
+        return args.length;
     }
 
     /**
@@ -259,14 +259,14 @@
      * Getter for the "JvmRTUptimeMs" variable.
      */
     public Long getJvmRTUptimeMs() throws SnmpStatusException {
-        return new Long(getRuntimeMXBean().getUptime());
+        return getRuntimeMXBean().getUptime();
     }
 
     /**
      * Getter for the "JvmRTStartTimeMs" variable.
      */
     public Long getJvmRTStartTimeMs() throws SnmpStatusException {
-        return new Long(getRuntimeMXBean().getStartTime());
+        return getRuntimeMXBean().getStartTime();
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -139,7 +139,7 @@
                           "Unexpected exception: " + r);
                 log.debug("getJvmThreadInstState",r);
             }
-            Byte[] result = { new Byte(bitmap[0]), new Byte(bitmap[1]) };
+			Byte[] result = { bitmap[0], bitmap[1] };
             return result;
         }
     }
@@ -231,7 +231,7 @@
             log.debug("getJvmThreadInstCpuTimeNs",
                       "Operation not supported: " + e);
         }
-        return new Long(l);
+        return l;
     }
 
     /**
@@ -248,14 +248,14 @@
             //Monitoring is disabled
             if(l == -1) l = 0;
         }
-        return new Long(l);
+        return l;
     }
 
     /**
      * Getter for the "JvmThreadInstBlockCount" variable.
      */
     public Long getJvmThreadInstBlockCount() throws SnmpStatusException {
-        return new Long(info.getBlockedCount());
+        return info.getBlockedCount();
     }
 
     /**
@@ -272,14 +272,14 @@
             //Monitoring is disabled
             if(l == -1) l = 0;
         }
-        return new Long(l);
+        return l;
     }
 
     /**
      * Getter for the "JvmThreadInstWaitCount" variable.
      */
     public Long getJvmThreadInstWaitCount() throws SnmpStatusException {
-        return new Long(info.getWaitedCount());
+        return info.getWaitedCount();
     }
 
     /**
@@ -294,7 +294,7 @@
      * Getter for the "JvmThreadInstId" variable.
      */
     public Long getJvmThreadInstId() throws SnmpStatusException {
-        return new Long(info.getThreadId());
+        return info.getThreadId();
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java
--- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadingImpl.java	Fri Jun 20 09:57:18 2014 -0300
@@ -303,28 +303,28 @@
      * Getter for the "JvmThreadTotalStartedCount" variable.
      */
     public Long getJvmThreadTotalStartedCount() throws SnmpStatusException {
-        return new Long(getThreadMXBean().getTotalStartedThreadCount());
+        return getThreadMXBean().getTotalStartedThreadCount();
     }
 
     /**
      * Getter for the "JvmThreadPeakCount" variable.
      */
     public Long getJvmThreadPeakCount() throws SnmpStatusException {
-        return  new Long(getThreadMXBean().getPeakThreadCount());
+        return  (long)getThreadMXBean().getPeakThreadCount();
     }
 
     /**
      * Getter for the "JvmThreadDaemonCount" variable.
      */
     public Long getJvmThreadDaemonCount() throws SnmpStatusException {
-        return new Long(getThreadMXBean().getDaemonThreadCount());
+        return (long)getThreadMXBean().getDaemonThreadCount();
     }
 
     /**
      * Getter for the "JvmThreadCount" variable.
      */
     public Long getJvmThreadCount() throws SnmpStatusException {
-        return new Long(getThreadMXBean().getThreadCount());
+        return (long)getThreadMXBean().getThreadCount();
     }
 
    /**
@@ -332,7 +332,7 @@
      */
     public synchronized Long getJvmThreadPeakCountReset()
         throws SnmpStatusException {
-        return new Long(jvmThreadPeakCountReset);
+        return jvmThreadPeakCountReset;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "verbose");
-        intTable.put(new Integer(1), "silent");
-        stringTable.put("verbose", new Integer(2));
-        stringTable.put("silent", new Integer(1));
+        intTable.put(2, "verbose");
+        intTable.put(1, "silent");
+        stringTable.put("verbose", 2);
+        stringTable.put("silent", 1);
     }
 
     public EnumJvmClassesVerboseLevel(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "supported");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("supported", new Integer(2));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(2, "supported");
+        intTable.put(1, "unsupported");
+        stringTable.put("supported", 2);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmJITCompilerTimeMonitoring(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java	Fri Jun 20 09:57:18 2014 -0300
@@ -50,10 +50,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "valid");
-        intTable.put(new Integer(1), "invalid");
-        stringTable.put("valid", new Integer(2));
-        stringTable.put("invalid", new Integer(1));
+        intTable.put(2, "valid");
+        intTable.put(1, "invalid");
+        stringTable.put("valid", 2);
+        stringTable.put("invalid", 1);
     }
 
     public EnumJvmMemManagerState(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "supported");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("supported", new Integer(2));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(2, "supported");
+        intTable.put(1, "unsupported");
+        stringTable.put("supported", 2);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmMemPoolCollectThreshdSupport(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "valid");
-        intTable.put(new Integer(1), "invalid");
-        stringTable.put("valid", new Integer(2));
-        stringTable.put("invalid", new Integer(1));
+        intTable.put(2, "valid");
+        intTable.put(1, "invalid");
+        stringTable.put("valid", 2);
+        stringTable.put("invalid", 1);
     }
 
     public EnumJvmMemPoolState(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "supported");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("supported", new Integer(2));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(2, "supported");
+        intTable.put(1, "unsupported");
+        stringTable.put("supported", 2);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmMemPoolThreshdSupport(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "heap");
-        intTable.put(new Integer(1), "nonheap");
-        stringTable.put("heap", new Integer(2));
-        stringTable.put("nonheap", new Integer(1));
+        intTable.put(2, "heap");
+        intTable.put(1, "nonheap");
+        stringTable.put("heap", 2);
+        stringTable.put("nonheap", 1);
     }
 
     public EnumJvmMemPoolType(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,16 +49,16 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "supported");
-        intTable.put(new Integer(5), "failed");
-        intTable.put(new Integer(4), "started");
-        intTable.put(new Integer(1), "unsupported");
-        intTable.put(new Integer(3), "start");
-        stringTable.put("supported", new Integer(2));
-        stringTable.put("failed", new Integer(5));
-        stringTable.put("started", new Integer(4));
-        stringTable.put("unsupported", new Integer(1));
-        stringTable.put("start", new Integer(3));
+        intTable.put(2, "supported");
+        intTable.put(5, "failed");
+        intTable.put(4, "started");
+        intTable.put(1, "unsupported");
+        intTable.put(3, "start");
+        stringTable.put("supported", 2);
+        stringTable.put("failed", 5);
+        stringTable.put("started", 4);
+        stringTable.put("unsupported", 1);
+        stringTable.put("start", 3);
     }
 
     public EnumJvmMemoryGCCall(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "verbose");
-        intTable.put(new Integer(1), "silent");
-        stringTable.put("verbose", new Integer(2));
-        stringTable.put("silent", new Integer(1));
+        intTable.put(2, "verbose");
+        intTable.put(1, "silent");
+        stringTable.put("verbose", 2);
+        stringTable.put("silent", 1);
     }
 
     public EnumJvmMemoryGCVerboseLevel(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,10 +49,10 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(2), "supported");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("supported", new Integer(2));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(2, "supported");
+        intTable.put(1, "unsupported");
+        stringTable.put("supported", 2);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmRTBootClassPathSupport(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,12 +49,12 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(3), "enabled");
-        intTable.put(new Integer(4), "disabled");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("enabled", new Integer(3));
-        stringTable.put("disabled", new Integer(4));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(3, "enabled");
+        intTable.put(4, "disabled");
+        intTable.put(1, "unsupported");
+        stringTable.put("enabled", 3);
+        stringTable.put("disabled", 4);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmThreadContentionMonitoring(int valueIndex) throws IllegalArgumentException {
diff -r d02b062bc827 src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java
--- a/src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java	Fri Jun 20 09:57:18 2014 -0300
@@ -49,12 +49,12 @@
     protected static Hashtable stringTable =
             new Hashtable<>();
     static  {
-        intTable.put(new Integer(3), "enabled");
-        intTable.put(new Integer(4), "disabled");
-        intTable.put(new Integer(1), "unsupported");
-        stringTable.put("enabled", new Integer(3));
-        stringTable.put("disabled", new Integer(4));
-        stringTable.put("unsupported", new Integer(1));
+        intTable.put(3, "enabled");
+        intTable.put(4, "disabled");
+        intTable.put(1, "unsupported");
+        stringTable.put("enabled", 3);
+        stringTable.put("disabled", 4);
+        stringTable.put("unsupported", 1);
     }
 
     public EnumJvmThreadCpuTimeMonitoring(int valueIndex) throws IllegalArgumentException {
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java
--- a/src/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java	Fri Jun 20 09:57:17 2014 -0300
@@ -174,9 +174,8 @@
                     Integer.TYPE
             });
 
-            impl = (PerfDataBufferImpl)cons.newInstance(new Object[] {
-                     bb, new Integer(lvmid)
-            });
+			impl = (PerfDataBufferImpl) cons.newInstance(new Object[] { bb,
+					lvmid });
 
         } catch (ClassNotFoundException e) {
             // from Class.forName();
diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java
--- a/src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java	Fri Jun 20 09:57:17 2014 -0300
@@ -67,7 +67,7 @@
      *                   return type is guaranteed to be of type Integer.
      */
     public Object getValue() {
-        return new Integer(ib.get(0));
+        return ib.get(0);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java
--- a/src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java	Fri Jun 20 09:57:17 2014 -0300
@@ -66,7 +66,7 @@
      *                  return type is guaranteed to be of type Long.
      */
     public Object getValue() {
-        return new Long(lb.get(0));
+        return Long.valueOf(lb.get(0));
     }
 
     /**
diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java
--- a/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java	Fri Jun 20 09:57:17 2014 -0300
@@ -156,8 +156,7 @@
                 if (files != null) {
                     for (int j = 0; j < files.length; j++) {
                         if (files[j].isFile() && files[j].canRead()) {
-                            jvmSet.add(new Integer(
-                                    PerfDataFile.getLocalVmId(files[j])));
+							jvmSet.add(PerfDataFile.getLocalVmId(files[j]));
                         }
                     }
                 }
@@ -175,8 +174,7 @@
             if (files != null) {
                 for (int j = 0; j < files.length; j++) {
                     if (files[j].isFile() && files[j].canRead()) {
-                        jvmSet.add(new Integer(
-                                PerfDataFile.getLocalVmId(files[j])));
+                        jvmSet.add(PerfDataFile.getLocalVmId(files[j]));
                     }
                 }
             }
@@ -187,8 +185,7 @@
         if (files != null) {
             for (int j = 0; j < files.length; j++) {
                 if (files[j].isFile() && files[j].canRead()) {
-                    jvmSet.add(new Integer(
-                            PerfDataFile.getLocalVmId(files[j])));
+                    jvmSet.add(PerfDataFile.getLocalVmId(files[j]));
                 }
             }
         }
diff -r d02b062bc827 src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java
--- a/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java	Fri Jun 20 09:57:17 2014 -0300
@@ -106,7 +106,7 @@
         Set activeSet = new HashSet(active.length);
 
         for (int i = 0; i < active.length; i++) {
-            activeSet.add(new Integer(active[i]));
+            activeSet.add(active[i]);
         }
 
         return activeSet;
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/sun/java2d/SunGraphics2D.java
--- a/src/share/classes/sun/java2d/SunGraphics2D.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/sun/java2d/SunGraphics2D.java	Fri Jun 20 09:57:17 2014 -0300
@@ -1322,7 +1322,7 @@
             return SunHints.Value.get(SunHints.INTKEY_FRACTIONALMETRICS,
                                       fractionalMetricsHint);
         case SunHints.INTKEY_AATEXT_LCD_CONTRAST:
-            return new Integer(lcdTextContrast);
+            return lcdTextContrast;
         case SunHints.INTKEY_INTERPOLATION:
             switch (interpolationHint) {
             case SunHints.INTVAL_INTERPOLATION_NEAREST_NEIGHBOR:
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java	Fri Jun 20 09:57:17 2014 -0300
@@ -1857,8 +1857,7 @@
             v += 2;
             break;
         case 'B': // pointer to CONSTANT_Byte
-            av.visit(name,
-                    new Byte((byte) readInt(items[readUnsignedShort(v)])));
+            av.visit(name, (byte) readInt(items[readUnsignedShort(v)]));
             v += 2;
             break;
         case 'Z': // pointer to CONSTANT_Boolean
@@ -1868,13 +1867,11 @@
             v += 2;
             break;
         case 'S': // pointer to CONSTANT_Short
-            av.visit(name, new Short(
-                    (short) readInt(items[readUnsignedShort(v)])));
+            av.visit(name, (short) readInt(items[readUnsignedShort(v)]));
             v += 2;
             break;
         case 'C': // pointer to CONSTANT_Char
-            av.visit(name, new Character(
-                    (char) readInt(items[readUnsignedShort(v)])));
+            av.visit(name, (char) readInt(items[readUnsignedShort(v)]));
             v += 2;
             break;
         case 's': // pointer to CONSTANT_Utf8
@@ -2498,11 +2495,11 @@
         int index = items[item];
         switch (b[index - 1]) {
         case ClassWriter.INT:
-            return new Integer(readInt(index));
+            return readInt(index);
         case ClassWriter.FLOAT:
             return new Float(Float.intBitsToFloat(readInt(index)));
         case ClassWriter.LONG:
-            return new Long(readLong(index));
+            return Long.valueOf(readLong(index));
         case ClassWriter.DOUBLE:
             return new Double(Double.longBitsToDouble(readLong(index)));
         case ClassWriter.CLASS:
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java	Fri Jun 20 09:57:17 2014 -0300
@@ -175,13 +175,13 @@
      */
     int F_SAME1 = 4;
 
-    Integer TOP = new Integer(0);
-    Integer INTEGER = new Integer(1);
-    Integer FLOAT = new Integer(2);
-    Integer DOUBLE = new Integer(3);
-    Integer LONG = new Integer(4);
-    Integer NULL = new Integer(5);
-    Integer UNINITIALIZED_THIS = new Integer(6);
+    Integer TOP = 0;
+    Integer INTEGER = 1;
+    Integer FLOAT = 2;
+    Integer DOUBLE = 3;
+    Integer LONG = 4;
+    Integer NULL = 5;
+    Integer UNINITIALIZED_THIS = 6;
 
     // opcodes // visit method (- = idem)
 
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java	Fri Jun 20 09:57:17 2014 -0300
@@ -408,7 +408,7 @@
         } else if (value >= Short.MIN_VALUE && value <= Short.MAX_VALUE) {
             mv.visitIntInsn(Opcodes.SIPUSH, value);
         } else {
-            mv.visitLdcInsn(new Integer(value));
+            mv.visitLdcInsn(value);
         }
     }
 
@@ -422,7 +422,7 @@
         if (value == 0L || value == 1L) {
             mv.visitInsn(Opcodes.LCONST_0 + (int) value);
         } else {
-            mv.visitLdcInsn(new Long(value));
+            mv.visitLdcInsn(value);
         }
     }
 
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java	Fri Jun 20 09:57:17 2014 -0300
@@ -737,7 +737,7 @@
         } else if (cst >= Short.MIN_VALUE && cst <= Short.MAX_VALUE) {
             mv.visitIntInsn(Opcodes.SIPUSH, cst);
         } else {
-            mv.visitLdcInsn(new Integer(cst));
+            mv.visitLdcInsn(cst);
         }
     }
 
@@ -745,7 +745,7 @@
         if (cst == 0L || cst == 1L) {
             mv.visitInsn(Opcodes.LCONST_0 + (int) cst);
         } else {
-            mv.visitLdcInsn(new Long(cst));
+            mv.visitLdcInsn(cst);
         }
     }
 
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java	Fri Jun 20 09:57:17 2014 -0300
@@ -366,8 +366,7 @@
 
     protected void addSVUID(long svuid) {
         FieldVisitor fv = super.visitField(Opcodes.ACC_FINAL
-                + Opcodes.ACC_STATIC, "serialVersionUID", "J", null, new Long(
-                svuid));
+                + Opcodes.ACC_STATIC, "serialVersionUID", "J", null, svuid);
         if (fv != null) {
             fv.visitEnd();
         }
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java	Fri Jun 20 09:57:17 2014 -0300
@@ -110,7 +110,7 @@
                 : labels.length);
         if (keys != null) {
             for (int i = 0; i < keys.length; ++i) {
-                this.keys.add(new Integer(keys[i]));
+                this.keys.add(keys[i]);
             }
         }
         if (labels != null) {
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java	Fri Jun 20 09:57:17 2014 -0300
@@ -802,7 +802,7 @@
         if (labels.get(label) != null) {
             throw new IllegalArgumentException("Already visited label");
         }
-        labels.put(label, new Integer(insnCount));
+        labels.put(label, insnCount);
         super.visitLabel(label);
     }
 
diff -r d02b062bc827 src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java
--- a/src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java	Fri Jun 20 09:57:17 2014 -0300
@@ -732,7 +732,7 @@
         Textifier t = createTextifier();
         text.add(t.getText());
         text.add(visible ? ") // parameter " : ") // invisible, parameter ");
-        text.add(new Integer(parameter));
+        text.add(parameter);
         text.add("\n");
         return t;
     }
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/javax/swing/JInternalFrame.java
--- a/src/share/classes/javax/swing/JInternalFrame.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/JInternalFrame.java	Fri Jun 20 09:57:17 2014 -0300
@@ -2106,7 +2106,7 @@
             if (n == null) {
                 return false;
             }
-            setLayer(new Integer(n.intValue()));
+            setLayer(n.intValue());
             return true;
         }
 
diff -r d02b062bc827 src/share/classes/javax/swing/JLayeredPane.java
--- a/src/share/classes/javax/swing/JLayeredPane.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/JLayeredPane.java	Fri Jun 20 09:57:17 2014 -0300
@@ -295,7 +295,7 @@
         /// MAKE SURE THIS AND setLayer(Component c, int layer, int position)  are SYNCED
         Integer layerObj;
 
-        layerObj = new Integer(layer);
+        layerObj = layer;
         c.putClientProperty(LAYER_PROPERTY, layerObj);
     }
 
@@ -626,7 +626,7 @@
             layerObj = DRAG_LAYER;
             break;
         default:
-            layerObj = new Integer(layer);
+            layerObj = layer;
         }
         return layerObj;
     }
diff -r d02b062bc827 src/share/classes/javax/swing/JScrollBar.java
--- a/src/share/classes/javax/swing/JScrollBar.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/JScrollBar.java	Fri Jun 20 09:57:17 2014 -0300
@@ -327,7 +327,7 @@
         if (accessibleContext != null) {
             accessibleContext.firePropertyChange(
                     AccessibleContext.ACCESSIBLE_VALUE_PROPERTY,
-                    oldValue, new Integer(model.getValue()));
+                    oldValue, model.getValue());
         }
     }
 
@@ -928,7 +928,7 @@
          */
         public Number getMaximumAccessibleValue() {
             // TIGER - 4422362
-            return new Integer(model.getMaximum() - model.getExtent());
+            return model.getMaximum() - model.getExtent();
         }
 
     } // AccessibleJScrollBar
diff -r d02b062bc827 src/share/classes/javax/swing/filechooser/FileSystemView.java
--- a/src/share/classes/javax/swing/filechooser/FileSystemView.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/filechooser/FileSystemView.java	Fri Jun 20 09:57:17 2014 -0300
@@ -645,7 +645,7 @@
         int i = 1;
         while (newFolder.exists() && i < 100) {
             newFolder = createFileObject(containingDir, MessageFormat.format(
-                    newFolderNextString, new Integer(i)));
+                    newFolderNextString, i));
             i++;
         }
 
@@ -754,7 +754,7 @@
         int i = 2;
         while (newFolder.exists() && i < 100) {
             newFolder = createFileObject(containingDir, MessageFormat.format(
-                newFolderNextString, new Integer(i)));
+                newFolderNextString, i));
             i++;
         }
 
diff -r d02b062bc827 src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
--- a/src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java	Fri Jun 20 09:57:17 2014 -0300
@@ -455,10 +455,10 @@
         initResourceBundle(table);
 
         // *** Shared Integers
-        Integer fiveHundred = new Integer(500);
+        Integer fiveHundred = 500;
 
         // *** Shared Longs
-        Long oneThousand = new Long(1000);
+        Long oneThousand = 1000L;
 
         LazyValue dialogPlain12 = t ->
             new FontUIResource(Font.DIALOG, Font.PLAIN, 12);
@@ -673,7 +673,7 @@
         Object editorMargin = threeInsets;
 
         Object caretBlinkRate = fiveHundred;
-        Integer four = new Integer(4);
+        Integer four = 4;
 
         Object[] allAuditoryCues = new Object[] {
                 "CheckBoxMenuItem.commandSound",
@@ -1087,10 +1087,10 @@
             "Menu.margin", twoInsets,
             "Menu.checkIcon", menuItemCheckIcon,
             "Menu.arrowIcon", menuArrowIcon,
-            "Menu.menuPopupOffsetX", new Integer(0),
-            "Menu.menuPopupOffsetY", new Integer(0),
-            "Menu.submenuPopupOffsetX", new Integer(0),
-            "Menu.submenuPopupOffsetY", new Integer(0),
+            "Menu.menuPopupOffsetX", 0,
+            "Menu.menuPopupOffsetY", 0,
+            "Menu.submenuPopupOffsetX", 0,
+            "Menu.submenuPopupOffsetY", 0,
             "Menu.shortcutKeys", new int[]{
                 SwingUtilities2.getSystemMnemonicKeyMask()
             },
@@ -1188,10 +1188,10 @@
             "ProgressBar.selectionForeground", control,
             "ProgressBar.selectionBackground", textHighlight,
             "ProgressBar.border", progressBarBorder,
-            "ProgressBar.cellLength", new Integer(1),
+            "ProgressBar.cellLength", 1,
             "ProgressBar.cellSpacing", zero,
-            "ProgressBar.repaintInterval", new Integer(50),
-            "ProgressBar.cycleTime", new Integer(3000),
+            "ProgressBar.repaintInterval", 50,
+            "ProgressBar.cycleTime", 3000,
             "ProgressBar.horizontalSize", new DimensionUIResource(146, 12),
             "ProgressBar.verticalSize", new DimensionUIResource(12, 146),
 
@@ -1236,7 +1236,7 @@
                         "LEFT", "positiveUnitIncrement",
                      "KP_LEFT", "positiveUnitIncrement",
                  }),
-            "ScrollBar.width", new Integer(16),
+            "ScrollBar.width", 16,
 
             "ScrollPane.font", dialogPlain12,
             "ScrollPane.background", control,
@@ -1332,7 +1332,7 @@
             "SplitPane.shadow", controlShadow,
             "SplitPane.darkShadow", controlDkShadow,
             "SplitPane.border", splitPaneBorder,
-            "SplitPane.dividerSize", new Integer(7),
+            "SplitPane.dividerSize", 7,
             "SplitPaneDivider.border", splitPaneDividerBorder,
             "SplitPaneDivider.draggingColor", darkGray,
             "SplitPane.ancestorInputMap",
@@ -1377,7 +1377,7 @@
             "TabbedPane.selectedTabPadInsets", tabbedPaneTabPadInsets,
             "TabbedPane.tabAreaInsets", tabbedPaneTabAreaInsets,
             "TabbedPane.contentBorderInsets", tabbedPaneContentBorderInsets,
-            "TabbedPane.tabRunOverlay", new Integer(2),
+            "TabbedPane.tabRunOverlay", 2,
             "TabbedPane.tabsOpaque", Boolean.TRUE,
             "TabbedPane.contentOpaque", Boolean.TRUE,
             "TabbedPane.focusInputMap",
@@ -1737,9 +1737,9 @@
             "Tree.selectionBorderColor", black,
             "Tree.dropLineColor", controlShadow,
             "Tree.editorBorder", blackLineBorder,
-            "Tree.leftChildIndent", new Integer(7),
-            "Tree.rightChildIndent", new Integer(13),
-            "Tree.rowHeight", new Integer(16),
+            "Tree.leftChildIndent", 7,
+            "Tree.rightChildIndent", 13,
+            "Tree.rowHeight", 16,
             "Tree.scrollsOnExpand", Boolean.TRUE,
             "Tree.openIcon", SwingUtilities2.makeIcon(getClass(),
                                                       BasicLookAndFeel.class,
diff -r d02b062bc827 src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
--- a/src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java	Fri Jun 20 09:57:17 2014 -0300
@@ -633,7 +633,7 @@
         LazyValue toolBarBorder = t -> new MetalBorders.ToolBarBorder();
 
         LazyValue progressBarBorder = t ->
-            new BorderUIResource.LineBorderUIResource(controlDarkShadow, new Integer(1));
+            new BorderUIResource.LineBorderUIResource(controlDarkShadow, 1);
 
         LazyValue toolTipBorder = t ->
             new BorderUIResource.LineBorderUIResource(primaryControlDarkShadow);
@@ -851,8 +851,8 @@
             "Slider.foreground", primaryControlShadow,
             "Slider.focus", focusColor,
             "Slider.focusInsets", zeroInsets,
-            "Slider.trackWidth", new Integer( 7 ),
-            "Slider.majorTickLength", new Integer( 6 ),
+            "Slider.trackWidth", 7,
+            "Slider.majorTickLength", 6,
             "Slider.horizontalThumbIcon",(LazyValue) t -> MetalIconFactory.getHorizontalSliderThumbIcon(),
             "Slider.verticalThumbIcon",(LazyValue) t -> MetalIconFactory.getVerticalSliderThumbIcon(),
             "Slider.focusInputMap",
@@ -914,7 +914,7 @@
                     new MetalBorders.OptionDialogBorder(),
             "InternalFrame.paletteBorder",(LazyValue) t ->
                     new MetalBorders.PaletteBorder(),
-            "InternalFrame.paletteTitleHeight", new Integer(11),
+            "InternalFrame.paletteTitleHeight", 11,
             "InternalFrame.paletteCloseIcon",(LazyValue) t ->
                     new MetalIconFactory.PaletteCloseIcon(),
             "InternalFrame.closeIcon",
@@ -1067,7 +1067,7 @@
             "ScrollBar.thumb", primaryControlShadow,
             "ScrollBar.thumbShadow", primaryControlDarkShadow,
             "ScrollBar.thumbHighlight", primaryControl,
-            "ScrollBar.width", new Integer( 17 ),
+            "ScrollBar.width", 17,
             "ScrollBar.allowsAbsolutePositioning", Boolean.TRUE,
             "ScrollBar.ancestorInputMap",
                new UIDefaults.LazyInputMap(new Object[] {
@@ -1238,8 +1238,8 @@
             "Menu.borderPainted", Boolean.TRUE,
             "Menu.menuPopupOffsetX", zero,
             "Menu.menuPopupOffsetY", zero,
-            "Menu.submenuPopupOffsetX", new Integer(-4),
-            "Menu.submenuPopupOffsetY", new Integer(-3),
+            "Menu.submenuPopupOffsetX", -4,
+            "Menu.submenuPopupOffsetY", -3,
             "Menu.font", menuTextValue,
             "Menu.selectionForeground", menuSelectedForeground,
             "Menu.selectionBackground", menuSelectedBackground,
@@ -1354,7 +1354,7 @@
 
             // SplitPane
 
-            "SplitPane.dividerSize", new Integer(10),
+            "SplitPane.dividerSize", 10,
             "SplitPane.ancestorInputMap",
                new UIDefaults.LazyInputMap(new Object[] {
                         "UP", "negativeIncrement",
diff -r d02b062bc827 src/share/classes/javax/swing/plaf/synth/SynthParser.java
--- a/src/share/classes/javax/swing/plaf/synth/SynthParser.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/plaf/synth/SynthParser.java	Fri Jun 20 09:57:17 2014 -0300
@@ -763,7 +763,7 @@
                 break;
             case 4: // integer
                 try {
-                    value = new Integer(Integer.parseInt(aValue));
+                    value = Integer.parseInt(aValue);
                 } catch (NumberFormatException nfe) {
                     throw new SAXException(property + " invalid value");
                 }
diff -r d02b062bc827 src/share/classes/javax/swing/text/JTextComponent.java
--- a/src/share/classes/javax/swing/text/JTextComponent.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/text/JTextComponent.java	Fri Jun 20 09:57:17 2014 -0300
@@ -2554,8 +2554,7 @@
             int mark = e.getMark();
             if (caretPos != dot) {
                 // the caret moved
-                firePropertyChange(ACCESSIBLE_CARET_PROPERTY,
-                    new Integer(caretPos), new Integer(dot));
+				firePropertyChange(ACCESSIBLE_CARET_PROPERTY, caretPos, dot);
                 caretPos = dot;
 
                 try {
diff -r d02b062bc827 src/share/classes/javax/swing/text/html/CSS.java
--- a/src/share/classes/javax/swing/text/html/CSS.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/text/html/CSS.java	Fri Jun 20 09:57:17 2014 -0300
@@ -1748,13 +1748,13 @@
                 return Boolean.FALSE;
             } else if (key == StyleConstants.Alignment) {
                 if (svalue.equals("right")) {
-                    return new Integer(StyleConstants.ALIGN_RIGHT);
+                    return StyleConstants.ALIGN_RIGHT;
                 } else if (svalue.equals("center")) {
-                    return new Integer(StyleConstants.ALIGN_CENTER);
+                    return StyleConstants.ALIGN_CENTER;
                 } else if  (svalue.equals("justify")) {
-                    return new Integer(StyleConstants.ALIGN_JUSTIFIED);
+                    return StyleConstants.ALIGN_JUSTIFIED;
                 }
-                return new Integer(StyleConstants.ALIGN_LEFT);
+                return StyleConstants.ALIGN_LEFT;
             } else if (key == StyleConstants.StrikeThrough) {
                 if (svalue.indexOf("line-through") >= 0) {
                     return Boolean.TRUE;
diff -r d02b062bc827 src/share/classes/javax/swing/text/html/HTMLDocument.java
--- a/src/share/classes/javax/swing/text/html/HTMLDocument.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/text/html/HTMLDocument.java	Fri Jun 20 09:57:17 2014 -0300
@@ -623,7 +623,7 @@
      * @param n  the number of tokens to buffer
      */
     public void setTokenThreshold(int n) {
-        putProperty(TokenThreshold, new Integer(n));
+        putProperty(TokenThreshold, n);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/javax/swing/text/rtf/RTFGenerator.java
--- a/src/share/classes/javax/swing/text/rtf/RTFGenerator.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/swing/text/rtf/RTFGenerator.java	Fri Jun 20 09:57:17 2014 -0300
@@ -165,14 +165,14 @@
         foregroundColor = StyleConstants.getForeground(a);
         if (foregroundColor != null &&
             colorTable.get(foregroundColor) == null) {
-            colorTable.put(foregroundColor, new Integer(colorCount));
+            colorTable.put(foregroundColor, colorCount);
             colorCount ++;
         }
 
         backgroundColor = a.getAttribute(StyleConstants.Background);
         if (backgroundColor != null &&
             colorTable.get(backgroundColor) == null) {
-            colorTable.put(backgroundColor, new Integer(colorCount));
+            colorTable.put(backgroundColor, colorCount);
             colorCount ++;
         }
 
@@ -183,7 +183,7 @@
 
         if (fontName != null &&
             fontTable.get(fontName) == null) {
-            fontTable.put(fontName, new Integer(fontCount));
+            fontTable.put(fontName, fontCount);
             fontCount ++;
         }
     }
@@ -200,7 +200,7 @@
             Integer aNum = styleTable.get(a);
             if (aNum == null) {
                 styleCount = styleCount + 1;
-                aNum = new Integer(styleCount);
+                aNum = styleCount;
                 styleTable.put(a, aNum);
             }
         }
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/javax/sound/midi/MidiSystem.java
--- a/src/share/classes/javax/sound/midi/MidiSystem.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/sound/midi/MidiSystem.java	Fri Jun 20 09:57:17 2014 -0300
@@ -914,7 +914,7 @@
             MidiFileWriter writer = (MidiFileWriter) providers.get(i);
             int[] types = writer.getMidiFileTypes();
             for (int j = 0; j < types.length; j++ ) {
-                allTypes.add(new Integer(types[j]));
+                allTypes.add(types[j]);
             }
         }
         int resultTypes[] = new int[allTypes.size()];
@@ -968,7 +968,7 @@
             MidiFileWriter writer = (MidiFileWriter) providers.get(i);
             int[] types = writer.getMidiFileTypes(sequence);
             for (int j = 0; j < types.length; j++ ) {
-                allTypes.add(new Integer(types[j]));
+                allTypes.add(types[j]);
             }
         }
         int resultTypes[] = new int[allTypes.size()];
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/javax/management/loading/MLet.java
--- a/src/share/classes/javax/management/loading/MLet.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/management/loading/MLet.java	Fri Jun 20 09:57:17 2014 -0300
@@ -1307,13 +1307,13 @@
         if (type.compareTo("java.lang.Boolean") == 0)
              return Boolean.valueOf(param);
         if (type.compareTo("java.lang.Byte") == 0)
-             return new Byte(param);
+             return Byte.valueOf(param);
         if (type.compareTo("java.lang.Short") == 0)
-             return new Short(param);
+             return Short.valueOf(param);
         if (type.compareTo("java.lang.Long") == 0)
-             return new Long(param);
+             return Long.valueOf(param);
         if (type.compareTo("java.lang.Integer") == 0)
-             return new Integer(param);
+             return Integer.valueOf(param);
         if (type.compareTo("java.lang.Float") == 0)
              return new Float(param);
         if (type.compareTo("java.lang.Double") == 0)
diff -r d02b062bc827 src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
--- a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java	Fri Jun 20 09:57:17 2014 -0300
@@ -544,7 +544,7 @@
             }
 
             // convert seconds to milliseconds for time comparison
-            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
+            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
             if (currencyPeriod < 0) {
                 /* if currencyTimeLimit is -1 then value is never cached */
                 returnCachedValue = false;
@@ -580,7 +580,7 @@
                 if (tStamp == null)
                     tStamp = "0";
 
-                long lastTime = (new Long(tStamp)).longValue();
+                long lastTime = (Long.valueOf(tStamp)).longValue();
 
                 if (tracing) {
                     MODELMBEAN_LOGGER.logp(Level.FINER,
diff -r d02b062bc827 src/share/classes/javax/management/relation/RelationService.java
--- a/src/share/classes/javax/management/relation/RelationService.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/management/relation/RelationService.java	Fri Jun 20 09:57:17 2014 -0300
@@ -3208,7 +3208,7 @@
                 // End of check :)
                 RELATION_LOGGER.exiting(RelationService.class.getName(),
                         "checkRoleInt");
-                return new Integer(0);
+                return 0;
             }
         }
 
@@ -3218,7 +3218,7 @@
             if (!isWritable) {
                 RELATION_LOGGER.exiting(RelationService.class.getName(),
                         "checkRoleInt");
-                return new Integer(RoleStatus.ROLE_NOT_WRITABLE);
+                return RoleStatus.ROLE_NOT_WRITABLE;
             }
         }
 
@@ -3229,7 +3229,7 @@
         if (!chkMinFlag) {
             RELATION_LOGGER.exiting(RelationService.class.getName(),
                     "checkRoleInt");
-            return new Integer(RoleStatus.LESS_THAN_MIN_ROLE_DEGREE);
+            return RoleStatus.LESS_THAN_MIN_ROLE_DEGREE;
         }
 
         // Checks maximum cardinality
@@ -3237,7 +3237,7 @@
         if (!chkMaxFlag) {
             RELATION_LOGGER.exiting(RelationService.class.getName(),
                     "checkRoleInt");
-            return new Integer(RoleStatus.MORE_THAN_MAX_ROLE_DEGREE);
+            return RoleStatus.MORE_THAN_MAX_ROLE_DEGREE;
         }
 
         // Verifies that each referenced MBean is registered in the MBean
@@ -3254,7 +3254,7 @@
             if (currObjName == null) {
                 RELATION_LOGGER.exiting(RelationService.class.getName(),
                         "checkRoleInt");
-                return new Integer(RoleStatus.REF_MBEAN_NOT_REGISTERED);
+                return RoleStatus.REF_MBEAN_NOT_REGISTERED;
             }
 
             // Checks if it is of the correct class
@@ -3265,19 +3265,19 @@
                 if (!classSts) {
                     RELATION_LOGGER.exiting(RelationService.class.getName(),
                             "checkRoleInt");
-                    return new Integer(RoleStatus.REF_MBEAN_OF_INCORRECT_CLASS);
+                    return RoleStatus.REF_MBEAN_OF_INCORRECT_CLASS;
                 }
 
             } catch (InstanceNotFoundException exc) {
                 RELATION_LOGGER.exiting(RelationService.class.getName(),
                         "checkRoleInt");
-                return new Integer(RoleStatus.REF_MBEAN_NOT_REGISTERED);
+                return RoleStatus.REF_MBEAN_NOT_REGISTERED;
             }
         }
 
         RELATION_LOGGER.exiting(RelationService.class.getName(),
                 "checkRoleInt");
-        return new Integer(0);
+        return 0;
     }
 
 
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/javax/imageio/spi/PartiallyOrderedSet.java
--- a/src/share/classes/javax/imageio/spi/PartiallyOrderedSet.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/imageio/spi/PartiallyOrderedSet.java	Fri Jun 20 09:57:17 2014 -0300
@@ -170,7 +170,7 @@
         while (iter.hasNext()) {
             DigraphNode node = iter.next();
             int inDegree = node.getInDegree();
-            inDegrees.put(node, new Integer(inDegree));
+            inDegrees.put(node, inDegree);
 
             // Add nodes with zero in-degree to the zero list
             if (inDegree == 0) {
@@ -191,7 +191,7 @@
         while (outNodes.hasNext()) {
             DigraphNode node = outNodes.next();
             int inDegree = inDegrees.get(node).intValue() - 1;
-            inDegrees.put(node, new Integer(inDegree));
+            inDegrees.put(node, inDegree);
 
             // If the in-degree has fallen to 0, place the node on the list
             if (inDegree == 0) {
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/util/Locale.java
--- a/src/share/classes/java/util/Locale.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/util/Locale.java	Fri Jun 20 09:57:17 2014 -0300
@@ -1924,7 +1924,7 @@
         // the qualifier; if there are no qualifiers, the third element is
         // unused by the format pattern.
         Object[] displayNames = {
-            new Integer(qualifierNames.length != 0 ? 2 : 1),
+            qualifierNames.length != 0 ? 2 : 1,
             mainName,
             // We could also just call formatList() and have it handle the empty
             // list case, but this is more efficient, and we want it to be
@@ -2078,7 +2078,7 @@
         // Rebuild the argument list with the list length as the first element
         Object[] args = new Object[stringList.length + 1];
         System.arraycopy(stringList, 0, args, 1, stringList.length);
-        args[0] = new Integer(stringList.length);
+        args[0] = stringList.length;
 
         // Format it using the pattern in the resource
         MessageFormat format = new MessageFormat(listPattern);
diff -r d02b062bc827 src/share/classes/java/util/prefs/XmlSupport.java
--- a/src/share/classes/java/util/prefs/XmlSupport.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/util/prefs/XmlSupport.java	Fri Jun 20 09:57:17 2014 -0300
@@ -262,7 +262,7 @@
         try {
             TransformerFactory tf = TransformerFactory.newInstance();
             try {
-                tf.setAttribute("indent-number", new Integer(2));
+                tf.setAttribute("indent-number", 2);
             } catch (IllegalArgumentException iae) {
                 //Ignore the IAE. Should not fail the writeout even the
                 //transformer provider does not support "indent-number".
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/text/DecimalFormat.java
--- a/src/share/classes/java/text/DecimalFormat.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/text/DecimalFormat.java	Fri Jun 20 09:57:16 2014 -0300
@@ -2094,7 +2094,7 @@
             }
 
             return gotDouble ?
-                (Number)new Double(doubleResult) : (Number)new Long(longResult);
+                (Number)new Double(doubleResult) : (Number)Long.valueOf(longResult);
         }
     }
 
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/nio/charset/CoderResult.java
--- a/src/share/classes/java/nio/charset/CoderResult.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/nio/charset/CoderResult.java	Fri Jun 20 09:57:16 2014 -0300
@@ -200,7 +200,7 @@
         private synchronized CoderResult get(int len) {
             if (len <= 0)
                 throw new IllegalArgumentException("Non-positive length");
-            Integer k = new Integer(len);
+            Integer k = len;
             WeakReference w;
             CoderResult e = null;
             if (cache == null) {
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
--- a/src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java	Fri Jun 20 09:57:16 2014 -0300
@@ -322,13 +322,13 @@
 
         switch (optID) {
             case SO_TIMEOUT:
-                result = new Integer(timeout);
+                result = timeout;
                 break;
 
             case IP_TOS:
                 result = socketGetOption(optID);
                 if ( ((Integer)result).intValue() == -1) {
-                    result = new Integer(trafficClass);
+                    result = trafficClass;
                 }
                 break;
 
diff -r d02b062bc827 src/share/classes/java/net/AbstractPlainSocketImpl.java
--- a/src/share/classes/java/net/AbstractPlainSocketImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/net/AbstractPlainSocketImpl.java	Fri Jun 20 09:57:16 2014 -0300
@@ -279,7 +279,7 @@
             throw new SocketException("Socket Closed");
         }
         if (opt == SO_TIMEOUT) {
-            return new Integer(timeout);
+            return timeout;
         }
         int ret = 0;
         /*
@@ -299,7 +299,7 @@
             return Boolean.valueOf(ret != -1);
         case SO_LINGER:
             ret = socketGetOption(opt, null);
-            return (ret == -1) ? Boolean.FALSE: (Object)(new Integer(ret));
+            return (ret == -1) ? Boolean.FALSE: (Object)(ret);
         case SO_REUSEADDR:
             ret = socketGetOption(opt, null);
             return Boolean.valueOf(ret != -1);
@@ -310,13 +310,13 @@
         case SO_SNDBUF:
         case SO_RCVBUF:
             ret = socketGetOption(opt, null);
-            return new Integer(ret);
+            return ret;
         case IP_TOS:
             ret = socketGetOption(opt, null);
             if (ret == -1) { // ipv6 tos
-                return new Integer(trafficClass);
+                return trafficClass;
             } else {
-                return new Integer(ret);
+                return ret;
             }
         case SO_KEEPALIVE:
             ret = socketGetOption(opt, null);
diff -r d02b062bc827 src/share/classes/java/net/DatagramSocket.java
--- a/src/share/classes/java/net/DatagramSocket.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/net/DatagramSocket.java	Fri Jun 20 09:57:16 2014 -0300
@@ -858,7 +858,7 @@
     public synchronized void setSoTimeout(int timeout) throws SocketException {
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_TIMEOUT, new Integer(timeout));
+        getImpl().setOption(SocketOptions.SO_TIMEOUT, timeout);
     }
 
     /**
@@ -920,7 +920,7 @@
         }
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_SNDBUF, new Integer(size));
+        getImpl().setOption(SocketOptions.SO_SNDBUF, size);
     }
 
     /**
@@ -978,7 +978,7 @@
         }
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_RCVBUF, new Integer(size));
+        getImpl().setOption(SocketOptions.SO_RCVBUF, size);
     }
 
     /**
@@ -1040,7 +1040,7 @@
             throw new SocketException("Socket is closed");
         // Integer instead of Boolean for compatibility with older DatagramSocketImpl
         if (oldImpl)
-            getImpl().setOption(SocketOptions.SO_REUSEADDR, new Integer(on?-1:0));
+            getImpl().setOption(SocketOptions.SO_REUSEADDR, on?-1:0);
         else
             getImpl().setOption(SocketOptions.SO_REUSEADDR, Boolean.valueOf(on));
     }
@@ -1141,7 +1141,7 @@
 
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.IP_TOS, new Integer(tc));
+        getImpl().setOption(SocketOptions.IP_TOS, tc);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/java/net/ServerSocket.java
--- a/src/share/classes/java/net/ServerSocket.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/net/ServerSocket.java	Fri Jun 20 09:57:16 2014 -0300
@@ -650,7 +650,7 @@
     public synchronized void setSoTimeout(int timeout) throws SocketException {
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_TIMEOUT, new Integer(timeout));
+        getImpl().setOption(SocketOptions.SO_TIMEOUT, timeout);
     }
 
     /**
@@ -847,7 +847,7 @@
         }
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_RCVBUF, new Integer(size));
+        getImpl().setOption(SocketOptions.SO_RCVBUF, size);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/java/net/Socket.java
--- a/src/share/classes/java/net/Socket.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/net/Socket.java	Fri Jun 20 09:57:16 2014 -0300
@@ -1024,7 +1024,7 @@
             }
             if (linger > 65535)
                 linger = 65535;
-            getImpl().setOption(SocketOptions.SO_LINGER, new Integer(linger));
+            getImpl().setOption(SocketOptions.SO_LINGER, linger);
         }
     }
 
@@ -1140,7 +1140,7 @@
         if (timeout < 0)
           throw new IllegalArgumentException("timeout can't be negative");
 
-        getImpl().setOption(SocketOptions.SO_TIMEOUT, new Integer(timeout));
+        getImpl().setOption(SocketOptions.SO_TIMEOUT, timeout);
     }
 
     /**
@@ -1196,7 +1196,7 @@
         }
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_SNDBUF, new Integer(size));
+        getImpl().setOption(SocketOptions.SO_SNDBUF, size);
     }
 
     /**
@@ -1270,7 +1270,7 @@
         }
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.SO_RCVBUF, new Integer(size));
+        getImpl().setOption(SocketOptions.SO_RCVBUF, size);
     }
 
     /**
@@ -1380,7 +1380,7 @@
 
         if (isClosed())
             throw new SocketException("Socket is closed");
-        getImpl().setOption(SocketOptions.IP_TOS, new Integer(tc));
+        getImpl().setOption(SocketOptions.IP_TOS, tc);
     }
 
     /**
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/lang/ConditionalSpecialCasing.java
--- a/src/share/classes/java/lang/ConditionalSpecialCasing.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/lang/ConditionalSpecialCasing.java	Fri Jun 20 09:57:16 2014 -0300
@@ -147,7 +147,7 @@
     }
 
     private static char[] lookUpTable(String src, int index, Locale locale, boolean bLowerCasing) {
-        HashSet set = entryTable.get(new Integer(src.codePointAt(index)));
+        HashSet set = entryTable.get(src.codePointAt(index));
         char[] ret = null;
 
         if (set != null) {
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/javax/crypto/CryptoPolicyParser.java
--- a/src/share/classes/javax/crypto/CryptoPolicyParser.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/javax/crypto/CryptoPolicyParser.java	Fri Jun 20 09:57:17 2014 -0300
@@ -256,11 +256,11 @@
             while (peek(",")) {
                 match(",");
                 if (peek("number")) {
-                    paramsV.addElement(new Integer(match()));
+                    paramsV.addElement(match());
                 } else {
                     if (peek("*")) {
                         match("*");
-                        paramsV.addElement(new Integer(Integer.MAX_VALUE));
+                        paramsV.addElement(Integer.MAX_VALUE);
                     } else {
                         throw new ParsingException(st.lineno(),
                                                    "Expecting an integer");
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/beans/EventHandler.java
--- a/src/share/classes/java/beans/EventHandler.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/beans/EventHandler.java	Fri Jun 20 09:57:16 2014 -0300
@@ -437,7 +437,7 @@
         if (method.getDeclaringClass() == Object.class)  {
             // Handle the Object public methods.
             if (methodName.equals("hashCode"))  {
-                return new Integer(System.identityHashCode(proxy));
+                return System.identityHashCode(proxy);
             } else if (methodName.equals("equals")) {
                 return (proxy == arguments[0] ? Boolean.TRUE : Boolean.FALSE);
             } else if (methodName.equals("toString")) {
diff -r d02b062bc827 src/share/classes/java/beans/MetaData.java
--- a/src/share/classes/java/beans/MetaData.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/beans/MetaData.java	Fri Jun 20 09:57:16 2014 -0300
@@ -123,13 +123,13 @@
         Class oldClass = oldInstance.getClass();
         return new Expression(oldInstance, Array.class, "newInstance",
                    new Object[]{oldClass.getComponentType(),
-                                new Integer(Array.getLength(oldInstance))});
+                                Array.getLength(oldInstance)});
         }
 
     protected void initialize(Class type, Object oldInstance, Object newInstance, Encoder out) {
         int n = Array.getLength(oldInstance);
         for (int i = 0; i < n; i++) {
-            Object index = new Integer(i);
+            Object index = i;
             // Expression oldGetExp = new Expression(Array.class, "get", new Object[]{oldInstance, index});
             // Expression newGetExp = new Expression(Array.class, "get", new Object[]{newInstance, index});
             Expression oldGetExp = new Expression(oldInstance, "get", new Object[]{index});
@@ -635,7 +635,7 @@
             newSize = 0;
         }
         for (int i = 0; i < newSize; i++) {
-            Object index = new Integer(i);
+            Object index = i;
 
             Expression oldGetExp = new Expression(oldInstance, "get", new Object[]{index});
             Expression newGetExp = new Expression(newInstance, "get", new Object[]{index});
@@ -892,7 +892,7 @@
     protected Expression instantiate(Object oldInstance, Encoder out) {
         java.awt.MenuShortcut m = (java.awt.MenuShortcut)oldInstance;
         return new Expression(oldInstance, m.getClass(), "new",
-                   new Object[]{new Integer(m.getKey()), Boolean.valueOf(m.usesShiftModifier())});
+                   new Object[]{m.getKey(), Boolean.valueOf(m.usesShiftModifier())});
     }
 }
 
diff -r d02b062bc827 src/share/classes/java/beans/NameGenerator.java
--- a/src/share/classes/java/beans/NameGenerator.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/beans/NameGenerator.java	Fri Jun 20 09:57:16 2014 -0300
@@ -107,7 +107,7 @@
 
             Integer size = nameToCount.get(className);
             int instanceNumber = (size == null) ? 0 : (size).intValue() + 1;
-            nameToCount.put(className, new Integer(instanceNumber));
+            nameToCount.put(className, instanceNumber);
 
             result = className + instanceNumber;
             valueToName.put(instance, result);
diff -r d02b062bc827 src/share/classes/java/beans/Statement.java
--- a/src/share/classes/java/beans/Statement.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/beans/Statement.java	Fri Jun 20 09:57:16 2014 -0300
@@ -248,7 +248,7 @@
                 // ignored elsewhere.
                 if (target == Character.class && arguments.length == 1 &&
                     argClasses[0] == String.class) {
-                    return new Character(((String)arguments[0]).charAt(0));
+                    return ((String)arguments[0]).charAt(0);
                 }
                 try {
                     m = ConstructorFinder.findConstructor((Class)target, argClasses);
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/java/awt/Component.java
--- a/src/share/classes/java/awt/Component.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/awt/Component.java	Fri Jun 20 09:57:16 2014 -0300
@@ -8506,7 +8506,7 @@
         if (changeSupport == null || oldValue == newValue) {
             return;
         }
-        firePropertyChange(propertyName, new Character(oldValue), new Character(newValue));
+        firePropertyChange(propertyName, oldValue, newValue);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/java/awt/image/renderable/ParameterBlock.java
--- a/src/share/classes/java/awt/image/renderable/ParameterBlock.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/java/awt/image/renderable/ParameterBlock.java	Fri Jun 20 09:57:16 2014 -0300
@@ -337,7 +337,7 @@
      *         the specified parameter.
      */
     public ParameterBlock add(byte b) {
-        return add(new Byte(b));
+        return add(b);
     }
 
     /**
@@ -348,7 +348,7 @@
      *         the specified parameter.
      */
     public ParameterBlock add(char c) {
-        return add(new Character(c));
+        return add(c);
     }
 
     /**
@@ -359,7 +359,7 @@
      *         the specified parameter.
      */
     public ParameterBlock add(short s) {
-        return add(new Short(s));
+        return add(s);
     }
 
     /**
@@ -370,7 +370,7 @@
      *         the specified parameter.
      */
     public ParameterBlock add(int i) {
-        return add(new Integer(i));
+        return add(i);
     }
 
     /**
@@ -381,7 +381,7 @@
      *         the specified parameter.
      */
     public ParameterBlock add(long l) {
-        return add(new Long(l));
+        return add(l);
     }
 
     /**
@@ -441,7 +441,7 @@
      *        the specified parameter.
      */
     public ParameterBlock set(byte b, int index) {
-        return set(new Byte(b), index);
+        return set(b, index);
     }
 
     /**
@@ -457,7 +457,7 @@
      *        the specified parameter.
      */
     public ParameterBlock set(char c, int index) {
-        return set(new Character(c), index);
+        return set(c, index);
     }
 
     /**
@@ -473,7 +473,7 @@
      *        the specified parameter.
      */
     public ParameterBlock set(short s, int index) {
-        return set(new Short(s), index);
+        return set(s, index);
     }
 
     /**
@@ -489,7 +489,7 @@
      *        the specified parameter.
      */
     public ParameterBlock set(int i, int index) {
-        return set(new Integer(i), index);
+        return set(i, index);
     }
 
     /**
@@ -505,7 +505,7 @@
      *        the specified parameter.
      */
     public ParameterBlock set(long l, int index) {
-        return set(new Long(l), index);
+        return set(l, index);
     }
 
     /**
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java
--- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java	Fri Jun 20 09:57:16 2014 -0300
@@ -211,7 +211,7 @@
     }
 
     private void setCurrentFrameIndex(ThreadInfo tinfo, int index) {
-        tinfo.setUserObject(new Integer(index));
+        tinfo.setUserObject(index);
         //### In fact, the value may not have changed at this point.
         //### We need to signal that the user attempted to change it,
         //### however, so that the selection can be "warped" to the
diff -r d02b062bc827 src/share/classes/com/sun/tools/example/debug/tty/Commands.java
--- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java	Fri Jun 20 09:57:16 2014 -0300
@@ -84,7 +84,7 @@
                                     MessageOutput.println("Current thread isnt suspended.");
                                 } catch (ArrayIndexOutOfBoundsException e) {
                                     MessageOutput.println("Requested stack frame is no longer active:",
-                                                          new Object []{new Integer(stackFrame)});
+                                                          new Object []{stackFrame});
                                 }
                             }
                             MessageOutput.printPrompt();
@@ -935,21 +935,21 @@
             try {
                 methodInfo = loc.sourceName() +
                     MessageOutput.format("line number",
-                                         new Object [] {new Long(lineNumber)});
+                                         new Object [] {Long.valueOf(lineNumber)});
             } catch (AbsentInformationException e) {
                 methodInfo = MessageOutput.format("unknown");
             }
         }
         if (pc != -1) {
             MessageOutput.println("stack frame dump with pc",
-                                  new Object [] {new Integer(frameNumber + 1),
+                                  new Object [] {frameNumber + 1,
                                                  meth.declaringType().name(),
                                                  meth.name(),
                                                  methodInfo,
-                                                 new Long(pc)});
+                                                 Long.valueOf(pc)});
         } else {
             MessageOutput.println("stack frame dump",
-                                  new Object [] {new Integer(frameNumber + 1),
+                                  new Object [] {frameNumber + 1,
                                                  meth.declaringType().name(),
                                                  meth.name(),
                                                  methodInfo});
@@ -2093,8 +2093,8 @@
                         VirtualMachineManager vmm) {
         MessageOutput.println("minus version",
                               new Object [] { debuggerName,
-                                              new Integer(vmm.majorInterfaceVersion()),
-                                              new Integer(vmm.minorInterfaceVersion()),
+                                              vmm.majorInterfaceVersion(),
+                                              vmm.minorInterfaceVersion(),
                                                   System.getProperty("java.version")});
         if (Env.connection() != null) {
             try {
diff -r d02b062bc827 src/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/share/classes/com/sun/tools/example/debug/tty/TTY.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/example/debug/tty/TTY.java	Fri Jun 20 09:57:16 2014 -0300
@@ -241,8 +241,7 @@
                 }
                 if (line != null) {
                     MessageOutput.println("source line number and line",
-                                          new Object [] {new Integer(loc.lineNumber()),
-                                                         line});
+							new Object[] { loc.lineNumber(), line });
                 }
             }
         }
diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
--- a/src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java	Fri Jun 20 09:57:16 2014 -0300
@@ -100,9 +100,9 @@
     // make Integer or Long for given object ID
     protected static Number makeId(long id) {
         if ((id & ~Snapshot.SMALL_ID_MASK) == 0) {
-            return new Integer((int)id);
+            return (int)id;
         } else {
-            return new Long(id);
+            return id;
         }
     }
 
diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java
--- a/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java	Fri Jun 20 09:57:16 2014 -0300
@@ -581,9 +581,9 @@
     // Internals only below this point
     private Number makeId(long id) {
         if (identifierSize == 4) {
-            return new Integer((int)id);
+            return (int)id;
         } else {
-            return new Long(id);
+            return id;
         }
     }
 
diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
--- a/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java	Fri Jun 20 09:57:16 2014 -0300
@@ -215,7 +215,7 @@
                     long id = readID();
                     byte[] chars = new byte[(int)length - identifierSize];
                     in.readFully(chars);
-                    names.put(new Long(id), new String(chars));
+                    names.put(id, new String(chars));
                     break;
                 }
                 case HPROF_LOAD_CLASS: {
@@ -223,11 +223,11 @@
                     long classID = readID();
                     int stackTraceSerialNo = in.readInt();
                     long classNameID = readID();
-                    Long classIdI = new Long(classID);
+                    Long classIdI = classID;
                     String nm = getNameFromID(classNameID).replace('/', '.');
                     classNameFromObjectID.put(classIdI, nm);
                     if (classNameFromSerialNo != null) {
-                        classNameFromSerialNo.put(new Integer(serialNo), nm);
+                        classNameFromSerialNo.put(serialNo, nm);
                     }
                     break;
                 }
@@ -297,13 +297,13 @@
                         String methodSig = getNameFromID(readID());
                         String sourceFile = getNameFromID(readID());
                         int classSer = in.readInt();
-                        String className = classNameFromSerialNo.get(new Integer(classSer));
+                        String className = classNameFromSerialNo.get(classSer);
                         int lineNumber = in.readInt();
                         if (lineNumber < StackFrame.LINE_NUMBER_NATIVE) {
                             warn("Weird stack frame line number:  " + lineNumber);
                             lineNumber = StackFrame.LINE_NUMBER_UNKNOWN;
                         }
-                        stackFrames.put(new Long(id),
+                        stackFrames.put(id,
                                         new StackFrame(methodName, methodSig,
                                                        className, sourceFile,
                                                        lineNumber));
@@ -319,13 +319,12 @@
                         StackFrame[] frames = new StackFrame[in.readInt()];
                         for (int i = 0; i < frames.length; i++) {
                             long fid = readID();
-                            frames[i] = stackFrames.get(new Long(fid));
+                            frames[i] = stackFrames.get(fid);
                             if (frames[i] == null) {
                                 throw new IOException("Stack frame " + toHex(fid) + " not found");
                             }
                         }
-                        stackTraces.put(new Integer(serialNo),
-                                        new StackTrace(frames));
+					stackTraces.put(serialNo, new StackTrace(frames));
                     }
                     break;
                 }
@@ -404,8 +403,7 @@
                     int threadSeq = in.readInt();
                     int stackSeq = in.readInt();
                     bytesLeft -= identifierSize + 8;
-                    threadObjects.put(new Integer(threadSeq),
-                                      new ThreadObject(id, stackSeq));
+				threadObjects.put(threadSeq, new ThreadObject(id, stackSeq));
                     break;
                 }
                 case HPROF_GC_ROOT_JNI_GLOBAL: {
@@ -610,7 +608,7 @@
 
     private ThreadObject getThreadObjectFromSequence(int threadSeq)
             throws IOException {
-        ThreadObject to = threadObjects.get(new Integer(threadSeq));
+        ThreadObject to = threadObjects.get(threadSeq);
         if (to == null) {
             throw new IOException("Thread " + threadSeq +
                                   " not found for JNI local ref");
@@ -619,7 +617,7 @@
     }
 
     private String getNameFromID(long id) throws IOException {
-        return getNameFromID(new Long(id));
+        return getNameFromID(id);
     }
 
     private String getNameFromID(Long id) throws IOException {
@@ -638,7 +636,7 @@
         if (stackTraces == null) {
             return null;
         }
-        StackTrace result = stackTraces.get(new Integer(ser));
+        StackTrace result = stackTraces.get(ser);
         if (result == null) {
             warn("Stack trace not found for serial # " + ser);
         }
@@ -703,7 +701,7 @@
             String signature = "" + ((char) type);
             fields[i] = new JavaField(fieldName, signature);
         }
-        String name = classNameFromObjectID.get(new Long(id));
+        String name = classNameFromObjectID.get(id);
         if (name == null) {
             warn("Class name not found for " + toHex(id));
             name = "unknown-name@" + toHex(id);
diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/server/ObjectQuery.java
--- a/src/share/classes/com/sun/tools/hat/internal/server/ObjectQuery.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/hat/internal/server/ObjectQuery.java	Fri Jun 20 09:57:16 2014 -0300
@@ -99,7 +99,7 @@
         final JavaField[] fields = obj.getClazz().getFieldsForInstance();
         Integer[] hack = new Integer[things.length];
         for (int i = 0; i < things.length; i++) {
-            hack[i] = new Integer(i);
+            hack[i] = i;
         }
         ArraySorter.sort(hack, new Comparer() {
             public int compare(Object lhs, Object rhs) {
diff -r d02b062bc827 src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java
--- a/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java	Fri Jun 20 09:57:16 2014 -0300
@@ -63,9 +63,9 @@
                     }
                     Long count = referrersStat.get(cl);
                     if (count == null) {
-                        count = new Long(1);
+                        count = 1L;
                     } else {
-                        count = new Long(count.longValue() + 1);
+                        count = count + 1L;
                     }
                     referrersStat.put(cl, count);
                 }
@@ -75,9 +75,9 @@
                             JavaClass cl = obj.getClazz();
                             Long count = refereesStat.get(cl);
                             if (count == null) {
-                                count = new Long(1);
+                                count = 1L;
                             } else {
-                                count = new Long(count.longValue() + 1);
+                                count = count + 1L;
                             }
                             refereesStat.put(cl, count);
                         }
diff -r d02b062bc827 src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java
--- a/src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java	Fri Jun 20 09:57:16 2014 -0300
@@ -143,7 +143,7 @@
          * Find the locations which match the line number
          * passed in.
          */
-        List list = info.lineMapper.get(new Integer(lineNumber));
+        List list = info.lineMapper.get(lineNumber);
 
         if (list == null) {
             list = new ArrayList(0);
@@ -329,7 +329,7 @@
                 lineLocations.add(loc);
 
                 // Add to the line -> locations map
-                Integer key = new Integer(lineNumber);
+                Integer key = lineNumber;
                 List mappedLocs = lineMapper.get(key);
                 if (mappedLocs == null) {
                     mappedLocs = new ArrayList(1);
@@ -399,7 +399,7 @@
                 lineLocations.add(loc);
 
                 // Add to the line -> locations map
-                Integer key = new Integer(lineNumber);
+                Integer key = lineNumber;
                 List mappedLocs = lineMapper.get(key);
                 if (mappedLocs == null) {
                     mappedLocs = new ArrayList(1);
diff -r d02b062bc827 src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
--- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java	Fri Jun 20 09:57:16 2014 -0300
@@ -781,7 +781,7 @@
             type.setSignature(signature);
         }
 
-        typesByID.put(new Long(id), type);
+        typesByID.put(id, type);
         typesBySignature.add(type);
 
         if ((vm.traceFlags & VirtualMachine.TRACE_REFTYPES) != 0) {
@@ -809,7 +809,7 @@
             if (comp == 0) {
                 matches++;
                 iter.remove();
-                typesByID.remove(new Long(type.ref()));
+                typesByID.remove(type.ref());
                 if ((vm.traceFlags & VirtualMachine.TRACE_REFTYPES) != 0) {
                    vm.printTrace("Uncaching ReferenceType, sig=" + signature +
                                  ", id=" + type.ref());
@@ -895,7 +895,7 @@
             ReferenceTypeImpl retType = null;
             synchronized (this) {
                 if (typesByID != null) {
-                    retType = (ReferenceTypeImpl)typesByID.get(new Long(id));
+                    retType = (ReferenceTypeImpl)typesByID.get(id);
                 }
                 if (retType == null) {
                     retType = addReferenceType(id, tag, signature);
@@ -1247,7 +1247,7 @@
             return null;
         }
         ObjectReferenceImpl object = null;
-        Long key = new Long(id);
+        Long key = id;
 
         /*
          * Attempt to retrieve an existing object object reference
@@ -1313,7 +1313,7 @@
         // Handle any queue elements that are not strongly reachable
         processQueue();
 
-        SoftObjectReference ref = objectsByID.remove(new Long(object.ref()));
+        SoftObjectReference ref = objectsByID.remove(object.ref());
         if (ref != null) {
             batchForDispose(ref);
         } else {
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java
--- a/src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java	Fri Jun 20 09:57:16 2014 -0300
@@ -110,7 +110,7 @@
      *
      */
     public SolarisNumericGroupPrincipal(long name, boolean primaryGroup) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
         this.primaryGroup = primaryGroup;
     }
 
@@ -137,7 +137,7 @@
      *          SolarisNumericGroupPrincipal as a long.
      */
     public long longValue() {
-        return ((new Long(name)).longValue());
+        return Long.valueOf(name);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
--- a/src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java	Fri Jun 20 09:57:16 2014 -0300
@@ -96,7 +96,7 @@
      *                  represented as a long.
      */
     public SolarisNumericUserPrincipal(long name) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
     }
 
     /**
@@ -122,7 +122,7 @@
      *          SolarisNumericUserPrincipal as a long.
      */
     public long longValue() {
-        return ((new Long(name)).longValue());
+        return Long.valueOf(name);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
--- a/src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java	Fri Jun 20 09:57:16 2014 -0300
@@ -102,7 +102,7 @@
      *
      */
     public UnixNumericGroupPrincipal(long name, boolean primaryGroup) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
         this.primaryGroup = primaryGroup;
     }
 
@@ -129,7 +129,7 @@
      *          UnixNumericGroupPrincipal as a long.
      */
     public long longValue() {
-        return ((new Long(name)).longValue());
+        return Long.valueOf(name);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java
--- a/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java	Fri Jun 20 09:57:16 2014 -0300
@@ -87,7 +87,7 @@
      *                  represented as a long.
      */
     public UnixNumericUserPrincipal(long name) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
     }
 
     /**
@@ -113,7 +113,7 @@
      *          UnixNumericUserPrincipal as a long.
      */
     public long longValue() {
-        return ((new Long(name)).longValue());
+        return Long.valueOf(name);
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java
--- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java	Fri Jun 20 09:57:16 2014 -0300
@@ -1410,7 +1410,7 @@
             if (logger.isLoggable(Level.FINEST)) {
                 logger.log(Level.FINEST,
                     "DIGEST33:Expecting sequence num: {0}",
-                    new Integer(peerSeqNum));
+                    peerSeqNum);
                 traceOutput(DP_CLASS_NAME, "unwrap", "DIGEST34:incoming: ",
                     encryptedMsg);
             }
@@ -1460,7 +1460,7 @@
                     if (logger.isLoggable(Level.INFO)) {
                         logger.log(Level.INFO,
                             "DIGEST39:Incorrect padding: {0}",
-                            new Byte(msgWithPadding[msgWithPadding.length - 1]));
+                            msgWithPadding[msgWithPadding.length - 1]);
                     }
                     return EMPTY_BYTE_ARRAY;
                 }
diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
--- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java	Fri Jun 20 09:57:16 2014 -0300
@@ -439,7 +439,7 @@
 
         if (logger.isLoggable(Level.FINE)) {
             logger.log(Level.FINE, "DIGEST61:Raw send size: {0}",
-                new Integer(rawSendSize));
+                rawSendSize);
         }
      }
 
diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
--- a/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java	Fri Jun 20 09:57:16 2014 -0300
@@ -241,7 +241,7 @@
                         "KRB5CLNT05:Challenge [unwrapped]:", gssOutToken);
                 }
                 logger.log(Level.FINE, "KRB5CLNT06:Server protections: {0}",
-                    new Byte(gssOutToken[0]));
+                    gssOutToken[0]);
             }
 
             // Client selects preferred protection
@@ -275,9 +275,8 @@
             if (logger.isLoggable(Level.FINE)) {
                 logger.log(Level.FINE,
 "KRB5CLNT07:Client max recv size: {0}; server max recv size: {1}; rawSendSize: {2}",
-                    new Object[] {new Integer(recvMaxBufSize),
-                                  new Integer(srvMaxBufSize),
-                                  new Integer(rawSendSize)});
+						new Object[] { recvMaxBufSize, srvMaxBufSize,
+								rawSendSize });
             }
 
             // Construct negotiated security layers and client's max
@@ -293,7 +292,7 @@
             if (logger.isLoggable(Level.FINE)) {
                 logger.log(Level.FINE,
             "KRB5CLNT08:Selected protection: {0}; privacy: {1}; integrity: {2}",
-                    new Object[]{new Byte(selectedQop),
+                    new Object[]{selectedQop,
                                  Boolean.valueOf(privacy),
                                  Boolean.valueOf(integrity)});
             }
diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
--- a/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java	Fri Jun 20 09:57:16 2014 -0300
@@ -221,8 +221,7 @@
             if (logger.isLoggable(Level.FINE)) {
                 logger.log(Level.FINE,
                     "KRB5SRV06:Supported protections: {0}; recv max buf size: {1}",
-                    new Object[]{new Byte(allQop),
-                                 new Integer(recvMaxBufSize)});
+                    new Object[]{allQop, recvMaxBufSize});
             }
 
             handshakeStage = 2;  // progress to next stage
@@ -288,14 +287,12 @@
             if (logger.isLoggable(Level.FINE)) {
                 logger.log(Level.FINE,
             "KRB5SRV10:Selected protection: {0}; privacy: {1}; integrity: {2}",
-                    new Object[]{new Byte(selectedQop),
+                    new Object[]{selectedQop,
                                  Boolean.valueOf(privacy),
                                  Boolean.valueOf(integrity)});
                 logger.log(Level.FINE,
 "KRB5SRV11:Client max recv size: {0}; server max send size: {1}; rawSendSize: {2}",
-                    new Object[] {new Integer(clntMaxBufSize),
-                                  new Integer(sendMaxBufSize),
-                                  new Integer(rawSendSize)});
+                    new Object[] {clntMaxBufSize, sendMaxBufSize, rawSendSize});
             }
 
             // Get authorization identity, if any
diff -r d02b062bc827 src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
--- a/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java	Fri Jun 20 09:57:16 2014 -0300
@@ -77,7 +77,7 @@
 
             if (logger.isLoggable(Level.FINE)) {
                 logger.logp(Level.FINE, myClassName, "constructor",
-                    "SASLIMPL02:Preferred qop mask: {0}", new Byte(allQop));
+                    "SASLIMPL02:Preferred qop mask: {0}", allQop);
 
                 if (qop.length > 0) {
                     StringBuffer qopbuf = new StringBuffer();
@@ -286,7 +286,7 @@
 
             // Message id supplied by caller as part of traceTag
             logger.logp(lev, srcClass, srcMethod, "{0} ( {1} ): {2}",
-                new Object[] {traceTag, new Integer(origlen), content});
+                new Object[] {traceTag, origlen, content});
         } catch (Exception e) {
             logger.logp(Level.WARNING, srcClass, srcMethod,
                 "SASLIMPL09:Error generating trace output: {0}", e);
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/jndi/ldap/Connection.java
--- a/src/share/classes/com/sun/jndi/ldap/Connection.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jndi/ldap/Connection.java	Fri Jun 20 09:57:15 2014 -0300
@@ -249,7 +249,7 @@
                 String.class, int.class});
 
             return inetSocketAddressCons.newInstance(new Object[]{
-                host, new Integer(port)});
+                host, port});
 
         } catch (ClassNotFoundException |
                  InstantiationException |
@@ -309,7 +309,7 @@
 
                     // connected socket
                     connect.invoke(socket, new Object[]{
-                        endpoint, new Integer(connectTimeout)});
+                        endpoint, connectTimeout});
 
                 } catch (NoSuchMethodException e) {
                     // continue (but ignore connectTimeout)
@@ -326,7 +326,7 @@
                 }
                 // connected socket
                 socket = (Socket) createSocket.invoke(factory,
-                    new Object[]{host, new Integer(port)});
+                    new Object[]{host, port});
             }
         } else {
 
@@ -348,7 +348,7 @@
                             "a timeout");
                     }
                     connect.invoke(socket, new Object[]{
-                        endpoint, new Integer(connectTimeout)});
+                        endpoint, connectTimeout});
 
                 } catch (NoSuchMethodException e) {
                     // continue (but ignore connectTimeout)
diff -r d02b062bc827 src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java
--- a/src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java	Fri Jun 20 09:57:15 2014 -0300
@@ -406,7 +406,7 @@
                 try {
                     return Integer.getInteger(propName, defVal);
                 } catch (SecurityException e) {
-                    return new Integer(defVal);
+                    return defVal;
                 }
             }
         });
@@ -421,7 +421,7 @@
                 try {
                     return Long.getLong(propName, defVal);
                 } catch (SecurityException e) {
-                    return new Long(defVal);
+                    return defVal;
                 }
             }
         });
diff -r d02b062bc827 src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java
--- a/src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java	Fri Jun 20 09:57:15 2014 -0300
@@ -221,7 +221,7 @@
             return;
 
         NamingEvent e = new NamingEvent(eventSrc, NamingEvent.OBJECT_ADDED,
-            newBd, null, new Long(changeID));
+            newBd, null, changeID);
         support.queueEvent(e, namingListeners);
     }
 
@@ -233,7 +233,7 @@
             return;
 
         NamingEvent e = new NamingEvent(eventSrc, NamingEvent.OBJECT_REMOVED,
-            null, oldBd, new Long(changeID));
+            null, oldBd, changeID);
         support.queueEvent(e, namingListeners);
     }
 
@@ -248,7 +248,7 @@
         Binding oldBd = new Binding(newBd.getName(), null, newBd.isRelative());
 
         NamingEvent e = new NamingEvent(
-            eventSrc, NamingEvent.OBJECT_CHANGED, newBd, oldBd, new Long(changeID));
+            eventSrc, NamingEvent.OBJECT_CHANGED, newBd, oldBd, changeID);
         support.queueEvent(e, namingListeners);
     }
 
@@ -273,7 +273,7 @@
         }
 
         NamingEvent e = new NamingEvent(
-            eventSrc, NamingEvent.OBJECT_RENAMED, newBd, oldBd, new Long(changeID));
+            eventSrc, NamingEvent.OBJECT_RENAMED, newBd, oldBd, changeID);
         support.queueEvent(e, namingListeners);
     }
 
diff -r d02b062bc827 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
--- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java	Fri Jun 20 09:57:15 2014 -0300
@@ -379,7 +379,7 @@
         // used for substring comparisons (where proto has "*" wildcards
         private boolean substringMatch(String proto, String value) {
             // simple case 1: "*" means attribute presence is being tested
-            if(proto.equals(new Character(WILDCARD_TOKEN).toString())) {
+            if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) {
                 if(debug) {System.out.println("simple presence assertion");}
                 return true;
             }
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
--- a/src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java	Fri Jun 20 09:57:15 2014 -0300
@@ -284,20 +284,20 @@
     final static Hashtable intTable = new Hashtable<>();
     final static Hashtable stringTable = new Hashtable<>();
     static  {
-        intTable.put(new Integer(0), "unspecified");
-        intTable.put(new Integer(3), "notReady");
-        intTable.put(new Integer(6), "destroy");
-        intTable.put(new Integer(2), "notInService");
-        intTable.put(new Integer(5), "createAndWait");
-        intTable.put(new Integer(1), "active");
-        intTable.put(new Integer(4), "createAndGo");
-        stringTable.put("unspecified", new Integer(0));
-        stringTable.put("notReady", new Integer(3));
-        stringTable.put("destroy", new Integer(6));
-        stringTable.put("notInService", new Integer(2));
-        stringTable.put("createAndWait", new Integer(5));
-        stringTable.put("active", new Integer(1));
-        stringTable.put("createAndGo", new Integer(4));
+        intTable.put(0, "unspecified");
+        intTable.put(3, "notReady");
+        intTable.put(6, "destroy");
+        intTable.put(2, "notInService");
+        intTable.put(5, "createAndWait");
+        intTable.put(1, "active");
+        intTable.put(4, "createAndGo");
+        stringTable.put("unspecified", 0);
+        stringTable.put("notReady", 3);
+        stringTable.put("destroy", 6);
+        stringTable.put("notInService", 2);
+        stringTable.put("createAndWait", 5);
+        stringTable.put("active", 1);
+        stringTable.put("createAndGo", 4);
     }
 
 
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/Enumerated.java
--- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java	Fri Jun 20 09:57:15 2014 -0300
@@ -71,7 +71,7 @@
    *            the method is illegal or inappropriate.
    */
   public Enumerated(int valueIndex) throws IllegalArgumentException {
-    if (getIntTable().get(new Integer(valueIndex)) == null) {
+    if (getIntTable().get(valueIndex) == null) {
       throw new IllegalArgumentException() ;
     }
     value = valueIndex ;
@@ -181,7 +181,7 @@
    */
   @Override
   public String toString() {
-    return getIntTable().get(new Integer(value)) ;
+    return getIntTable().get(value);
   }
 
 
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java
--- a/src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java	Fri Jun 20 09:57:15 2014 -0300
@@ -100,7 +100,7 @@
 
 
   void openNodeScope(Node n) {
-    marks.push(new Integer(mk));
+    marks.push(mk);
     mk = sp;
     n.jjtOpen();
   }
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java	Fri Jun 20 09:57:15 2014 -0300
@@ -84,7 +84,7 @@
      * @return The Long representation of the value.
      */
     public Long toLong() {
-        return new Long(value) ;
+        return value;
     }
 
     /**
@@ -100,7 +100,7 @@
      * @return The Integer representation of the value.
      */
     public Integer toInteger() {
-        return new Integer((int)value) ;
+        return (int)value;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpInt.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpInt.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpInt.java	Fri Jun 20 09:57:15 2014 -0300
@@ -130,7 +130,7 @@
      * @return The Long representation of the value.
      */
     public Long toLong() {
-        return new Long(value) ;
+        return value;
     }
 
     /**
@@ -146,7 +146,7 @@
      * @return The Integer representation of the value.
      */
     public Integer toInteger() {
-        return new Integer((int)value) ;
+        return (int)value;
     }
 
     /**
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/SnmpString.java
--- a/src/share/classes/com/sun/jmx/snmp/SnmpString.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/SnmpString.java	Fri Jun 20 09:57:15 2014 -0300
@@ -140,7 +140,7 @@
     public Byte[] toByte() {
         Byte[] result = new Byte[value.length] ;
         for (int i = 0 ; i < value.length ; i++) {
-            result[i] = new Byte(value[i]) ;
+            result[i] = value[i];
         }
         return result ;
     }
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
--- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java	Fri Jun 20 09:57:15 2014 -0300
@@ -136,7 +136,7 @@
      */
     public boolean isNestedArc(long arc) {
         if (subgroups == null) return false;
-        Object obj = subgroups.get(new Long(arc));
+        Object obj = subgroups.get(arc);
         // if the arc is registered in the hashtable,
         // it leads to a subgroup.
         return (obj != null);
@@ -260,7 +260,7 @@
      *
      */
     void registerNestedArc(long arc) {
-        Long obj = new Long(arc);
+        Long obj = arc;
         if (subgroups == null) subgroups = new Hashtable<>();
         // registers the arc in the hashtable.
         subgroups.put(obj,obj);
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java
--- a/src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java	Fri Jun 20 09:57:15 2014 -0300
@@ -1272,8 +1272,8 @@
                          message,                    // message
                          "State",                    // attribute name
                          "int",                      // attribute type
-                         new Integer(oldState),      // old value
-                         new Integer(newState) );    // new value
+                         oldState,                   // old value
+                         newState);                  // new value
         if (SNMP_ADAPTOR_LOGGER.isLoggable(Level.FINEST)) {
             SNMP_ADAPTOR_LOGGER.logp(Level.FINEST, dbgTag,
                 "sendStateChangeNotification","Sending AttributeChangeNotification #"
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java
--- a/src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java	Fri Jun 20 09:57:15 2014 -0300
@@ -569,7 +569,7 @@
      */
     @Override
     public Integer getTrapPort() {
-        return new Integer(trapPort) ;
+        return trapPort;
     }
 
     /**
@@ -639,7 +639,7 @@
      */
     @Override
     public Integer getBufferSize() {
-        return new Integer(bufferSize) ;
+        return bufferSize;
     }
 
     /**
@@ -858,7 +858,7 @@
      */
     @Override
     public Long getSnmpOutTraps() {
-        return new Long(snmpOutTraps);
+        return (long)snmpOutTraps;
     }
 
     /**
@@ -868,7 +868,7 @@
      */
     @Override
     public Long getSnmpOutGetResponses() {
-        return new Long(snmpOutGetResponses);
+        return (long)snmpOutGetResponses;
     }
 
     /**
@@ -878,7 +878,7 @@
      */
     @Override
     public Long getSnmpOutGenErrs() {
-        return new Long(snmpOutGenErrs);
+		return (long) snmpOutGenErrs;
     }
 
     /**
@@ -888,7 +888,7 @@
      */
     @Override
     public Long getSnmpOutBadValues() {
-        return new Long(snmpOutBadValues);
+        return (long)snmpOutBadValues;
     }
 
     /**
@@ -898,7 +898,7 @@
      */
     @Override
     public Long getSnmpOutNoSuchNames() {
-        return new Long(snmpOutNoSuchNames);
+        return (long)snmpOutNoSuchNames;
     }
 
     /**
@@ -908,7 +908,7 @@
      */
     @Override
     public Long getSnmpOutTooBigs() {
-        return new Long(snmpOutTooBigs);
+        return (long)snmpOutTooBigs;
     }
 
     /**
@@ -918,7 +918,7 @@
      */
     @Override
     public Long getSnmpInASNParseErrs() {
-        return new Long(snmpInASNParseErrs);
+        return (long)snmpInASNParseErrs;
     }
 
     /**
@@ -928,7 +928,7 @@
      */
     @Override
     public Long getSnmpInBadCommunityUses() {
-        return new Long(snmpInBadCommunityUses);
+        return (long)snmpInBadCommunityUses;
     }
 
     /**
@@ -939,7 +939,7 @@
      */
     @Override
     public Long getSnmpInBadCommunityNames() {
-        return new Long(snmpInBadCommunityNames);
+        return (long)snmpInBadCommunityNames;
     }
 
     /**
@@ -949,7 +949,7 @@
      */
     @Override
     public Long getSnmpInBadVersions() {
-        return new Long(snmpInBadVersions);
+        return (long)snmpInBadVersions;
     }
 
     /**
@@ -959,7 +959,7 @@
      */
     @Override
     public Long getSnmpOutPkts() {
-        return new Long(snmpOutPkts);
+        return (long)snmpOutPkts;
     }
 
     /**
@@ -969,7 +969,7 @@
      */
     @Override
     public Long getSnmpInPkts() {
-        return new Long(snmpInPkts);
+        return (long)snmpInPkts;
     }
 
     /**
@@ -979,7 +979,7 @@
      */
     @Override
     public Long getSnmpInGetRequests() {
-        return new Long(snmpInGetRequests);
+        return (long)snmpInGetRequests;
     }
 
     /**
@@ -989,7 +989,7 @@
      */
     @Override
     public Long getSnmpInGetNexts() {
-        return new Long(snmpInGetNexts);
+        return (long)snmpInGetNexts;
     }
 
     /**
@@ -999,7 +999,7 @@
      */
     @Override
     public Long getSnmpInSetRequests() {
-        return new Long(snmpInSetRequests);
+        return (long)snmpInSetRequests;
     }
 
     /**
@@ -1009,7 +1009,7 @@
      */
     @Override
     public Long getSnmpInTotalSetVars() {
-        return new Long(snmpInTotalSetVars);
+        return (long)snmpInTotalSetVars;
     }
 
     /**
@@ -1019,7 +1019,7 @@
      */
     @Override
     public Long getSnmpInTotalReqVars() {
-        return new Long(snmpInTotalReqVars);
+        return (long)snmpInTotalReqVars;
     }
 
     /**
@@ -1032,7 +1032,7 @@
      */
     @Override
     public Long getSnmpSilentDrops() {
-        return new Long(snmpSilentDrops);
+        return (long)snmpSilentDrops;
     }
 
     /**
@@ -1045,7 +1045,7 @@
      */
     @Override
     public Long getSnmpProxyDrops() {
-        return new Long(0);
+        return 0L;
     }
 
 
diff -r d02b062bc827 src/share/classes/com/sun/jmx/snmp/internal/SnmpLcd.java
--- a/src/share/classes/com/sun/jmx/snmp/internal/SnmpLcd.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jmx/snmp/internal/SnmpLcd.java	Fri Jun 20 09:57:15 2014 -0300
@@ -43,15 +43,15 @@
 
         public void addModelLcd(int id,
                                 SnmpModelLcd usmlcd) {
-            models.put(new Integer(id), usmlcd);
+            models.put(id, usmlcd);
         }
 
         public SnmpModelLcd getModelLcd(int id) {
-            return models.get(new Integer(id));
+            return models.get(id);
         }
 
         public SnmpModelLcd removeModelLcd(int id) {
-            return models.remove(new Integer(id));
+            return models.remove(id);
         }
     }
 
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
--- a/src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java	Fri Jun 20 09:57:15 2014 -0300
@@ -812,12 +812,12 @@
 
             "OptionPane.setButtonMargin", Boolean.FALSE,
             "OptionPane.sameSizeButtons", Boolean.TRUE,
-            "OptionPane.buttonOrientation", new Integer(SwingConstants.RIGHT),
+            "OptionPane.buttonOrientation", SwingConstants.RIGHT,
             "OptionPane.minimumSize", new DimensionUIResource(262, 90),
-            "OptionPane.buttonPadding", new Integer(10),
+            "OptionPane.buttonPadding", 10,
             "OptionPane.windowBindings", new Object[] {
                 "ESCAPE", "close" },
-            "OptionPane.buttonClickThreshhold", new Integer(500),
+            "OptionPane.buttonClickThreshhold", 500,
             "OptionPane.isYesLast", Boolean.TRUE,
             "OptionPane.font", new FontLazyValue(Region.OPTION_PANE),
 
diff -r d02b062bc827 src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
--- a/src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java	Fri Jun 20 09:57:15 2014 -0300
@@ -567,7 +567,7 @@
             "ProgressBar.selectionForeground", table.get("control"),
             "ProgressBar.selectionBackground", table.get("controlText"),
             "ProgressBar.border", loweredBevelBorder,
-            "ProgressBar.cellLength", new Integer(6),
+            "ProgressBar.cellLength", 6,
             "ProgressBar.cellSpacing", Integer.valueOf(0),
 
             // Buttons
@@ -582,7 +582,7 @@
                  "released SPACE", "released"
               }),
 
-            "CheckBox.textIconGap", new Integer(8),
+            "CheckBox.textIconGap", 8,
             "CheckBox.margin", new InsetsUIResource(4, 2, 4, 2),
             "CheckBox.icon", checkBoxIcon,
             "CheckBox.focus", table.get("activeCaptionBorder"),
@@ -593,7 +593,7 @@
                  }),
 
             "RadioButton.margin", new InsetsUIResource(4, 2, 4, 2),
-            "RadioButton.textIconGap", new Integer(8),
+            "RadioButton.textIconGap", 8,
             "RadioButton.background", table.get("control"),
             "RadioButton.foreground", table.get("controlText"),
             "RadioButton.icon", radioButtonIcon,
@@ -627,10 +627,10 @@
             "Menu.selectionBackground", menuItemPressedBackground,
             "Menu.checkIcon", menuItemCheckIcon,
             "Menu.arrowIcon", menuArrowIcon,
-            "Menu.menuPopupOffsetX", new Integer(0),
-            "Menu.menuPopupOffsetY", new Integer(0),
-            "Menu.submenuPopupOffsetX", new Integer(-2),
-            "Menu.submenuPopupOffsetY", new Integer(3),
+            "Menu.menuPopupOffsetX", 0,
+            "Menu.menuPopupOffsetY", 0,
+            "Menu.submenuPopupOffsetX", -2,
+            "Menu.submenuPopupOffsetY", 3,
             "Menu.shortcutKeys", new int[]{
                 SwingUtilities2.getSystemMnemonicKeyMask(),
                 KeyEvent.META_MASK
@@ -938,7 +938,7 @@
             "Tree.collapsedIcon", treeCollapsedIcon,
             "Tree.editorBorder", focusBorder,
             "Tree.editorBorderSelectionColor", table.get("activeCaptionBorder"),
-            "Tree.rowHeight", new Integer(18),
+            "Tree.rowHeight", 18,
             "Tree.drawsFocusBorderAroundIcon", Boolean.TRUE,
             "Tree.focusInputMap", new UIDefaults.LazyInputMap(new Object[] {
                                 "COPY", "copy",
diff -r d02b062bc827 src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
--- a/src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java	Fri Jun 20 09:57:15 2014 -0300
@@ -1102,8 +1102,7 @@
             "PasswordField.selectionBackground", SelectionBackgroundColor,
             "PasswordField.selectionForeground", SelectionTextColor,
             "PasswordField.caretForeground",WindowTextColor,
-            "PasswordField.echoChar", new XPValue(new Character((char)0x25CF),
-                                                  new Character('*')),
+            "PasswordField.echoChar", new XPValue((char)0x25CF,'*'),
 
             // *** ProgressBar
             "ProgressBar.font", ControlFont,
-------------- next part --------------
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
--- a/src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java	Fri Jun 20 09:57:15 2014 -0300
@@ -126,18 +126,18 @@
             new IIOMetadataNode(nativeMetadataFormatName);
 
         addChildNode(root, "BMPVersion", bmpVersion);
-        addChildNode(root, "Width", new Integer(width));
-        addChildNode(root, "Height", new Integer(height));
-        addChildNode(root, "BitsPerPixel", new Short(bitsPerPixel));
-        addChildNode(root, "Compression", new Integer(compression));
-        addChildNode(root, "ImageSize", new Integer(imageSize));
+        addChildNode(root, "Width", width);
+        addChildNode(root, "Height", height);
+        addChildNode(root, "BitsPerPixel", bitsPerPixel);
+        addChildNode(root, "Compression", compression);
+        addChildNode(root, "ImageSize", imageSize);
 
         IIOMetadataNode node = addChildNode(root, "PixelsPerMeter", null);
-        addChildNode(node, "X", new Integer(xPixelsPerMeter));
-        addChildNode(node, "Y", new Integer(yPixelsPerMeter));
+        addChildNode(node, "X", xPixelsPerMeter);
+        addChildNode(node, "Y", yPixelsPerMeter);
 
-        addChildNode(root, "ColorsUsed", new Integer(colorsUsed));
-        addChildNode(root, "ColorsImportant", new Integer(colorsImportant));
+        addChildNode(root, "ColorsUsed", colorsUsed);
+        addChildNode(root, "ColorsImportant", colorsImportant);
 
         int version = 0;
         for (int i = 0; i < bmpVersion.length(); i++)
@@ -146,19 +146,19 @@
 
         if (version >= 4) {
             node = addChildNode(root, "Mask", null);
-            addChildNode(node, "Red", new Integer(redMask));
-            addChildNode(node, "Green", new Integer(greenMask));
-            addChildNode(node, "Blue", new Integer(blueMask));
-            addChildNode(node, "Alpha", new Integer(alphaMask));
+            addChildNode(node, "Red", redMask);
+            addChildNode(node, "Green", greenMask);
+            addChildNode(node, "Blue", blueMask);
+            addChildNode(node, "Alpha", alphaMask);
 
-            addChildNode(root, "ColorSpaceType", new Integer(colorSpace));
+            addChildNode(root, "ColorSpaceType", colorSpace);
 
             node = addChildNode(root, "CIEXYZEndPoints", null);
             addXYZPoints(node, "Red", redX, redY, redZ);
             addXYZPoints(node, "Green", greenX, greenY, greenZ);
             addXYZPoints(node, "Blue", blueX, blueY, blueZ);
 
-            node = addChildNode(root, "Intent", new Integer(intent));
+            node = addChildNode(root, "Intent", intent);
         }
 
         // Palette
@@ -172,12 +172,12 @@
                 red = palette[j++] & 0xff;
                 green = palette[j++] & 0xff;
                 blue = palette[j++] & 0xff;
-                addChildNode(entry, "Red", new Byte((byte)red));
-                addChildNode(entry, "Green", new Byte((byte)green));
-                addChildNode(entry, "Blue", new Byte((byte)blue));
+                addChildNode(entry, "Red", (byte)red);
+                addChildNode(entry, "Green", (byte)green);
+                addChildNode(entry, "Blue", (byte)blue);
                 if (numComps == 4)
                     addChildNode(entry, "Alpha",
-                                 new Byte((byte)(palette[j++] & 0xff)));
+                                 (byte)(palette[j++] & 0xff));
             }
         }
 
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
--- a/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java	Fri Jun 20 09:57:15 2014 -0300
@@ -616,7 +616,7 @@
                     return index;
                 }
 
-                Long l1 = new Long(stream.getStreamPosition());
+                Long l1 = stream.getStreamPosition();
                 imageStartPosition.add(l1);
                 ++index;
             }
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
--- a/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java	Fri Jun 20 09:57:15 2014 -0300
@@ -367,10 +367,10 @@
             // Now we are at the first image if there are any, so add it
             // to the list
             if (hasNextImage()) {
-                imagePositions.add(new Long(iis.getStreamPosition()));
+                imagePositions.add(iis.getStreamPosition());
             }
         } else { // Not tables only, so add original pos to the list
-            imagePositions.add(new Long(savePos));
+            imagePositions.add(savePos);
             // And set current image since we've read it now
             currentImage = 0;
         }
@@ -498,7 +498,7 @@
                 if (!hasNextImage()) {
                     throw new IndexOutOfBoundsException();
                 }
-                pos = new Long(iis.getStreamPosition());
+                pos = iis.getStreamPosition();
                 imagePositions.add(pos);
                 if (seekForwardOnly) {
                     iis.flushBefore(pos.longValue());
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
--- a/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java	Fri Jun 20 09:57:15 2014 -0300
@@ -2323,7 +2323,7 @@
                 SOSMarkerSegment sos = (SOSMarkerSegment) seg;
                 SOSMarkerSegment.ScanComponentSpec [] specs = sos.componentSpecs;
                 for (int i = 0; i < specs.length; i++) {
-                    Integer id = new Integer(specs[i].componentSelector);
+                    Integer id = specs[i].componentSelector;
                     if (!ids.contains(id)) {
                         ids.add(id);
                     }
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
--- a/src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java	Fri Jun 20 09:57:15 2014 -0300
@@ -639,7 +639,7 @@
         metadata.zTXt_keyword.add(keyword);
 
         int method = stream.readUnsignedByte();
-        metadata.zTXt_compressionMethod.add(new Integer(method));
+        metadata.zTXt_compressionMethod.add(method);
 
         byte[] b = new byte[chunkLength - keyword.length() - 2];
         stream.readFully(b);
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
--- a/src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java	Fri Jun 20 09:57:15 2014 -0300
@@ -1644,7 +1644,7 @@
                     int compressionMethod =
                         getEnumeratedAttribute(zTXt_node, "compressionMethod",
                                                zTXt_compressionMethodNames);
-                    zTXt_compressionMethod.add(new Integer(compressionMethod));
+                    zTXt_compressionMethod.add(compressionMethod);
 
                     String text = getAttribute(zTXt_node, "text");
                     zTXt_text.add(text);
diff -r d02b062bc827 src/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java
--- a/src/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java	Fri Jun 20 09:57:15 2014 -0300
@@ -75,9 +75,9 @@
         IIOMetadataNode root =
             new IIOMetadataNode(nativeMetadataFormatName);
 
-        addChildNode(root, "WBMPType", new Integer(wbmpType));
-        addChildNode(root, "Width", new Integer(width));
-        addChildNode(root, "Height", new Integer(height));
+        addChildNode(root, "WBMPType", wbmpType);
+        addChildNode(root, "Width", width);
+        addChildNode(root, "Height", height);
 
         return root;
     }

From peter.levart at gmail.com  Fri Jun 20 14:02:27 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Jun 2014 16:02:27 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A43055.5070803@oracle.com>
References: 	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
	<53A43055.5070803@oracle.com>
Message-ID: <53A43EF3.8000206@gmail.com>

On 06/20/2014 03:00 PM, Alan Bateman wrote:
> On 20/06/2014 12:20, Peter Levart wrote:
>>
>> Hi,
>>
>> A patch that solves this is a patch to InetAddress. We can't suppress 
>> initialization of InetAddress as part of NetworkInterface 
>> initialization, but we can suppress initialization of NameService 
>> providers as part of InetAddress initialization by moving them into a 
>> nested class called NameServices:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.NameServices/webrev.01/ 
>>
>>
>> This should solve Martin's issue, but the patch to TLR initialization 
>> could be applied nevertheless, since it might help overcome possible 
>> issues when using SecureRandom for TLR's seed.
> That should work. An alternative is to just get rid of this mechanism. 
> Way back then it was useful for running on systems that has NIS/YP 
> configured as it wasn't always possible get to the fully qualified 
> host name. It was also used as a workaround to long timeouts on 
> Windows doing NetBIOS lookups. I don't think if either of these cases 
> it interesting these days so it might be the simplest thing to just 
> get rid of it. The other thing is that it was never meant to be a 
> general service provider mechanism, it's not usable outside of the JDK 
> without extending JDK-internal classes for example.
>
> -Alan

And, as Martin pointed out, it seems to be used for tests that exercise 
particular responses from NameService API to test the behaviour of JDK 
classes. It would be a shame for those tests to go away.

Regards, Peter



From kumar.x.srinivasan at oracle.com  Fri Jun 20 14:04:04 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 20 Jun 2014 07:04:04 -0700
Subject: Please review:  (JDK-8044866) Fix raw and unchecked lint warnings
	in asm
Message-ID: <53A43F54.2010200@oracle.com>

Hi Joe, all,

Please approve fix for removings warnings in asm, this is merely a mini 
refresh from
upstream sources, I have verified there are no more warnings in asm sources.

http://cr.openjdk.java.net/~ksrini/8044866/webrev/

Thanks
Kumar

PS: many thanks to Remi Forax for pushing these fixes  into the upstream 
source base.


From Alan.Bateman at oracle.com  Fri Jun 20 14:59:06 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jun 2014 15:59:06 +0100
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A43EF3.8000206@gmail.com>
References: 	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
	<53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com>
Message-ID: <53A44C3A.6000607@oracle.com>

On 20/06/2014 15:02, Peter Levart wrote:
>
> And, as Martin pointed out, it seems to be used for tests that 
> exercise particular responses from NameService API to test the 
> behaviour of JDK classes. It would be a shame for those tests to go away.
We've been talking about removing it for many years because it has been 
so troublesome. If we really need to having something for testing then I 
don't think it needs to be general purpose, we can get right of the 
lookup at least.

-Alan.


From joe.darcy at oracle.com  Fri Jun 20 15:21:29 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Jun 2014 08:21:29 -0700
Subject: Please review: (JDK-8044866) Fix raw and unchecked lint warnings
	in asm
In-Reply-To: <53A43F54.2010200@oracle.com>
References: <53A43F54.2010200@oracle.com>
Message-ID: <53A45179.3070702@oracle.com>

Hi Kumar,

Looks fine; thanks,

-Joe

On 06/20/2014 07:04 AM, Kumar Srinivasan wrote:
> Hi Joe, all,
>
> Please approve fix for removings warnings in asm, this is merely a 
> mini refresh from
> upstream sources, I have verified there are no more warnings in asm 
> sources.
>
> http://cr.openjdk.java.net/~ksrini/8044866/webrev/
>
> Thanks
> Kumar
>
> PS: many thanks to Remi Forax for pushing these fixes  into the 
> upstream source base.



From neil.toda at oracle.com  Fri Jun 20 16:50:30 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Fri, 20 Jun 2014 09:50:30 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A42284.4020707@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
Message-ID: <53A46656.3010105@oracle.com>


They should complain.  Thanks Zhengyu.  I'll make sure these are non-null.

-neil

On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
> Neil,
>
> Thanks for quick implementation.
>
> java.c:
>   Did not check return values of malloc(), I wonder if source code 
> analyzers will complain.
>
> -Zhengyu
>
> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>
>> Launcher support for modified Native Memory Tracking mechanism in JVM 
>> in JDK9.
>>
>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>> CCC         : http://ccc.us.oracle.com/8042469
>>
>> Thanks.
>>
>> -neil
>>
>



From henry.jen at oracle.com  Fri Jun 20 18:46:55 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 11:46:55 -0700
Subject: RFR: 8047721: @since should have JDK version
Message-ID: <53A4819F.5080906@oracle.com>

Hi,

Please review a trivial webrev to add JDK version to @since in a format 
as Mark suggested[1].

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

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html

Appened is the diff as in the webrev.

Cheers,
Henry


diff --git a/src/share/classes/java/lang/Package.java 
b/src/share/classes/java/lang/Package.java
--- a/src/share/classes/java/lang/Package.java
+++ b/src/share/classes/java/lang/Package.java
@@ -107,6 +107,7 @@
   * loader to be found.
   *
   * @see ClassLoader#definePackage
+ * @since 1.2
   */
  public class Package implements java.lang.reflect.AnnotatedElement {
      /**
diff --git a/src/share/classes/javax/crypto/CipherInputStream.java 
b/src/share/classes/javax/crypto/CipherInputStream.java
--- a/src/share/classes/javax/crypto/CipherInputStream.java
+++ b/src/share/classes/javax/crypto/CipherInputStream.java
@@ -170,7 +170,7 @@
       * @return  the next byte of data, or -1 if the end 
of the
       *          stream is reached.
       * @exception  IOException  if an I/O error occurs.
-     * @since JCE1.2
+     * @since 1.4, JCE1.2
       */
      public int read() throws IOException {
          if (ostart >= ofinish) {
@@ -196,7 +196,7 @@
       *             the stream has been reached.
       * @exception  IOException  if an I/O error occurs.
       * @see        java.io.InputStream#read(byte[], int, int)
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public int read(byte b[]) throws IOException {
          return read(b, 0, b.length);
@@ -217,7 +217,7 @@
       *             the stream has been reached.
       * @exception  IOException  if an I/O error occurs.
       * @see        java.io.InputStream#read()
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public int read(byte b[], int off, int len) throws IOException {
          if (ostart >= ofinish) {
@@ -254,7 +254,7 @@
       * @param      n the number of bytes to be skipped.
       * @return     the actual number of bytes skipped.
       * @exception  IOException  if an I/O error occurs.
-     * @since JCE1.2
+     * @since 1.4, JCE1.2
       */
      public long skip(long n) throws IOException {
          int available = ofinish - ostart;
@@ -277,7 +277,7 @@
       * @return     the number of bytes that can be read from this 
input stream
       *             without blocking.
       * @exception  IOException  if an I/O error occurs.
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public int available() throws IOException {
          return (ofinish - ostart);
@@ -292,7 +292,7 @@
       * stream.
       *
       * @exception  IOException  if an I/O error occurs.
-     * @since JCE1.2
+     * @since 1.4, JCE1.2
       */
      public void close() throws IOException {
          if (closed) {
@@ -321,7 +321,7 @@
       *          mark and reset methods.
       * @see     java.io.InputStream#mark(int)
       * @see     java.io.InputStream#reset()
-     * @since   JCE1.2
+     * @since   1.4, JCE1.2
       */
      public boolean markSupported() {
          return false;
diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java 
b/src/share/classes/javax/crypto/CipherOutputStream.java
--- a/src/share/classes/javax/crypto/CipherOutputStream.java
+++ b/src/share/classes/javax/crypto/CipherOutputStream.java
@@ -114,7 +114,7 @@
       *
       * @param      b   the byte.
       * @exception  IOException  if an I/O error occurs.
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public void write(int b) throws IOException {
          ibuffer[0] = (byte) b;
@@ -138,7 +138,7 @@
       * @exception  NullPointerException if b is null.
       * @exception  IOException  if an I/O error occurs.
       * @see        javax.crypto.CipherOutputStream#write(byte[], int, int)
-     * @since JCE1.2
+     * @since 1.4, JCE1.2
       */
      public void write(byte b[]) throws IOException {
          write(b, 0, b.length);
@@ -152,7 +152,7 @@
       * @param      off   the start offset in the data.
       * @param      len   the number of bytes to write.
       * @exception  IOException  if an I/O error occurs.
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public void write(byte b[], int off, int len) throws IOException {
          obuffer = cipher.update(b, off, len);
@@ -174,7 +174,7 @@
       * the cipher's block size, no bytes will be written out.
       *
       * @exception  IOException  if an I/O error occurs.
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public void flush() throws IOException {
          if (obuffer != null) {
@@ -198,7 +198,7 @@
       * stream.
       *
       * @exception  IOException  if an I/O error occurs.
-     * @since      JCE1.2
+     * @since      1.4, JCE1.2
       */
      public void close() throws IOException {
          if (closed) {
diff --git a/src/share/classes/javax/naming/InitialContext.java 
b/src/share/classes/javax/naming/InitialContext.java
--- a/src/share/classes/javax/naming/InitialContext.java
+++ b/src/share/classes/javax/naming/InitialContext.java
@@ -125,7 +125,7 @@
   * @see Context
   * @see NamingManager#setInitialContextFactoryBuilder
   *      NamingManager.setInitialContextFactoryBuilder
- * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
+ * @since 1.3, JNDI 1.1
   */

  public class InitialContext implements Context {



From pbenedict at apache.org  Fri Jun 20 20:01:46 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 20 Jun 2014 15:01:46 -0500
Subject: RFR: 8047721: @since should have JDK version
Message-ID: 

Henry,

I think "JCE1.2" should get the space to be "JCE 1.2" so it matches other
secondary versions like "JNDI 1.1" (last part of your patch). Or, you could
make that another cleanup in itself.

Cheers,
Paul


From henry.jen at oracle.com  Fri Jun 20 20:20:24 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 13:20:24 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: 
References: 
Message-ID: <53A49788.7000306@oracle.com>

You are absolutely right, I should have fixed it as I did for the rest.

Updated webrev can be found at

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

Cheers,
Henry

On 06/20/2014 01:01 PM, Paul Benedict wrote:
> Henry,
>
> I think "JCE1.2" should get the space to be "JCE 1.2" so it matches other
> secondary versions like "JNDI 1.1" (last part of your patch). Or, you could
> make that another cleanup in itself.
>
> Cheers,
> Paul
>


From joe.darcy at oracle.com  Fri Jun 20 20:25:42 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Jun 2014 13:25:42 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A49788.7000306@oracle.com>
References: 
	<53A49788.7000306@oracle.com>
Message-ID: <53A498C6.4020600@oracle.com>

Hi Henry,

For the Cipher{Input, Output}Stream classes, the class itself was added 
in 1.4 so it seems redundant to have the @since information on each 
method too. In other words, is preserving the @since JCE 1.2 information 
useful at this point?

Thanmks,

-Joe

On 06/20/2014 01:20 PM, Henry Jen wrote:
> You are absolutely right, I should have fixed it as I did for the rest.
>
> Updated webrev can be found at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/1/webrev/
>
> Cheers,
> Henry
>
> On 06/20/2014 01:01 PM, Paul Benedict wrote:
>> Henry,
>>
>> I think "JCE1.2" should get the space to be "JCE 1.2" so it matches 
>> other
>> secondary versions like "JNDI 1.1" (last part of your patch). Or, you 
>> could
>> make that another cleanup in itself.
>>
>> Cheers,
>> Paul
>>



From henry.jen at oracle.com  Fri Jun 20 20:42:43 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 13:42:43 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A498C6.4020600@oracle.com>
References: 	<53A49788.7000306@oracle.com>
	<53A498C6.4020600@oracle.com>
Message-ID: <53A49CC3.900@oracle.com>

I assume the reason to have those @since JCE tag is somehow we want to 
distinguish those APIs from the rest, thus I chose to preserve them.

If we agree it's not worth to keep, I can remove them.

Cheers,
Henry

On 06/20/2014 01:25 PM, Joe Darcy wrote:
> Hi Henry,
>
> For the Cipher{Input, Output}Stream classes, the class itself was added
> in 1.4 so it seems redundant to have the @since information on each
> method too. In other words, is preserving the @since JCE 1.2 information
> useful at this point?
>
> Thanmks,
>
> -Joe
>
> On 06/20/2014 01:20 PM, Henry Jen wrote:
>> You are absolutely right, I should have fixed it as I did for the rest.
>>
>> Updated webrev can be found at
>>
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/1/webrev/
>>
>> Cheers,
>> Henry
>>
>> On 06/20/2014 01:01 PM, Paul Benedict wrote:
>>> Henry,
>>>
>>> I think "JCE1.2" should get the space to be "JCE 1.2" so it matches
>>> other
>>> secondary versions like "JNDI 1.1" (last part of your patch). Or, you
>>> could
>>> make that another cleanup in itself.
>>>
>>> Cheers,
>>> Paul
>>>
>


From jason_mehrens at hotmail.com  Fri Jun 20 20:54:28 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 20 Jun 2014 15:54:28 -0500
Subject: Zombie FileHandler locks can exhaust all available log file locks.
Message-ID: 

Daniel, Jim,


In JDK8 the FileHandler file locking was changed to use FileChannel.open with CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due to safety concerns about writing to the same log file. The FileHandler has an upper bound of 100 as the number of file locks that can be attempted to be acquired. Given the right pattern, enough time, and enough failures it seems at it is possible for a program to end up in a state where the FileHandler is surrounded by zombie lock files refuses log or perform a clean up action. (A.K.A Farmer Rick Grimes). This means that the lck files have to manually be deleted or the FileHandler will just fail with an IOException every time it is created.


A simple test to emulate crashing is to run (JDK7 vs. JDK8) the following code twice without deleting the log and lck files:


public static void main(String[] args) throws Exception {
   System.out.println(System.getProperty("java.runtime.version"));
   ReferenceQueue q = new ReferenceQueue<>();

   for (int i=0; i<100; i++) {
     WeakReference h = new WeakReference<>(
     new FileHandler("./test_%u.log", 10000, 2, true), q);
     while (q.poll() != h) {
         System.runFinalization();
         System.gc();
         System.runFinalization();
         Thread.yield();
     }
  }

}


I understand that if you can't trust that the file locking always works then there isn't much that can be done. Leaving the number of locks as unbounded isn't really an option either. Seems like there should be a way to identify zombie lock files (ATOMIC_MOVE) and delete them.  Any thoughts on this?

The source discussion on this can be found at http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandler-in-java-8-broken


Regards,

Jason 		 	   		  

From mandy.chung at oracle.com  Fri Jun 20 20:57:57 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Jun 2014 13:57:57 -0700
Subject: Review request:  8044063: Remove com.sun.java.browser.* from
	jdk repo
In-Reply-To: <53A1DB4C.6030302@oracle.com>
References: <53A1D8D0.4060000@oracle.com> <53A1DA23.90107@oracle.com>
	<53A1DB4C.6030302@oracle.com>
Message-ID: <53A4A055.6030602@oracle.com>

Thanks for the review.  FYI.  I'm going to push this change to 
jdk9/client as this depends on the deploy change that is not integrated 
(just anxious to get this out of my queue rather than waiting it to show 
up in jdk9/dev).

Mandy

On 6/18/14 11:32 AM, Joe Darcy wrote:
> On 06/18/2014 11:27 AM, Alan Bateman wrote:
>> On 18/06/2014 19:22, Mandy Chung wrote:
>>> com.sun.java.browser.dom and com.sun.java.browser.net classes
>>> are legacy and only used by old plugin.  Time to remove them.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/
>>>
>> Good to see this being removed, the changes looks good to me.
>>
>> -Alan.
>
> Yes, good to see these legacy classes being removed!
>
> -Joe



From henry.jen at oracle.com  Fri Jun 20 21:28:41 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 14:28:41 -0700
Subject: RFR: 8047722: @since tag cleanup in corba
Message-ID: <53A4A789.6040609@oracle.com>

Hi,

Please review a trivial webrev for jdk9/corba that do the same @since 
tag normalization as in jdk9/jdk.

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

Cheers,
Henry


From henry.jen at oracle.com  Fri Jun 20 21:39:48 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 14:39:48 -0700
Subject: RFR: 8047723: @since tag cleanup in jaxp
Message-ID: <53A4AA24.40309@oracle.com>

Hi,

Please review a trivial webrev for jdk9/jaxp that do the same @since tag 
normalization as in jdk9/jdk.

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

I am not sure if there is another mailing list thatis more appropriate 
for this, if so, please direct me to the right ml. Thanks.

Cheers,
Henry


From henry.jen at oracle.com  Fri Jun 20 21:41:01 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 14:41:01 -0700
Subject: RFR: 8047724: @since tag cleanup in jaxws
Message-ID: <53A4AA6D.9060204@oracle.com>

Hi,

Please review a trivial webrev for jdk9/jaxws that do the same @since 
tag normalization as in jdk9/jdk.

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

I am not sure if there is another mailing list thatis more appropriate 
for this, if so, please direct me to the right ml. Thanks.

Cheers,
Henry


From huizhe.wang at oracle.com  Fri Jun 20 22:36:26 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 20 Jun 2014 15:36:26 -0700
Subject: RFR: 8047723: @since tag cleanup in jaxp
In-Reply-To: <53A4AA24.40309@oracle.com>
References: <53A4AA24.40309@oracle.com>
Message-ID: <53A4B76A.70608@oracle.com>

Hi Henry,

Is it possible to add to the @since tool/script to remove repository 
revision notes?  They appear in the API document as if they reflect 
meaningful "version". An example in 
http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html

   * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $


This is also true in packages not in the webrevs (ones that have proper 
@since tag), for example 
http://docs.oracle.com/javase/8/docs/api/javax/xml/datatype/DatatypeFactory.html

$Revision: 1.13 $, $Date: 2010/03/11 23:10:53 $


It looks good otherwise.

Thanks,
Joe

On 6/20/2014 2:39 PM, Henry Jen wrote:
> Hi,
>
> Please review a trivial webrev for jdk9/jaxp that do the same @since 
> tag normalization as in jdk9/jdk.
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/
>
> I am not sure if there is another mailing list thatis more appropriate 
> for this, if so, please direct me to the right ml. Thanks.
>
> Cheers,
> Henry



From joe.darcy at oracle.com  Fri Jun 20 23:04:14 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Jun 2014 16:04:14 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A46656.3010105@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com>
Message-ID: <53A4BDEE.8040305@oracle.com>

Memory allocation in the launcher should use one of the JLI_MemAlloc 
wrappers, if possible.

-Joe


On 06/20/2014 09:50 AM, Neil Toda wrote:
>
> They should complain.  Thanks Zhengyu.  I'll make sure these are 
> non-null.
>
> -neil
>
> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>> Neil,
>>
>> Thanks for quick implementation.
>>
>> java.c:
>>   Did not check return values of malloc(), I wonder if source code 
>> analyzers will complain.
>>
>> -Zhengyu
>>
>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>
>>> Launcher support for modified Native Memory Tracking mechanism in 
>>> JVM in JDK9.
>>>
>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>> CCC         : http://ccc.us.oracle.com/8042469
>>>
>>> Thanks.
>>>
>>> -neil
>>>
>>
>



From neil.toda at oracle.com  Fri Jun 20 23:27:08 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Fri, 20 Jun 2014 16:27:08 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A4BDEE.8040305@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
Message-ID: <53A4C34C.4010004@oracle.com>


Thanks Joe.  It would have checked for NULL for me.
I'll use the JLI wrapper.

-neil

On 6/20/2014 4:04 PM, Joe Darcy wrote:
> Memory allocation in the launcher should use one of the JLI_MemAlloc 
> wrappers, if possible.
>
> -Joe
>
>
> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>
>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>> non-null.
>>
>> -neil
>>
>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>> Neil,
>>>
>>> Thanks for quick implementation.
>>>
>>> java.c:
>>>   Did not check return values of malloc(), I wonder if source code 
>>> analyzers will complain.
>>>
>>> -Zhengyu
>>>
>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>
>>>> Launcher support for modified Native Memory Tracking mechanism in 
>>>> JVM in JDK9.
>>>>
>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>
>>>> Thanks.
>>>>
>>>> -neil
>>>>
>>>
>>
>



From kumar.x.srinivasan at oracle.com  Fri Jun 20 23:45:29 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 20 Jun 2014 16:45:29 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A4C34C.4010004@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
	<53A4C34C.4010004@oracle.com>
Message-ID: <53A4C799.900@oracle.com>

Neil,

Generally looks good, yes JLI_* functions must be used, I missed that one.
Are you going to post another iteration ?

Kumar

On 6/20/2014 4:27 PM, Neil Toda wrote:
>
> Thanks Joe.  It would have checked for NULL for me.
> I'll use the JLI wrapper.
>
> -neil
>
> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>> Memory allocation in the launcher should use one of the JLI_MemAlloc 
>> wrappers, if possible.
>>
>> -Joe
>>
>>
>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>
>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>> non-null.
>>>
>>> -neil
>>>
>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>> Neil,
>>>>
>>>> Thanks for quick implementation.
>>>>
>>>> java.c:
>>>>   Did not check return values of malloc(), I wonder if source code 
>>>> analyzers will complain.
>>>>
>>>> -Zhengyu
>>>>
>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>
>>>>> Launcher support for modified Native Memory Tracking mechanism in 
>>>>> JVM in JDK9.
>>>>>
>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -neil
>>>>>
>>>>
>>>
>>
>



From neil.toda at oracle.com  Fri Jun 20 23:55:53 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Fri, 20 Jun 2014 16:55:53 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A4C799.900@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
	<53A4C34C.4010004@oracle.com> <53A4C799.900@oracle.com>
Message-ID: <53A4CA09.5030404@oracle.com>


Thanks Kumar for your other finds.  I'll spin another webrev this 
evening and post
it with the fixes to address everyone's points.

Thanks.

-neil

On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
> Neil,
>
> Generally looks good, yes JLI_* functions must be used, I missed that 
> one.
> Are you going to post another iteration ?
>
> Kumar
>
> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>
>> Thanks Joe.  It would have checked for NULL for me.
>> I'll use the JLI wrapper.
>>
>> -neil
>>
>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>> Memory allocation in the launcher should use one of the JLI_MemAlloc 
>>> wrappers, if possible.
>>>
>>> -Joe
>>>
>>>
>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>
>>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>>> non-null.
>>>>
>>>> -neil
>>>>
>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>> Neil,
>>>>>
>>>>> Thanks for quick implementation.
>>>>>
>>>>> java.c:
>>>>>   Did not check return values of malloc(), I wonder if source code 
>>>>> analyzers will complain.
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>
>>>>>> Launcher support for modified Native Memory Tracking mechanism in 
>>>>>> JVM in JDK9.
>>>>>>
>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>
>>>>
>>>
>>
>



From henry.jen at oracle.com  Sat Jun 21 00:24:08 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 20 Jun 2014 17:24:08 -0700
Subject: RFR: 8047723: @since tag cleanup in jaxp
In-Reply-To: <53A4B76A.70608@oracle.com>
References: <53A4AA24.40309@oracle.com> <53A4B76A.70608@oracle.com>
Message-ID: <53A4D0A8.5040104@oracle.com>

Looks like it's pretty easy to do a find and replace in files in jaxp 
folder. If this is desired, we can do it in a separate webrev to be 
clear on changeset history?

Cheers,
Henry

On 06/20/2014 03:36 PM, huizhe wang wrote:
> Hi Henry,
>
> Is it possible to add to the @since tool/script to remove repository
> revision notes?  They appear in the API document as if they reflect
> meaningful "version". An example in
> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html
>
>
>    * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $
>
>
> This is also true in packages not in the webrevs (ones that have proper
> @since tag), for example
> http://docs.oracle.com/javase/8/docs/api/javax/xml/datatype/DatatypeFactory.html
>
>
> $Revision: 1.13 $, $Date: 2010/03/11 23:10:53 $
>
>
> It looks good otherwise.
>
> Thanks,
> Joe
>
> On 6/20/2014 2:39 PM, Henry Jen wrote:
>> Hi,
>>
>> Please review a trivial webrev for jdk9/jaxp that do the same @since
>> tag normalization as in jdk9/jdk.
>>
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/
>>
>> I am not sure if there is another mailing list thatis more appropriate
>> for this, if so, please direct me to the right ml. Thanks.
>>
>> Cheers,
>> Henry
>


From huizhe.wang at oracle.com  Sat Jun 21 01:01:48 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 20 Jun 2014 18:01:48 -0700
Subject: RFR: 8047723: @since tag cleanup in jaxp
In-Reply-To: <53A4D0A8.5040104@oracle.com>
References: <53A4AA24.40309@oracle.com> <53A4B76A.70608@oracle.com>
	<53A4D0A8.5040104@oracle.com>
Message-ID: <53A4D97C.9070104@oracle.com>


On 6/20/2014 5:24 PM, Henry Jen wrote:
> Looks like it's pretty easy to do a find and replace in files in jaxp 
> folder. If this is desired, we can do it in a separate webrev to be 
> clear on changeset history?

Sounds good. Then, your webrev is fine with me.

Cheers,
Joe

>
> Cheers,
> Henry
>
> On 06/20/2014 03:36 PM, huizhe wang wrote:
>> Hi Henry,
>>
>> Is it possible to add to the @since tool/script to remove repository
>> revision notes?  They appear in the API document as if they reflect
>> meaningful "version". An example in
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html 
>>
>>
>>
>>    * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $
>>
>>
>> This is also true in packages not in the webrevs (ones that have proper
>> @since tag), for example
>> http://docs.oracle.com/javase/8/docs/api/javax/xml/datatype/DatatypeFactory.html 
>>
>>
>>
>> $Revision: 1.13 $, $Date: 2010/03/11 23:10:53 $
>>
>>
>> It looks good otherwise.
>>
>> Thanks,
>> Joe
>>
>> On 6/20/2014 2:39 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a trivial webrev for jdk9/jaxp that do the same @since
>>> tag normalization as in jdk9/jdk.
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/
>>>
>>> I am not sure if there is another mailing list thatis more appropriate
>>> for this, if so, please direct me to the right ml. Thanks.
>>>
>>> Cheers,
>>> Henry
>>



From huizhe.wang at oracle.com  Sat Jun 21 02:36:29 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 20 Jun 2014 19:36:29 -0700
Subject: RFR JDK-5077522 : Duration.compare incorrect for some values
In-Reply-To: <53A406C0.2060709@oracle.com>
References: <53A094DA.1000905@oracle.com> <53A406C0.2060709@oracle.com>
Message-ID: <53A4EFAD.3050000@oracle.com>

Thanks Daniel, Lance.

On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> Thanks for the detailed explanation.
> It really helps reviewing the fix!

Glad to know it helps. I thought this part of spec could be unfamiliar 
to people.

>
> This looks reasonable to me. One minor nit is that you
> could turn:
>
> 769         BigInteger maxintAsBigInteger = BigInteger.valueOf((long) 
> Integer.MAX_VALUE);

Good catch!  I was going to do so but then forgot.

I also refactored the check method so that the checks can be done in one 
loop: 24 lines of code instead of the original 170. I feel good :-)

The other changes are purely clean-up and in one case, JavaDoc.

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

Best regards,
Joe


>
> into a static final constant in the class.
>
> best regards,
>
> -- daniel
>
> On 6/17/14 9:19 PM, huizhe wang wrote:
>> Hi,
>>
>> This is a long time compatibility issue: Duration.compare returns equal
>> for INDETERMINATE relations defined in XML Schema standard
>> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
>> following table:
>>
>>      Relation
>> P*1Y*     > P*364D*     <> P*365D*         <> P*366D*     < P*367D*
>> P*1M*     > P*27D*     <> P*28D*     <> P*29D*     <> P*30D*     <>
>> P*31D*     < P*32D*
>> P*5M*     > P*149D*     <> P*150D*     <> P*151D*     <> P*152D*     <>
>> P*153D*     < P*154D*
>>
>>
>>
>> The order-relation of two Duratoin values x and y is x < y iff s+x < s+y
>> for each qualified datetime s listed below:
>>
>>   * 1696-09-01T00:00:00Z
>>   * 1697-02-01T00:00:00Z
>>   * 1903-03-01T00:00:00Z
>>   * 1903-07-01T00:00:00Z
>>
>>
>> The original implementation used Unix epoch, that is, 00:00:00 UTC on 1
>> January 1970, as s in the above calculation which violated the above
>> specification. A patch during JDK 6 development added correct
>> implementation of the spec, but it was unfortunately added after the
>> original calculation using Epoch time.
>>
>> *The fix to the issue therefore is simply removing the calculation using
>> Epoch time.* I also consolidated the tedious max field value checks into
>> a method called checkMaxValue.
>>
>> *Patch:*
>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>>
>> Test:
>> testCompareWithInderterminateRelation: this is a copy of the JCK test
>> that tests INDETERMINATE relations.
>> testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1
>> second to the original test cases. For example, to the original test:
>> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
>> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>>
>> Below is the test result:
>> Comparing P1Y and P365D: INDETERMINATE
>> Comparing P1Y and P366D: INDETERMINATE
>> Comparing P1M and P28D: INDETERMINATE
>> Comparing P1M and P29D: INDETERMINATE
>> Comparing P1M and P30D: INDETERMINATE
>> Comparing P1M and P31D: INDETERMINATE
>> Comparing P5M and P150D: INDETERMINATE
>> Comparing P5M and P151D: INDETERMINATE
>> Comparing P5M and P152D: INDETERMINATE
>> Comparing P5M and P153D: INDETERMINATE
>> Comparing PT2419200S and P1M: INDETERMINATE
>> Comparing PT2678400S and P1M: INDETERMINATE
>> Comparing PT31536000S and P1Y: INDETERMINATE
>> Comparing PT31622400S and P1Y: INDETERMINATE
>> Comparing PT525600M and P1Y: INDETERMINATE
>> Comparing PT527040M and P1Y: INDETERMINATE
>> Comparing PT8760H and P1Y: INDETERMINATE
>> Comparing PT8784H and P1Y: INDETERMINATE
>> Comparing P365D and P1Y: INDETERMINATE
>> Comparing P1Y and P364D: expected: GREATER actual: GREATER
>> Comparing P1Y and P367D: expected: LESSER actual: LESSER
>> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
>> Comparing P1M and P27D: expected: GREATER actual: GREATER
>> Comparing P1M and P32D: expected: LESSER actual: LESSER
>> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
>> Comparing P5M and P149D: expected: GREATER actual: GREATER
>> Comparing P5M and P154D: expected: LESSER actual: LESSER
>> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
>> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
>> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
>> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
>> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
>> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
>> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
>> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
>> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>>
>> Number of tests passed: 36
>> Number of tests failed: 0
>>
>> Thanks,
>> Joe
>>
>



From daniel.fuchs at oracle.com  Sat Jun 21 08:27:25 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 21 Jun 2014 10:27:25 +0200
Subject: RFR JDK-5077522 : Duration.compare incorrect for some values
In-Reply-To: <53A4EFAD.3050000@oracle.com>
References: <53A094DA.1000905@oracle.com> <53A406C0.2060709@oracle.com>
	<53A4EFAD.3050000@oracle.com>
Message-ID: <53A541ED.4090303@oracle.com>

Thanks Joe!

This is much cleaner indeed :-)

-- daniel

On 6/21/14 4:36 AM, huizhe wang wrote:
> Thanks Daniel, Lance.
>
> On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
>> Hi Joe,
>>
>> Thanks for the detailed explanation.
>> It really helps reviewing the fix!
>
> Glad to know it helps. I thought this part of spec could be unfamiliar 
> to people.
>
>>
>> This looks reasonable to me. One minor nit is that you
>> could turn:
>>
>> 769         BigInteger maxintAsBigInteger = BigInteger.valueOf((long) 
>> Integer.MAX_VALUE);
>
> Good catch!  I was going to do so but then forgot.
>
> I also refactored the check method so that the checks can be done in 
> one loop: 24 lines of code instead of the original 170. I feel good :-)
>
> The other changes are purely clean-up and in one case, JavaDoc.
>
> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>
> Best regards,
> Joe
>
>
>>
>> into a static final constant in the class.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 6/17/14 9:19 PM, huizhe wang wrote:
>>> Hi,
>>>
>>> This is a long time compatibility issue: Duration.compare returns equal
>>> for INDETERMINATE relations defined in XML Schema standard
>>> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
>>> following table:
>>>
>>>      Relation
>>> P*1Y*     > P*364D*     <> P*365D*         <> P*366D*     < P*367D*
>>> P*1M*     > P*27D*     <> P*28D*     <> P*29D*     <> P*30D*     <>
>>> P*31D*     < P*32D*
>>> P*5M*     > P*149D*     <> P*150D*     <> P*151D*     <> P*152D*     <>
>>> P*153D*     < P*154D*
>>>
>>>
>>>
>>> The order-relation of two Duratoin values x and y is x < y iff s+x < 
>>> s+y
>>> for each qualified datetime s listed below:
>>>
>>>   * 1696-09-01T00:00:00Z
>>>   * 1697-02-01T00:00:00Z
>>>   * 1903-03-01T00:00:00Z
>>>   * 1903-07-01T00:00:00Z
>>>
>>>
>>> The original implementation used Unix epoch, that is, 00:00:00 UTC on 1
>>> January 1970, as s in the above calculation which violated the above
>>> specification. A patch during JDK 6 development added correct
>>> implementation of the spec, but it was unfortunately added after the
>>> original calculation using Epoch time.
>>>
>>> *The fix to the issue therefore is simply removing the calculation 
>>> using
>>> Epoch time.* I also consolidated the tedious max field value checks 
>>> into
>>> a method called checkMaxValue.
>>>
>>> *Patch:*
>>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>>>
>>> Test:
>>> testCompareWithInderterminateRelation: this is a copy of the JCK test
>>> that tests INDETERMINATE relations.
>>> testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1
>>> second to the original test cases. For example, to the original test:
>>> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
>>> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>>>
>>> Below is the test result:
>>> Comparing P1Y and P365D: INDETERMINATE
>>> Comparing P1Y and P366D: INDETERMINATE
>>> Comparing P1M and P28D: INDETERMINATE
>>> Comparing P1M and P29D: INDETERMINATE
>>> Comparing P1M and P30D: INDETERMINATE
>>> Comparing P1M and P31D: INDETERMINATE
>>> Comparing P5M and P150D: INDETERMINATE
>>> Comparing P5M and P151D: INDETERMINATE
>>> Comparing P5M and P152D: INDETERMINATE
>>> Comparing P5M and P153D: INDETERMINATE
>>> Comparing PT2419200S and P1M: INDETERMINATE
>>> Comparing PT2678400S and P1M: INDETERMINATE
>>> Comparing PT31536000S and P1Y: INDETERMINATE
>>> Comparing PT31622400S and P1Y: INDETERMINATE
>>> Comparing PT525600M and P1Y: INDETERMINATE
>>> Comparing PT527040M and P1Y: INDETERMINATE
>>> Comparing PT8760H and P1Y: INDETERMINATE
>>> Comparing PT8784H and P1Y: INDETERMINATE
>>> Comparing P365D and P1Y: INDETERMINATE
>>> Comparing P1Y and P364D: expected: GREATER actual: GREATER
>>> Comparing P1Y and P367D: expected: LESSER actual: LESSER
>>> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
>>> Comparing P1M and P27D: expected: GREATER actual: GREATER
>>> Comparing P1M and P32D: expected: LESSER actual: LESSER
>>> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
>>> Comparing P5M and P149D: expected: GREATER actual: GREATER
>>> Comparing P5M and P154D: expected: LESSER actual: LESSER
>>> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
>>> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
>>> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
>>> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
>>> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
>>> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
>>> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
>>> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
>>> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>>>
>>> Number of tests passed: 36
>>> Number of tests failed: 0
>>>
>>> Thanks,
>>> Joe
>>>
>>
>



From lance.andersen at oracle.com  Sat Jun 21 10:32:09 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Sat, 21 Jun 2014 06:32:09 -0400
Subject: RFR JDK-5077522 : Duration.compare incorrect for some values
In-Reply-To: <53A541ED.4090303@oracle.com>
References: <53A094DA.1000905@oracle.com> <53A406C0.2060709@oracle.com>
	<53A4EFAD.3050000@oracle.com> <53A541ED.4090303@oracle.com>
Message-ID: <13FBA989-0946-483D-AE6A-D6E6DF7824F8@oracle.com>

Agree this is better and cleaner!


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 Jun 21, 2014, at 4:27 AM, Daniel Fuchs  wrote:

> Thanks Joe!
> 
> This is much cleaner indeed :-)
> 
> -- daniel
> 
> On 6/21/14 4:36 AM, huizhe wang wrote:
>> Thanks Daniel, Lance.
>> 
>> On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
>>> Hi Joe,
>>> 
>>> Thanks for the detailed explanation.
>>> It really helps reviewing the fix!
>> 
>> Glad to know it helps. I thought this part of spec could be unfamiliar to people.
>> 
>>> 
>>> This looks reasonable to me. One minor nit is that you
>>> could turn:
>>> 
>>> 769         BigInteger maxintAsBigInteger = BigInteger.valueOf((long) Integer.MAX_VALUE);
>> 
>> Good catch!  I was going to do so but then forgot.
>> 
>> I also refactored the check method so that the checks can be done in one loop: 24 lines of code instead of the original 170. I feel good :-)
>> 
>> The other changes are purely clean-up and in one case, JavaDoc.
>> 
>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>> 
>> Best regards,
>> Joe
>> 
>> 
>>> 
>>> into a static final constant in the class.
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>> On 6/17/14 9:19 PM, huizhe wang wrote:
>>>> Hi,
>>>> 
>>>> This is a long time compatibility issue: Duration.compare returns equal
>>>> for INDETERMINATE relations defined in XML Schema standard
>>>> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
>>>> following table:
>>>> 
>>>>     Relation
>>>> P*1Y*     > P*364D*     <> P*365D*         <> P*366D*     < P*367D*
>>>> P*1M*     > P*27D*     <> P*28D*     <> P*29D*     <> P*30D*     <>
>>>> P*31D*     < P*32D*
>>>> P*5M*     > P*149D*     <> P*150D*     <> P*151D*     <> P*152D*     <>
>>>> P*153D*     < P*154D*
>>>> 
>>>> 
>>>> 
>>>> The order-relation of two Duratoin values x and y is x < y iff s+x < s+y
>>>> for each qualified datetime s listed below:
>>>> 
>>>>  * 1696-09-01T00:00:00Z
>>>>  * 1697-02-01T00:00:00Z
>>>>  * 1903-03-01T00:00:00Z
>>>>  * 1903-07-01T00:00:00Z
>>>> 
>>>> 
>>>> The original implementation used Unix epoch, that is, 00:00:00 UTC on 1
>>>> January 1970, as s in the above calculation which violated the above
>>>> specification. A patch during JDK 6 development added correct
>>>> implementation of the spec, but it was unfortunately added after the
>>>> original calculation using Epoch time.
>>>> 
>>>> *The fix to the issue therefore is simply removing the calculation using
>>>> Epoch time.* I also consolidated the tedious max field value checks into
>>>> a method called checkMaxValue.
>>>> 
>>>> *Patch:*
>>>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>>>> 
>>>> Test:
>>>> testCompareWithInderterminateRelation: this is a copy of the JCK test
>>>> that tests INDETERMINATE relations.
>>>> testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1
>>>> second to the original test cases. For example, to the original test:
>>>> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
>>>> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>>>> 
>>>> Below is the test result:
>>>> Comparing P1Y and P365D: INDETERMINATE
>>>> Comparing P1Y and P366D: INDETERMINATE
>>>> Comparing P1M and P28D: INDETERMINATE
>>>> Comparing P1M and P29D: INDETERMINATE
>>>> Comparing P1M and P30D: INDETERMINATE
>>>> Comparing P1M and P31D: INDETERMINATE
>>>> Comparing P5M and P150D: INDETERMINATE
>>>> Comparing P5M and P151D: INDETERMINATE
>>>> Comparing P5M and P152D: INDETERMINATE
>>>> Comparing P5M and P153D: INDETERMINATE
>>>> Comparing PT2419200S and P1M: INDETERMINATE
>>>> Comparing PT2678400S and P1M: INDETERMINATE
>>>> Comparing PT31536000S and P1Y: INDETERMINATE
>>>> Comparing PT31622400S and P1Y: INDETERMINATE
>>>> Comparing PT525600M and P1Y: INDETERMINATE
>>>> Comparing PT527040M and P1Y: INDETERMINATE
>>>> Comparing PT8760H and P1Y: INDETERMINATE
>>>> Comparing PT8784H and P1Y: INDETERMINATE
>>>> Comparing P365D and P1Y: INDETERMINATE
>>>> Comparing P1Y and P364D: expected: GREATER actual: GREATER
>>>> Comparing P1Y and P367D: expected: LESSER actual: LESSER
>>>> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
>>>> Comparing P1M and P27D: expected: GREATER actual: GREATER
>>>> Comparing P1M and P32D: expected: LESSER actual: LESSER
>>>> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
>>>> Comparing P5M and P149D: expected: GREATER actual: GREATER
>>>> Comparing P5M and P154D: expected: LESSER actual: LESSER
>>>> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
>>>> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
>>>> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
>>>> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
>>>> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
>>>> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>>>> 
>>>> Number of tests passed: 36
>>>> Number of tests failed: 0
>>>> 
>>>> Thanks,
>>>> Joe
> 


From andrej.golovnin at gmail.com  Sat Jun 21 22:00:41 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Sun, 22 Jun 2014 00:00:41 +0200
Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection
In-Reply-To: <20140613084650.GA24337@oracle.com>
References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com>
	
	
	<55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com>
	<2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com>
	<237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com>
	
	<20140613084650.GA24337@oracle.com>
Message-ID: 

Hi Joel,

sorry for late response. I was too busy with other things.

Again, I have very limited time to work on this. We are looking into
> other changes in reflection that may or may not change and/or supersede
> this work.


Could you please share the details? I'm just curious.


> I think this would be a fine contribution to get in to 9, a
> good baseline to build further work upon, but the scope has to be
> limited. Given the risk-reward here my bar for accepting this is quite
> high.
>
> I'm looking forward to a rewritten test and some coverage information.
>

I have changed the test TestMethodReflectValueOf as you suggested and I
have changed the summary of both tests too. You will find the changes in
the attached patch. Here is the new webrev: https://db.tt/wQBLVceA

And here is the coverage report in the HTML format:

https://db.tt/JTZjpnMM

Let me know if you need the coverage report in the text format.

Best regards,
Andrej Golovnin
-------------- next part --------------
diff --git a/src/share/classes/sun/reflect/AccessorGenerator.java b/src/share/classes/sun/reflect/AccessorGenerator.java
--- a/src/share/classes/sun/reflect/AccessorGenerator.java
+++ b/src/share/classes/sun/reflect/AccessorGenerator.java
@@ -69,33 +69,34 @@
     protected short codeIdx;
     protected short exceptionsIdx;
     // Boxing
+    protected short valueOfIdx;
     protected short booleanIdx;
-    protected short booleanCtorIdx;
+    protected short booleanBoxIdx;
     protected short booleanUnboxIdx;
     protected short byteIdx;
-    protected short byteCtorIdx;
+    protected short byteBoxIdx;
     protected short byteUnboxIdx;
     protected short characterIdx;
-    protected short characterCtorIdx;
+    protected short characterBoxIdx;
     protected short characterUnboxIdx;
     protected short doubleIdx;
-    protected short doubleCtorIdx;
+    protected short doubleBoxIdx;
     protected short doubleUnboxIdx;
     protected short floatIdx;
-    protected short floatCtorIdx;
+    protected short floatBoxIdx;
     protected short floatUnboxIdx;
     protected short integerIdx;
-    protected short integerCtorIdx;
+    protected short integerBoxIdx;
     protected short integerUnboxIdx;
     protected short longIdx;
-    protected short longCtorIdx;
+    protected short longBoxIdx;
     protected short longUnboxIdx;
     protected short shortIdx;
-    protected short shortCtorIdx;
+    protected short shortBoxIdx;
     protected short shortUnboxIdx;
 
     protected final short NUM_COMMON_CPOOL_ENTRIES = (short) 30;
-    protected final short NUM_BOXING_CPOOL_ENTRIES = (short) 72;
+    protected final short NUM_BOXING_CPOOL_ENTRIES = (short) 73;
 
     // Requires that superClass has been set up
     protected void emitCommonConstantPoolEntries() {
@@ -181,9 +182,10 @@
     /** Constant pool entries required to be able to box/unbox primitive
         types. Note that we don't emit these if we don't need them. */
     protected void emitBoxingContantPoolEntries() {
+        //  *  [UTF-8] "valueOf"
         //  *  [UTF-8] "java/lang/Boolean"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(Z)V"
+        //  *  [UTF-8] "(Z)Ljava/lang/Boolean;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "booleanValue"
@@ -192,7 +194,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Byte"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(B)V"
+        //  *  [UTF-8] "(B)Ljava/lang/Byte;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "byteValue"
@@ -201,7 +203,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Character"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(C)V"
+        //  *  [UTF-8] "(C)Ljava/lang/Character;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "charValue"
@@ -210,7 +212,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Double"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(D)V"
+        //  *  [UTF-8] "(D)Ljava/lang/Double;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "doubleValue"
@@ -219,7 +221,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Float"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(F)V"
+        //  *  [UTF-8] "(F)Ljava/lang/Float;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "floatValue"
@@ -228,7 +230,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Integer"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(I)V"
+        //  *  [UTF-8] "(I)Ljava/lang/Integer;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "intValue"
@@ -237,7 +239,7 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Long"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(J)V"
+        //  *  [UTF-8] "(J)Ljava/lang/Long;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "longValue"
@@ -246,21 +248,26 @@
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "java/lang/Short"
         //  *  [CONSTANT_Class_info] for above
-        //  *  [UTF-8] "(S)V"
+        //  *  [UTF-8] "(S)Ljava/lang/Short;"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
         //  *  [UTF-8] "shortValue"
         //  *  [UTF-8] "()S"
         //  *  [CONSTANT_NameAndType_info] for above
         //  *  [CONSTANT_Methodref_info] for above
+
+        // valueOf-method name
+        asm.emitConstantPoolUTF8("valueOf");
+        valueOfIdx = asm.cpi();
+
         // Boolean
         asm.emitConstantPoolUTF8("java/lang/Boolean");
         asm.emitConstantPoolClass(asm.cpi());
         booleanIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(Z)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(Z)Ljava/lang/Boolean;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        booleanCtorIdx = asm.cpi();
+        booleanBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("booleanValue");
         asm.emitConstantPoolUTF8("()Z");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -271,10 +278,10 @@
         asm.emitConstantPoolUTF8("java/lang/Byte");
         asm.emitConstantPoolClass(asm.cpi());
         byteIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(B)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(B)Ljava/lang/Byte;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        byteCtorIdx = asm.cpi();
+        byteBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("byteValue");
         asm.emitConstantPoolUTF8("()B");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -285,10 +292,10 @@
         asm.emitConstantPoolUTF8("java/lang/Character");
         asm.emitConstantPoolClass(asm.cpi());
         characterIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(C)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(C)Ljava/lang/Character;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        characterCtorIdx = asm.cpi();
+        characterBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("charValue");
         asm.emitConstantPoolUTF8("()C");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -299,10 +306,10 @@
         asm.emitConstantPoolUTF8("java/lang/Double");
         asm.emitConstantPoolClass(asm.cpi());
         doubleIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(D)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(D)Ljava/lang/Double;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        doubleCtorIdx = asm.cpi();
+        doubleBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("doubleValue");
         asm.emitConstantPoolUTF8("()D");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -313,10 +320,10 @@
         asm.emitConstantPoolUTF8("java/lang/Float");
         asm.emitConstantPoolClass(asm.cpi());
         floatIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(F)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(F)Ljava/lang/Float;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        floatCtorIdx = asm.cpi();
+        floatBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("floatValue");
         asm.emitConstantPoolUTF8("()F");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -327,10 +334,10 @@
         asm.emitConstantPoolUTF8("java/lang/Integer");
         asm.emitConstantPoolClass(asm.cpi());
         integerIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(I)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(I)Ljava/lang/Integer;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        integerCtorIdx = asm.cpi();
+        integerBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("intValue");
         asm.emitConstantPoolUTF8("()I");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -341,10 +348,10 @@
         asm.emitConstantPoolUTF8("java/lang/Long");
         asm.emitConstantPoolClass(asm.cpi());
         longIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(J)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(J)Ljava/lang/Long;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        longCtorIdx = asm.cpi();
+        longBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("longValue");
         asm.emitConstantPoolUTF8("()J");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -355,10 +362,10 @@
         asm.emitConstantPoolUTF8("java/lang/Short");
         asm.emitConstantPoolClass(asm.cpi());
         shortIdx = asm.cpi();
-        asm.emitConstantPoolUTF8("(S)V");
-        asm.emitConstantPoolNameAndType(initIdx, asm.cpi());
+        asm.emitConstantPoolUTF8("(S)Ljava/lang/Short;");
+        asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi());
         asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi());
-        shortCtorIdx = asm.cpi();
+        shortBoxIdx = asm.cpi();
         asm.emitConstantPoolUTF8("shortValue");
         asm.emitConstantPoolUTF8("()S");
         asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi());
@@ -515,23 +522,23 @@
         throw new InternalError("Should have found primitive type");
     }
 
-    protected short ctorIndexForPrimitiveType(Class type) {
+    protected short boxingMethodForPrimitiveType(Class type) {
         if (type == Boolean.TYPE) {
-            return booleanCtorIdx;
+            return booleanBoxIdx;
         } else if (type == Byte.TYPE) {
-            return byteCtorIdx;
+            return byteBoxIdx;
         } else if (type == Character.TYPE) {
-            return characterCtorIdx;
+            return characterBoxIdx;
         } else if (type == Double.TYPE) {
-            return doubleCtorIdx;
+            return doubleBoxIdx;
         } else if (type == Float.TYPE) {
-            return floatCtorIdx;
+            return floatBoxIdx;
         } else if (type == Integer.TYPE) {
-            return integerCtorIdx;
+            return integerBoxIdx;
         } else if (type == Long.TYPE) {
-            return longCtorIdx;
+            return longBoxIdx;
         } else if (type == Short.TYPE) {
-            return shortCtorIdx;
+            return shortBoxIdx;
         }
         throw new InternalError("Should have found primitive type");
     }
diff --git a/src/share/classes/sun/reflect/MethodAccessorGenerator.java b/src/share/classes/sun/reflect/MethodAccessorGenerator.java
--- a/src/share/classes/sun/reflect/MethodAccessorGenerator.java
+++ b/src/share/classes/sun/reflect/MethodAccessorGenerator.java
@@ -660,9 +660,9 @@
         if (!isConstructor) {
             // Box return value if necessary
             if (isPrimitive(returnType)) {
-                cb.opc_invokespecial(ctorIndexForPrimitiveType(returnType),
-                                     typeSizeInStackSlots(returnType),
-                                     0);
+                cb.opc_invokestatic(boxingMethodForPrimitiveType(returnType),
+                                    typeSizeInStackSlots(returnType),
+                                    0);
             } else if (returnType == Void.TYPE) {
                 cb.opc_aconst_null();
             }
diff --git a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Boolean(getBoolean(obj));
+        return Boolean.valueOf(getBoolean(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Byte(getByte(obj));
+        return Byte.valueOf(getByte(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Character(getChar(obj));
+        return Character.valueOf(getChar(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Double(getDouble(obj));
+        return Double.valueOf(getDouble(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Float(getFloat(obj));
+        return Float.valueOf(getFloat(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Integer(getInt(obj));
+        return Integer.valueOf(getInt(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Long(getLong(obj));
+        return Long.valueOf(getLong(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Boolean(getBoolean(obj));
+        return Boolean.valueOf(getBoolean(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Byte(getByte(obj));
+        return Byte.valueOf(getByte(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Character(getChar(obj));
+        return Character.valueOf(getChar(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Double(getDouble(obj));
+        return Double.valueOf(getDouble(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Float(getFloat(obj));
+        return Float.valueOf(getFloat(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Integer(getInt(obj));
+        return Integer.valueOf(getInt(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Long(getLong(obj));
+        return Long.valueOf(getLong(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Short(getShort(obj));
+        return Short.valueOf(getShort(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Boolean(getBoolean(obj));
+        return Boolean.valueOf(getBoolean(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Byte(getByte(obj));
+        return Byte.valueOf(getByte(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Character(getChar(obj));
+        return Character.valueOf(getChar(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Double(getDouble(obj));
+        return Double.valueOf(getDouble(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Float(getFloat(obj));
+        return Float.valueOf(getFloat(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Integer(getInt(obj));
+        return Integer.valueOf(getInt(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Long(getLong(obj));
+        return Long.valueOf(getLong(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java
@@ -35,7 +35,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Short(getShort(obj));
+        return Short.valueOf(getShort(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Short(getShort(obj));
+        return Short.valueOf(getShort(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Boolean(getBoolean(obj));
+        return Boolean.valueOf(getBoolean(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Byte(getByte(obj));
+        return Byte.valueOf(getByte(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Character(getChar(obj));
+        return Character.valueOf(getChar(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Double(getDouble(obj));
+        return Double.valueOf(getDouble(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Float(getFloat(obj));
+        return Float.valueOf(getFloat(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Integer(getInt(obj));
+        return Integer.valueOf(getInt(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Long(getLong(obj));
+        return Long.valueOf(getLong(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java
--- a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java
+++ b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java
@@ -33,7 +33,7 @@
     }
 
     public Object get(Object obj) throws IllegalArgumentException {
-        return new Short(getShort(obj));
+        return Short.valueOf(getShort(obj));
     }
 
     public boolean getBoolean(Object obj) throws IllegalArgumentException {
diff --git a/test/java/lang/reflect/Field/TestFieldReflectValueOf.java b/test/java/lang/reflect/Field/TestFieldReflectValueOf.java
new file mode 100644
--- /dev/null
+++ b/test/java/lang/reflect/Field/TestFieldReflectValueOf.java
@@ -0,0 +1,173 @@
+/*
+ * 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.
+ *
+ * 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.
+ */
+
+/*
+ * @test
+ * @bug 5043030
+ * @summary Verify that the method java.lang.reflect.Field.get(Object) makes
+ *          use of the same caching mechanism as used for autoboxing
+ *          when wrapping values of the primitive types.
+ * @author Andrej Golovnin
+ */
+
+import java.lang.reflect.Field;
+
+public class TestFieldReflectValueOf {
+
+    @SuppressWarnings("unused")
+    private static boolean booleanStaticField;
+    @SuppressWarnings("unused")
+    private static byte byteStaticField;
+    @SuppressWarnings("unused")
+    private static char charStaticField;
+    @SuppressWarnings("unused")
+    private static int intStaticField;
+    @SuppressWarnings("unused")
+    private static long longStaticField;
+    @SuppressWarnings("unused")
+    private static short shortStaticField;
+
+    @SuppressWarnings("unused")
+    private static volatile boolean booleanStaticVolatileField;
+    @SuppressWarnings("unused")
+    private static volatile byte byteStaticVolatileField;
+    @SuppressWarnings("unused")
+    private static volatile char charStaticVolatileField;
+    @SuppressWarnings("unused")
+    private static volatile int intStaticVolatileField;
+    @SuppressWarnings("unused")
+    private static volatile long longStaticVolatileField;
+    @SuppressWarnings("unused")
+    private static volatile short shortStaticVolatileField;
+
+    @SuppressWarnings("unused")
+    private boolean booleanField;
+    @SuppressWarnings("unused")
+    private byte byteField;
+    @SuppressWarnings("unused")
+    private char charField;
+    @SuppressWarnings("unused")
+    private int intField;
+    @SuppressWarnings("unused")
+    private long longField;
+    @SuppressWarnings("unused")
+    private short shortField;
+
+    @SuppressWarnings("unused")
+    private volatile boolean booleanVolatileField;
+    @SuppressWarnings("unused")
+    private volatile byte byteVolatileField;
+    @SuppressWarnings("unused")
+    private volatile char charVolatileField;
+    @SuppressWarnings("unused")
+    private volatile int intVolatileField;
+    @SuppressWarnings("unused")
+    private volatile long longVolatileField;
+    @SuppressWarnings("unused")
+    private volatile short shortVolatileField;
+
+    public static void main(String[] args) {
+        testUnsafeStaticFieldAccessors();
+        testUnsafeQualifiedStaticFieldAccessors();
+        testUnsafeFieldAccessors();
+        testUnsafeQualifiedFieldAccessors();
+    }
+
+    private static void testUnsafeStaticFieldAccessors() {
+        testFieldAccessors(true, false);
+    }
+
+    private static void testUnsafeQualifiedStaticFieldAccessors() {
+        testFieldAccessors(true, true);
+    }
+
+    private static void testUnsafeFieldAccessors() {
+        testFieldAccessors(false, false);
+    }
+
+    private static void testUnsafeQualifiedFieldAccessors() {
+        testFieldAccessors(false, true);
+    }
+
+    private static void testFieldAccessors(boolean checkStatic,
+        boolean checkVolatile)
+    {
+        // Boolean#valueOf test
+        testField(Boolean.TYPE, Boolean.FALSE, checkStatic, checkVolatile);
+        testField(Boolean.TYPE, Boolean.TRUE, checkStatic, checkVolatile);
+
+        // Byte#valueOf test
+        for (int b = Byte.MIN_VALUE; b < (Byte.MAX_VALUE + 1); b++) {
+            testField(Byte.TYPE, Byte.valueOf((byte) b), checkStatic, checkVolatile);
+        }
+
+        // Character#valueOf test
+        for (char c = '\u0000'; c <= '\u007F'; c++) {
+            testField(Character.TYPE, Character.valueOf(c), checkStatic, checkVolatile);
+        }
+
+        // Integer#valueOf test
+        for (int i = -128; i <= 127; i++) {
+            testField(Integer.TYPE, Integer.valueOf(i), checkStatic, checkVolatile);
+        }
+
+        // Long#valueOf test
+        for (long l = -128L; l <= 127L; l++) {
+            testField(Long.TYPE, Long.valueOf(l), checkStatic, checkVolatile);
+        }
+
+        // Short#valueOf test
+        for (short s = -128; s <= 127; s++) {
+            testField(Short.TYPE, Short.valueOf(s), checkStatic, checkVolatile);
+        }
+    }
+
+    private static void testField(Class primType, Object wrappedValue,
+        boolean checkStatic, boolean checkVolatile)
+    {
+        String fieldName = primType.getName();
+        if (checkStatic) {
+            fieldName += "Static";
+        }
+        if (checkVolatile) {
+            fieldName += "Volatile";
+        }
+        fieldName += "Field";
+        try {
+            Field field = TestFieldReflectValueOf.class.getDeclaredField(fieldName);
+            field.setAccessible(true);
+            TestFieldReflectValueOf obj = new TestFieldReflectValueOf();
+            field.set(obj, wrappedValue);
+            Object result = field.get(obj);
+            if (result != wrappedValue) {
+                throw new RuntimeException("The value " + wrappedValue
+                    + " is not cached for the type " + primType);
+            }
+        } catch (  NoSuchFieldException | SecurityException
+                 | IllegalAccessException | IllegalArgumentException e)
+        {
+            throw new RuntimeException(e);
+        }
+    }
+
+}
diff --git a/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java b/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java
new file mode 100644
--- /dev/null
+++ b/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java
@@ -0,0 +1,131 @@
+/*
+ * 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.
+ *
+ * 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.
+ */
+
+/*
+ * @test
+ * @bug 5043030
+ * @summary Verify that the method java.lang.reflect.Method.invoke(Object, Object...)
+ *          makes use of the same caching mechanism as used for autoboxing
+ *          when wrapping returned values of the primitive types.
+ * @author Andrej Golovnin
+ * @run main/othervm -Dsun.reflect.noInflation=true TestMethodReflectValueOf
+ * @run main/othervm -Dsun.reflect.noInflation=false -Dsun.reflect.inflationThreshold=500 TestMethodReflectValueOf
+ */
+
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+
+
+public class TestMethodReflectValueOf {
+
+    public static void main(String[] args) {
+        // When the inflation is disabled we compare values using "=="
+        // as the returned values of the primitive types should be cached
+        // by the same mechanism as used for autoboxing. When the inflation
+        // is enabled we use "equals()"-method to compare values as the native
+        // code still creates new instances to wrap values of the primitive
+        // types.
+        boolean checkIdentity = Boolean.getBoolean("sun.reflect.noInflation");
+        
+        // Boolean#valueOf test
+        testMethod(Boolean.TYPE, Boolean.FALSE, checkIdentity);
+        testMethod(Boolean.TYPE, Boolean.TRUE, checkIdentity);
+
+        // Byte#valueOf test
+        for (int b = Byte.MIN_VALUE; b < (Byte.MAX_VALUE + 1); b++) {
+            testMethod(Byte.TYPE, Byte.valueOf((byte) b), checkIdentity);
+        }
+
+        // Character#valueOf test
+        for (char c = '\u0000'; c <= '\u007F'; c++) {
+            testMethod(Character.TYPE, Character.valueOf(c), checkIdentity);
+        }
+
+        // Integer#valueOf test
+        for (int i = -128; i <= 127; i++) {
+            testMethod(Integer.TYPE, Integer.valueOf(i), checkIdentity);
+        }
+
+        // Long#valueOf test
+        for (long l = -128L; l <= 127L; l++) {
+            testMethod(Long.TYPE, Long.valueOf(l), checkIdentity);
+        }
+
+        // Short#valueOf test
+        for (short s = -128; s <= 127; s++) {
+            testMethod(Short.TYPE, Short.valueOf(s), checkIdentity);
+        }
+    }
+
+    public static void testMethod(Class primType, Object wrappedValue, 
+            boolean checkIdentity)
+    {
+        String methodName = primType.getName() + "Method";
+        try {
+            Method method = TestMethodReflectValueOf.class.getMethod(methodName, primType);
+            Object result = method.invoke(new TestMethodReflectValueOf(), wrappedValue);
+            if (checkIdentity) {
+                if (result != wrappedValue) {
+                    throw new RuntimeException("The value " + wrappedValue
+                        + " is not cached for the type " + primType);
+                }
+            } else {
+                if (!result.equals(wrappedValue)) {
+                    throw new RuntimeException("The result value " + result
+                        + " is not equal to the expected value " 
+                        + wrappedValue + " for the type " + primType);
+                }
+            }
+        } catch (  NoSuchMethodException | SecurityException
+                 | IllegalAccessException | IllegalArgumentException
+                 | InvocationTargetException e)
+        {
+            throw new RuntimeException(e);
+        }
+    }
+
+    public int intMethod(int value) {
+        return value;
+    }
+
+    public long longMethod(long value) {
+        return value;
+    }
+
+    public short shortMethod(short value) {
+        return value;
+    }
+
+    public byte byteMethod(byte value) {
+        return value;
+    }
+
+    public char charMethod(char value) {
+        return value;
+    }
+
+    public boolean booleanMethod(boolean value) {
+        return value;
+    }
+
+}

From andrej.golovnin at gmail.com  Sat Jun 21 22:17:27 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Sun, 22 Jun 2014 00:17:27 +0200
Subject: [PATCH] LambdaTranslationTest[1|2] may fail when executed with other
	locale than US
Message-ID: 

Hi Joel,

as I already wrote [1] the tests

jdk/lambda/LambdaTranslationTest1.java
jdk/lambda/LambdaTranslationTest2.java

fails when they are executed with other locale than US. The tests make use
of Locale sensitive APIs and assume that the current Locale has the same
formatting rules as Locale.US.

The test LambdaTranslationTest1 fails with the message:

test LambdaTranslationTest1.testMethodRefs(): failure
java.lang.AssertionError: expected [d:1234.000000] but found [d:1234,000000]

The test LambdaTranslationTest2 fails with the message:

test LambdaTranslationTest2.testBoxing(): failure
java.lang.AssertionError: expected [b1 s2 cA i4 j5 ztrue f6,000000
d7,000000] but found [b1 s2 cA i4 j5 ztrue f6.000000 d7.000000]


To reproduce the failure you should execute following commands in the shell
(tested only on Linux):

export LANG=de_DE.utf8
export LC_PAPER=de_DE.utf8
export LC_MONETARY=de_DE.utf8
export LC_NUMERIC=de_DE.utf8
export LC_MEASUREMENT=de_DE.utf8
export LC_TIME=de_DE.utf8
make test TEST=jdk_lang

I have created patch to fix this problem. The patch is attached to this
mail.

Best regards,
Andrej Golovnin

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027194.html
-------------- next part --------------
diff --git a/test/jdk/lambda/LambdaTranslationTest1.java b/test/jdk/lambda/LambdaTranslationTest1.java
--- a/test/jdk/lambda/LambdaTranslationTest1.java
+++ b/test/jdk/lambda/LambdaTranslationTest1.java
@@ -21,6 +21,7 @@
  * questions.
  */
 
+import java.util.Locale;
 import java.util.function.Consumer;
 
 import org.testng.annotations.Test;
@@ -54,15 +55,15 @@
     }
 
     static void eye(Integer i) {
-        setResult(String.format("I:%d", i));
+        setResult(String.format(Locale.US, "I:%d", i));
     }
 
     static void ieye(int i) {
-        setResult(String.format("i:%d", i));
+        setResult(String.format(Locale.US, "i:%d", i));
     }
 
     static void deye(double d) {
-        setResult(String.format("d:%f", d));
+        setResult(String.format(Locale.US, "d:%f", d));
     }
 
     public void testLambdas() {
@@ -87,37 +88,37 @@
         }
 
         cntxt = "blah";
-        Consumer b4 = t -> {setResult(String.format("b4: %s .. %s", cntxt, t));};
+        Consumer b4 = t -> {setResult(String.format(Locale.US, "b4: %s .. %s", cntxt, t));};
         b4.accept("Yor");
         assertResult("b4: blah .. Yor");
 
         String flaw = "flaw";
-        Consumer b5 = t -> {setResult(String.format("b5: %s .. %s", flaw, t));};
+        Consumer b5 = t -> {setResult(String.format(Locale.US, "b5: %s .. %s", flaw, t));};
         b5.accept("BB");
         assertResult("b5: flaw .. BB");
 
         cntxt = "flew";
-        Consumer b6 = t -> {setResult(String.format("b6: %s .. %s .. %s", t, cntxt, flaw));};
+        Consumer b6 = t -> {setResult(String.format(Locale.US, "b6: %s .. %s .. %s", t, cntxt, flaw));};
         b6.accept("flee");
         assertResult("b6: flee .. flew .. flaw");
 
-        Consumer b7 = t -> {setResult(String.format("b7: %s %s", t, this.protectedSuperclassMethod()));};
+        Consumer b7 = t -> {setResult(String.format(Locale.US, "b7: %s %s", t, this.protectedSuperclassMethod()));};
         b7.accept("this:");
         assertResult("b7: this: instance:flew");
 
-        Consumer b8 = t -> {setResult(String.format("b8: %s %s", t, super.protectedSuperclassMethod()));};
+        Consumer b8 = t -> {setResult(String.format(Locale.US, "b8: %s %s", t, super.protectedSuperclassMethod()));};
         b8.accept("super:");
         assertResult("b8: super: I'm the sub");
 
-        Consumer b7b = t -> {setResult(String.format("b9: %s %s", t, protectedSuperclassMethod()));};
+        Consumer b7b = t -> {setResult(String.format(Locale.US, "b9: %s %s", t, protectedSuperclassMethod()));};
         b7b.accept("implicit this:");
         assertResult("b9: implicit this: instance:flew");
 
-        Consumer b10 = t -> {setResult(String.format("b10: new LT1Thing: %s", (new LT1Thing(t)).str));};
+        Consumer b10 = t -> {setResult(String.format(Locale.US, "b10: new LT1Thing: %s", (new LT1Thing(t)).str));};
         b10.accept("thing");
         assertResult("b10: new LT1Thing: thing");
 
-        Consumer b11 = t -> {setResult(String.format("b11: %s", (new LT1Thing(t) {
+        Consumer b11 = t -> {setResult(String.format(Locale.US, "b11: %s", (new LT1Thing(t) {
             String get() {
                 return "*" + str.toString() + "*";
             }
@@ -159,7 +160,7 @@
         private int that = 1234;
 
         void doInner() {
-            Consumer i4 = t -> {setResult(String.format("i4: %d .. %s", that, t));};
+            Consumer i4 = t -> {setResult(String.format(Locale.US, "i4: %d .. %s", that, t));};
             i4.accept("=1234");
             assertResult("i4: 1234 .. =1234");
 
@@ -168,7 +169,7 @@
             assertResult("fruitfruit");
 
             cntxt = "human";
-            Consumer b4 = t -> {setResult(String.format("b4: %s .. %s", cntxt, t));};
+            Consumer b4 = t -> {setResult(String.format(Locale.US, "b4: %s .. %s", cntxt, t));};
             b4.accept("bin");
             assertResult("b4: human .. bin");
 
@@ -179,16 +180,16 @@
  System.out.printf("c5: %s\n", c5.call() );
  **/
 
-            Consumer b5 = t -> {setResult(String.format("b5: %s .. %s", flaw, t));};
+            Consumer b5 = t -> {setResult(String.format(Locale.US, "b5: %s .. %s", flaw, t));};
             b5.accept("BB");
             assertResult("b5: flaw .. BB");
 
             cntxt = "borg";
-            Consumer b6 = t -> {setResult(String.format("b6: %s .. %s .. %s", t, cntxt, flaw));};
+            Consumer b6 = t -> {setResult(String.format(Locale.US, "b6: %s .. %s .. %s", t, cntxt, flaw));};
             b6.accept("flee");
             assertResult("b6: flee .. borg .. flaw");
 
-            Consumer b7b = t -> {setResult(String.format("b7b: %s %s", t, protectedSuperclassMethod()));};
+            Consumer b7b = t -> {setResult(String.format(Locale.US, "b7b: %s %s", t, protectedSuperclassMethod()));};
             b7b.accept("implicit outer this");
             assertResult("b7b: implicit outer this instance:borg");
 
diff --git a/test/jdk/lambda/LambdaTranslationTest2.java b/test/jdk/lambda/LambdaTranslationTest2.java
--- a/test/jdk/lambda/LambdaTranslationTest2.java
+++ b/test/jdk/lambda/LambdaTranslationTest2.java
@@ -25,6 +25,7 @@
 
 import java.util.ArrayList;
 import java.util.List;
+import java.util.Locale;
 import java.util.function.Function;
 import java.util.function.Predicate;
 
@@ -160,39 +161,39 @@
     }
 
     static String pb(Byte a0, Short a1, Character a2, Integer a3, Long a4, Boolean a5, Float a6, Double a7) {
-        return String.format("b%d s%d c%c i%d j%d z%b f%f d%f", a0, a1, a2, a3, a4, a5, a6, a7);
+        return String.format(Locale.US, "b%d s%d c%c i%d j%d z%b f%f d%f", a0, a1, a2, a3, a4, a5, a6, a7);
     }
 
     static String pwI1(int a0, int a1, int a2, int a3) {
-        return String.format("b%d s%d c%d i%d", a0, a1, a2, a3);
+        return String.format(Locale.US, "b%d s%d c%d i%d", a0, a1, a2, a3);
     }
 
     static String pwI2(Integer a0, Integer a1, Integer a2, Integer a3) {
-        return String.format("b%d s%d c%d i%d", a0, a1, a2, a3);
+        return String.format(Locale.US, "b%d s%d c%d i%d", a0, a1, a2, a3);
     }
 
     static String pwL1(long a0, long a1, long a2, long a3, long a4) {
-        return String.format("b%d s%d c%d i%d j%d", a0, a1, a2, a3, a4);
+        return String.format(Locale.US, "b%d s%d c%d i%d j%d", a0, a1, a2, a3, a4);
     }
 
     static String pwL2(Long a0, Long a1, Long a2, Long a3, Long a4) {
-        return String.format("b%d s%d c%d i%d j%d", a0, a1, a2, a3, a4);
+        return String.format(Locale.US, "b%d s%d c%d i%d j%d", a0, a1, a2, a3, a4);
     }
 
     static String pwS1(short a0, short a1) {
-        return String.format("b%d s%d", a0, a1);
+        return String.format(Locale.US, "b%d s%d", a0, a1);
     }
 
     static String pwS2(Short a0, Short a1) {
-        return String.format("b%d s%d", a0, a1);
+        return String.format(Locale.US, "b%d s%d", a0, a1);
     }
 
     static String pwD1(double a0, double a1) {
-        return String.format("f%f d%f", a0, a1);
+        return String.format(Locale.US, "f%f d%f", a0, a1);
     }
 
     static String pwD2(Double a0, Double a1) {
-        return String.format("f%f d%f", a0, a1);
+        return String.format(Locale.US, "f%f d%f", a0, a1);
     }
 
     public void testPrimitiveWidening() {
@@ -216,7 +217,7 @@
     }
 
     static String pu(byte a0, short a1, char a2, int a3, long a4, boolean a5, float a6, double a7) {
-        return String.format("b%d s%d c%c i%d j%d z%b f%f d%f", a0, a1, a2, a3, a4, a5, a6, a7);
+        return String.format(Locale.US, "b%d s%d c%c i%d j%d z%b f%f d%f", a0, a1, a2, a3, a4, a5, a6, a7);
     }
 
     public void testUnboxing() {

From martinrb at google.com  Sun Jun 22 04:05:23 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 21 Jun 2014 21:05:23 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A44C3A.6000607@oracle.com>
References: 
	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
	<53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com>
	<53A44C3A.6000607@oracle.com>
Message-ID: 

While looking at NativePRNG, I filed

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

SecureRandom should be more frugal with file descriptors

If I run this java program on Linux

public class SecureRandoms {
    public static void main(String[] args) throws Throwable {
        new java.security.SecureRandom();
    }
}

it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
by:

strace -q -ff -e open java SecureRandoms |& grep /dev/
[pid 20769] open("/dev/random", O_RDONLY) = 5
[pid 20769] open("/dev/urandom", O_RDONLY) = 6
[pid 20769] open("/dev/random", O_RDONLY) = 7
[pid 20769] open("/dev/random", O_RDONLY) = 8
[pid 20769] open("/dev/urandom", O_RDONLY) = 9
[pid 20769] open("/dev/urandom", O_RDONLY) = 10

Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
it looks like 2 file descriptors are created for every variant of
NativePRNG, whether or not they are ever used. Which is wasteful. In fact,
you only ever need at most two file descriptors, one for /dev/random and
one for /dev/urandom.

Further, it would be nice if the file descriptors were closed when idle and
lazily re-created. Especially /dev/random should typically be used at
startup and never thereafter.


On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman 
wrote:

> On 20/06/2014 15:02, Peter Levart wrote:
>
>>
>> And, as Martin pointed out, it seems to be used for tests that exercise
>> particular responses from NameService API to test the behaviour of JDK
>> classes. It would be a shame for those tests to go away.
>>
> We've been talking about removing it for many years because it has been so
> troublesome. If we really need to having something for testing then I don't
> think it needs to be general purpose, we can get right of the lookup at
> least.
>
> -Alan.
>


From martinrb at google.com  Sun Jun 22 17:12:02 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 22 Jun 2014 10:12:02 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 
	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
	<53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com>
	<53A44C3A.6000607@oracle.com>
	
Message-ID: 

We know that loading the networking machinery is problematic.  On Linux we
would be content to hard-code a read from /dev/urandom, which is safer and
strictly more random than the existing network hardware determination, but
y'all will reject that as too system-dependent (insufficient machinery!).
Hmmmm .... maybe not .... as long as we code up a good fallback ...

I learned that SecureRandom by default on Unix uses /dev/random for "seed
bytes" and /dev/urandom for nextBytes.

Here's my proposal, that in the default case on Unix doesn't load any
machinery, and as a fallback loads the SecureRandom machinery instead of
the network machinery, while maintaining the ultra-secure behavior of the
java.util.secureRandomSeed system property:


    private static long initialSeed() {
        byte[] seedBytes = initialSeedBytes();
        long s = (long)(seedBytes[0]) & 0xffL;
        for (int i = 1; i < seedBytes.length; ++i)
            s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
        return s ^ mix64(System.currentTimeMillis()) ^
mix64(System.nanoTime());
    }

    private static byte[] initialSeedBytes() {
        String pp = java.security.AccessController.doPrivileged(
                new sun.security.action.GetPropertyAction(
                        "java.util.secureRandomSeed"));
        boolean secureRandomSeed = (pp != null &&
pp.equalsIgnoreCase("true"));
        if (secureRandomSeed)
            return java.security.SecureRandom.getSeed(8);
        final byte[] seedBytes = new byte[8];
        File seedSource = new File("/dev/urandom");
        if (seedSource.exists()) {
            try (FileInputStream stream = new FileInputStream(seedSource)) {
                if (stream.read(seedBytes) == 8)
                    return seedBytes;
            } catch (IOException ignore) { }
        }
        new java.security.SecureRandom().nextBytes(seedBytes);
        return seedBytes;
    }




On Sat, Jun 21, 2014 at 9:05 PM, Martin Buchholz 
wrote:

> While looking at NativePRNG, I filed
>
> https://bugs.openjdk.java.net/browse/JDK-8047769
>
> SecureRandom should be more frugal with file descriptors
>
> If I run this java program on Linux
>
> public class SecureRandoms {
>     public static void main(String[] args) throws Throwable {
>         new java.security.SecureRandom();
>     }
> }
>
> it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
> by:
>
> strace -q -ff -e open java SecureRandoms |& grep /dev/
> [pid 20769] open("/dev/random", O_RDONLY) = 5
> [pid 20769] open("/dev/urandom", O_RDONLY) = 6
> [pid 20769] open("/dev/random", O_RDONLY) = 7
> [pid 20769] open("/dev/random", O_RDONLY) = 8
> [pid 20769] open("/dev/urandom", O_RDONLY) = 9
> [pid 20769] open("/dev/urandom", O_RDONLY) = 10
>
> Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
> it looks like 2 file descriptors are created for every variant of
> NativePRNG, whether or not they are ever used. Which is wasteful. In fact,
> you only ever need at most two file descriptors, one for /dev/random and
> one for /dev/urandom.
>
> Further, it would be nice if the file descriptors were closed when idle
> and lazily re-created. Especially /dev/random should typically be used at
> startup and never thereafter.
>
>
> On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman 
> wrote:
>
>> On 20/06/2014 15:02, Peter Levart wrote:
>>
>>>
>>> And, as Martin pointed out, it seems to be used for tests that exercise
>>> particular responses from NameService API to test the behaviour of JDK
>>> classes. It would be a shame for those tests to go away.
>>>
>> We've been talking about removing it for many years because it has been
>> so troublesome. If we really need to having something for testing then I
>> don't think it needs to be general purpose, we can get right of the lookup
>> at least.
>>
>> -Alan.
>>
>
>


From sean.coffey at oracle.com  Sun Jun 22 18:18:29 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Sun, 22 Jun 2014 19:18:29 +0100
Subject: RFR : 8047777: Build broken: ProcessEnvironment_md.c not compiling
Message-ID: <53A71DF5.7020607@oracle.com>

The JDK-8036603 fix pushed on Friday broke windows builds. Bad macro 
call. Simple fix :
https://bugs.openjdk.java.net/browse/JDK-8047777
applicable to jdk8u-dev only.

> --- a/src/windows/native/java/lang/ProcessEnvironment_md.c
> +++ b/src/windows/native/java/lang/ProcessEnvironment_md.c
> @@ -41,7 +41,7 @@
>      CHECK_NULL_RETURN(string_class, NULL);
>      String_init_ID =
>          (*env)->GetMethodID(env, string_class, "", "([B)V");
> -    CHECK_NULL_RETURN(String_init_ID);
> +    CHECK_NULL_RETURN(String_init_ID, NULL);
>      blockA = (jbyte *) GetEnvironmentStringsA();
>      if (blockA == NULL) {
>          /* Both GetEnvironmentStringsW and GetEnvironmentStringsA

regards,
Sean.


From martinrb at google.com  Sun Jun 22 18:54:24 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 22 Jun 2014 11:54:24 -0700
Subject: [concurrency-interest] ThreadLocalRandom.nextSecondarySeed()
	re-initializes TLR's seed
In-Reply-To: <53A3F3F7.9010506@gmail.com>
References: <53A2A155.3040509@gmail.com> <53A2A3D8.8000602@gmail.com>
	<53A2D13E.4020006@cs.oswego.edu> <53A3F3F7.9010506@gmail.com>
Message-ID: 

On Fri, Jun 20, 2014 at 1:42 AM, Peter Levart 
wrote:

>
> This pertains to the other thread (ThreadLocalRandom clinit troubles)
> started by Martin Buchholz, right? He's making a valid point. The "seeder"
> static field is still uninitialized during either NetworkInterface class
> initialization (as a result of NetworkInterface.getNetworkInterfaces()
> call) or during SecureRandom.getSeed() call. Either of which can execute
> user code in some configurations which might in turn use ThreadLocalRandom.
> If this happens, TLR.current() throws a NPE. I proposed a re-arrangement of
> class initialization that allows TLR to be fully functional even during
> it's initialization, albeit with a less randomized seed, and does not
> change the behaviour otherwise (since it triggers re-initialization at the
> end). See the proposed patch in the other thread.
>

I tried this same approach, and found that:

yes, we see some previously failing tests that start passing when the TLR
is functional even while executing its own clinit method, BUT there are
other tests that still fail, and only start passing when the network init
code is removed ... for unknown reasons.  We could debug them, but the
fundamental danger remains - TLR may be invoked very early during JDK
startup, and it is simply too risky to load higher-level libraries so
early, possibly invoking foreign code that might do anything.  Which is why
I keep trying to minimize TLR's external dependencies.

Whatever we decide to do here, the same changes should be made to
SplittableRandom.  Maybe there's scope for some refactoring/sharing, both
of code and of file system access at runtime.


From chris.hegarty at oracle.com  Sun Jun 22 18:59:15 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 22 Jun 2014 19:59:15 +0100
Subject: RFR : 8047777: Build broken: ProcessEnvironment_md.c not compiling
In-Reply-To: <53A71DF5.7020607@oracle.com>
References: <53A71DF5.7020607@oracle.com>
Message-ID: 

Reviewed.

-Chris

> On 22 Jun 2014, at 19:18, Se?n Coffey  wrote:
> 
> The JDK-8036603 fix pushed on Friday broke windows builds. Bad macro call. Simple fix :
> https://bugs.openjdk.java.net/browse/JDK-8047777
> applicable to jdk8u-dev only.
> 
>> --- a/src/windows/native/java/lang/ProcessEnvironment_md.c
>> +++ b/src/windows/native/java/lang/ProcessEnvironment_md.c
>> @@ -41,7 +41,7 @@
>>     CHECK_NULL_RETURN(string_class, NULL);
>>     String_init_ID =
>>         (*env)->GetMethodID(env, string_class, "", "([B)V");
>> -    CHECK_NULL_RETURN(String_init_ID);
>> +    CHECK_NULL_RETURN(String_init_ID, NULL);
>>     blockA = (jbyte *) GetEnvironmentStringsA();
>>     if (blockA == NULL) {
>>         /* Both GetEnvironmentStringsW and GetEnvironmentStringsA
> 
> regards,
> Sean.


From daniel.fuchs at oracle.com  Mon Jun 23 09:48:18 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jun 2014 11:48:18 +0200
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: 
References: 
Message-ID: <53A7F7E2.2030006@oracle.com>

Hi Jason,

Looking at the diff for 6244047 - I see that, as you pointed
out, the unwanted behavior described comes from the fact that
the new code is using CREATE_NEW - which prevents the 'zombie
lock files' from being reused.

I am not an expert in file locks - but I wonder whether we
could revert to using CREATE instead: wouldn't tryLock() later
tell us if the file is used by another entity?

Another possibility would be to combine CREATE_NEW and
DELETE_ON_CLOSE, which according to StandardOpenOptions will
attempt to delete the file on JVM termination if close()
hasn't been called.
This probably wouldn't help in case on VM crash,
but it would help in the case demonstrated by your test below.
I have however some reluctance because I see that we call
FileChannel.close() in the case were the lock can't be obtained,
and I'm not sure what that would do...
Also StandardOpenOptions has some warning about using
DELETE_ON_CLOSE for files that can be opened concurrently
by other entities - so I'm not sure it would be appropriate.

The last possibility I see would be to change the lock HashMap to
take instances of a subclass of WeakReference as
values (instead of String), and add some code that attempts to
close & remove the lock file when the FileHandler is no longer referenced.
Again - this will probably not help in the case of crash, and also
adds the question on when the weak reference queue should be polled to
ensure that the no longer referenced FileChannel are closed in a
timely fashion.

All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
and live with the issue.
Hopefully some nio experts will chime in ;-)

On another track - we could also make MAX configurable - but that
would just be shifting the issue around - wouldn't it?

best regards,

-- daniel

On 6/20/14 10:54 PM, Jason Mehrens wrote:
> Daniel, Jim,
>
>
> In JDK8 the FileHandler file locking was changed to use FileChannel.open with CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due to safety concerns about writing to the same log file. The FileHandler has an upper bound of 100 as the number of file locks that can be attempted to be acquired. Given the right pattern, enough time, and enough failures it seems at it is possible for a program to end up in a state where the FileHandler is surrounded by zombie lock files refuses log or perform a clean up action. (A.K.A Farmer Rick Grimes). This means that the lck files have to manually be deleted or the FileHandler will just fail with an IOException every time it is created.
>
>
> A simple test to emulate crashing is to run (JDK7 vs. JDK8) the following code twice without deleting the log and lck files:
>
>
> public static void main(String[] args) throws Exception {
>     System.out.println(System.getProperty("java.runtime.version"));
>     ReferenceQueue q = new ReferenceQueue<>();
>
>     for (int i=0; i<100; i++) {
>       WeakReference h = new WeakReference<>(
>       new FileHandler("./test_%u.log", 10000, 2, true), q);
>       while (q.poll() != h) {
>           System.runFinalization();
>           System.gc();
>           System.runFinalization();
>           Thread.yield();
>       }
>    }
>
> }
>
>
> I understand that if you can't trust that the file locking always works then there isn't much that can be done. Leaving the number of locks as unbounded isn't really an option either. Seems like there should be a way to identify zombie lock files (ATOMIC_MOVE) and delete them.  Any thoughts on this?
>
> The source discussion on this can be found at http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandler-in-java-8-broken
>
>
> Regards,
>
> Jason 		 	   		
>



From jason_mehrens at hotmail.com  Mon Jun 23 12:51:49 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 23 Jun 2014 07:51:49 -0500
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A7F7E2.2030006@oracle.com>
References: ,
	<53A7F7E2.2030006@oracle.com>
Message-ID: 

Daniel,


My understanding is that changing CREATE_NEW to use CREATE would make it work like does in JDK7.  Closing the lock files when the FileHandler is unreferenced I is probably the fix for JDK-6774110: lock file is not deleted when child logger is used.


If we could prove that system FileLock is mandatory we could use the JDK7 behavior otherwise if they are advisory then use the JDK8 behavior.  If we knew the boot time of the JVM host O/S we could delete all lock files older than the boot time + some constant.


Jason




----------------------------------------
> Date: Mon, 23 Jun 2014 11:48:18 +0200
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>
> Hi Jason,
>
> Looking at the diff for 6244047 - I see that, as you pointed
> out, the unwanted behavior described comes from the fact that
> the new code is using CREATE_NEW - which prevents the 'zombie
> lock files' from being reused.
>
> I am not an expert in file locks - but I wonder whether we
> could revert to using CREATE instead: wouldn't tryLock() later
> tell us if the file is used by another entity?
>
> Another possibility would be to combine CREATE_NEW and
> DELETE_ON_CLOSE, which according to StandardOpenOptions will
> attempt to delete the file on JVM termination if close()
> hasn't been called.
> This probably wouldn't help in case on VM crash,
> but it would help in the case demonstrated by your test below.
> I have however some reluctance because I see that we call
> FileChannel.close() in the case were the lock can't be obtained,
> and I'm not sure what that would do...
> Also StandardOpenOptions has some warning about using
> DELETE_ON_CLOSE for files that can be opened concurrently
> by other entities - so I'm not sure it would be appropriate.
>
> The last possibility I see would be to change the lock HashMap to
> take instances of a subclass of WeakReference as
> values (instead of String), and add some code that attempts to
> close & remove the lock file when the FileHandler is no longer referenced.
> Again - this will probably not help in the case of crash, and also
> adds the question on when the weak reference queue should be polled to
> ensure that the no longer referenced FileChannel are closed in a
> timely fashion.
>
> All in all - I feel our best options would be to revert to using
> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
> and live with the issue.
> Hopefully some nio experts will chime in ;-)
>
> On another track - we could also make MAX configurable - but that
> would just be shifting the issue around - wouldn't it?
>
> best regards,
>
> -- daniel
>
> On 6/20/14 10:54 PM, Jason Mehrens wrote:
>> Daniel, Jim,
>>
>>
>> In JDK8 the FileHandler file locking was changed to use FileChannel.open with CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due to safety concerns about writing to the same log file. The FileHandler has an upper bound of 100 as the number of file locks that can be attempted to be acquired. Given the right pattern, enough time, and enough failures it seems at it is possible for a program to end up in a state where the FileHandler is surrounded by zombie lock files refuses log or perform a clean up action. (A.K.A Farmer Rick Grimes). This means that the lck files have to manually be deleted or the FileHandler will just fail with an IOException every time it is created.
>>
>>
>> A simple test to emulate crashing is to run (JDK7 vs. JDK8) the following code twice without deleting the log and lck files:
>>
>>
>> public static void main(String[] args) throws Exception {
>> System.out.println(System.getProperty("java.runtime.version"));
>> ReferenceQueue q = new ReferenceQueue<>();
>>
>> for (int i=0; i<100; i++) {
>> WeakReference h = new WeakReference<>(
>> new FileHandler("./test_%u.log", 10000, 2, true), q);
>> while (q.poll() != h) {
>> System.runFinalization();
>> System.gc();
>> System.runFinalization();
>> Thread.yield();
>> }
>> }
>>
>> }
>>
>>
>> I understand that if you can't trust that the file locking always works then there isn't much that can be done. Leaving the number of locks as unbounded isn't really an option either. Seems like there should be a way to identify zombie lock files (ATOMIC_MOVE) and delete them. Any thoughts on this?
>>
>> The source discussion on this can be found at http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandler-in-java-8-broken
>>
>>
>> Regards,
>>
>> Jason
>>
> 		 	   		  

From daniel.fuchs at oracle.com  Mon Jun 23 13:18:16 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jun 2014 15:18:16 +0200
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: 
References: ,
	<53A7F7E2.2030006@oracle.com>
	
Message-ID: <53A82918.2030900@oracle.com>

Hi Jason,

On 6/23/14 2:51 PM, Jason Mehrens wrote:
> Daniel,
>
>
> My understanding is that changing CREATE_NEW to use CREATE would make it work like does in JDK7.  Closing the lock files when the FileHandler is unreferenced I is probably the fix for JDK-6774110: lock file is not deleted when child logger is used.

I'll see if I can dig more info about the reason for the change.
Thanks for pointing at JDK-6774110 - I'll have a look at that as well.

-- daniel

>
>
> If we could prove that system FileLock is mandatory we could use the JDK7 behavior otherwise if they are advisory then use the JDK8 behavior.  If we knew the boot time of the JVM host O/S we could delete all lock files older than the boot time + some constant.
>
>
> Jason
>
>
>
>
> ----------------------------------------
>> Date: Mon, 23 Jun 2014 11:48:18 +0200
>> From: daniel.fuchs at oracle.com
>> To: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
>> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>>
>> Hi Jason,
>>
>> Looking at the diff for 6244047 - I see that, as you pointed
>> out, the unwanted behavior described comes from the fact that
>> the new code is using CREATE_NEW - which prevents the 'zombie
>> lock files' from being reused.
>>
>> I am not an expert in file locks - but I wonder whether we
>> could revert to using CREATE instead: wouldn't tryLock() later
>> tell us if the file is used by another entity?
>>
>> Another possibility would be to combine CREATE_NEW and
>> DELETE_ON_CLOSE, which according to StandardOpenOptions will
>> attempt to delete the file on JVM termination if close()
>> hasn't been called.
>> This probably wouldn't help in case on VM crash,
>> but it would help in the case demonstrated by your test below.
>> I have however some reluctance because I see that we call
>> FileChannel.close() in the case were the lock can't be obtained,
>> and I'm not sure what that would do...
>> Also StandardOpenOptions has some warning about using
>> DELETE_ON_CLOSE for files that can be opened concurrently
>> by other entities - so I'm not sure it would be appropriate.
>>
>> The last possibility I see would be to change the lock HashMap to
>> take instances of a subclass of WeakReference as
>> values (instead of String), and add some code that attempts to
>> close & remove the lock file when the FileHandler is no longer referenced.
>> Again - this will probably not help in the case of crash, and also
>> adds the question on when the weak reference queue should be polled to
>> ensure that the no longer referenced FileChannel are closed in a
>> timely fashion.
>>
>> All in all - I feel our best options would be to revert to using
>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>> and live with the issue.
>> Hopefully some nio experts will chime in ;-)
>>
>> On another track - we could also make MAX configurable - but that
>> would just be shifting the issue around - wouldn't it?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 6/20/14 10:54 PM, Jason Mehrens wrote:
>>> Daniel, Jim,
>>>
>>>
>>> In JDK8 the FileHandler file locking was changed to use FileChannel.open with CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due to safety concerns about writing to the same log file. The FileHandler has an upper bound of 100 as the number of file locks that can be attempted to be acquired. Given the right pattern, enough time, and enough failures it seems at it is possible for a program to end up in a state where the FileHandler is surrounded by zombie lock files refuses log or perform a clean up action. (A.K.A Farmer Rick Grimes). This means that the lck files have to manually be deleted or the FileHandler will just fail with an IOException every time it is created.
>>>
>>>
>>> A simple test to emulate crashing is to run (JDK7 vs. JDK8) the following code twice without deleting the log and lck files:
>>>
>>>
>>> public static void main(String[] args) throws Exception {
>>> System.out.println(System.getProperty("java.runtime.version"));
>>> ReferenceQueue q = new ReferenceQueue<>();
>>>
>>> for (int i=0; i<100; i++) {
>>> WeakReference h = new WeakReference<>(
>>> new FileHandler("./test_%u.log", 10000, 2, true), q);
>>> while (q.poll() != h) {
>>> System.runFinalization();
>>> System.gc();
>>> System.runFinalization();
>>> Thread.yield();
>>> }
>>> }
>>>
>>> }
>>>
>>>
>>> I understand that if you can't trust that the file locking always works then there isn't much that can be done. Leaving the number of locks as unbounded isn't really an option either. Seems like there should be a way to identify zombie lock files (ATOMIC_MOVE) and delete them. Any thoughts on this?
>>>
>>> The source discussion on this can be found at http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandler-in-java-8-broken
>>>
>>>
>>> Regards,
>>>
>>> Jason
>>>
>> 		 	   		



From daniel.fuchs at oracle.com  Mon Jun 23 14:42:33 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jun 2014 16:42:33 +0200
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A82918.2030900@oracle.com>
References: ,
	<53A7F7E2.2030006@oracle.com>	
	<53A82918.2030900@oracle.com>
Message-ID: <53A83CD9.3050600@oracle.com>

Hi,

I wonder whether the following patch would solve the
issue. In the case where the lock file already exists,
we check whether it's writable, and whether its directory
is writable, and if so, we open it for 'write+append',
otherwise, we continue with the next lock name.

I we have manage to open the lock file, then we proceed
with trying to lock it, as before.
If locking succeeds - we use that file.
If locking throws exception - we only fall through
if we actually created the file, otherwise we proceed
with the next lock name.

Would that make sense? It passes the CheckLockLocationTest
that was added for 6244047.
Note: I also added a deleteOnExit() hook for good measure.

-- daniel

--- a/src/share/classes/java/util/logging/FileHandler.java
+++ b/src/share/classes/java/util/logging/FileHandler.java
@@ -25,6 +25,7 @@

  package java.util.logging;

+import static java.nio.file.StandardOpenOption.APPEND;
  import static java.nio.file.StandardOpenOption.CREATE_NEW;
  import static java.nio.file.StandardOpenOption.WRITE;

@@ -35,6 +36,8 @@
  import java.io.OutputStream;
  import java.nio.channels.FileChannel;
  import java.nio.file.FileAlreadyExistsException;
+import java.nio.file.Files;
+import java.nio.file.Path;
  import java.nio.file.Paths;
  import java.security.AccessController;
  import java.security.PrivilegedAction;
@@ -434,24 +437,44 @@
                      continue;
                  }

+                final Path lockFilePath = Paths.get(lockFileName);
+                boolean fileCreated;
                  try {
-                    lockFileChannel = 
FileChannel.open(Paths.get(lockFileName),
+                    lockFileChannel = FileChannel.open(lockFilePath,
                              CREATE_NEW, WRITE);
+                    fileCreated = true;
                  } catch (FileAlreadyExistsException ix) {
+                    // This may be a zombie file left over by a previous
+                    // execution. Reuse it - but since we didn't create
+                    // it we won't delete it either.
+                    if (Files.isRegularFile(lockFilePath)
+                            && Files.isWritable(lockFilePath)
+                            && 
Files.isWritable(lockFilePath.getParent())) {
+                        lockFileChannel = FileChannel.open(lockFilePath,
+                                WRITE, APPEND);
+                        fileCreated = false;
+                    } else {
                      // try the next lock file name in the sequence
                      continue;
                  }
+                }

                  boolean available;
                  try {
                      available = lockFileChannel.tryLock() != null;
+                    if (available) {
+                        // we got the lock - ensure that the lock file
+                        // will be deleted on exit.
+                        lockFilePath.toFile().deleteOnExit();
+                    }
                      // We got the lock OK.
                  } catch (IOException ix) {
                      // We got an IOException while trying to get the lock.
                      // This normally indicates that locking is not 
supported
                      // on the target directory.  We have to proceed 
without
-                    // getting a lock.   Drop through.
-                    available = true;
+                    // getting a lock.   Drop through, but only if we did
+                    // create the file...
+                    available = fileCreated;
                  }
                  if (available) {
                      // We got the lock.  Remember it.



On 6/23/14 3:18 PM, Daniel Fuchs wrote:
> Hi Jason,
>
> On 6/23/14 2:51 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> My understanding is that changing CREATE_NEW to use CREATE would make
>> it work like does in JDK7.  Closing the lock files when the
>> FileHandler is unreferenced I is probably the fix for JDK-6774110:
>> lock file is not deleted when child logger is used.
>
> I'll see if I can dig more info about the reason for the change.
> Thanks for pointing at JDK-6774110 - I'll have a look at that as well.
>
> -- daniel
>
>>
>>
>> If we could prove that system FileLock is mandatory we could use the
>> JDK7 behavior otherwise if they are advisory then use the JDK8
>> behavior.  If we knew the boot time of the JVM host O/S we could
>> delete all lock files older than the boot time + some constant.
>>
>>
>> Jason
>>
>>
>>
>>
>> ----------------------------------------
>>> Date: Mon, 23 Jun 2014 11:48:18 +0200
>>> From: daniel.fuchs at oracle.com
>>> To: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
>>> Subject: Re: Zombie FileHandler locks can exhaust all available log
>>> file locks.
>>>
>>> Hi Jason,
>>>
>>> Looking at the diff for 6244047 - I see that, as you pointed
>>> out, the unwanted behavior described comes from the fact that
>>> the new code is using CREATE_NEW - which prevents the 'zombie
>>> lock files' from being reused.
>>>
>>> I am not an expert in file locks - but I wonder whether we
>>> could revert to using CREATE instead: wouldn't tryLock() later
>>> tell us if the file is used by another entity?
>>>
>>> Another possibility would be to combine CREATE_NEW and
>>> DELETE_ON_CLOSE, which according to StandardOpenOptions will
>>> attempt to delete the file on JVM termination if close()
>>> hasn't been called.
>>> This probably wouldn't help in case on VM crash,
>>> but it would help in the case demonstrated by your test below.
>>> I have however some reluctance because I see that we call
>>> FileChannel.close() in the case were the lock can't be obtained,
>>> and I'm not sure what that would do...
>>> Also StandardOpenOptions has some warning about using
>>> DELETE_ON_CLOSE for files that can be opened concurrently
>>> by other entities - so I'm not sure it would be appropriate.
>>>
>>> The last possibility I see would be to change the lock HashMap to
>>> take instances of a subclass of WeakReference as
>>> values (instead of String), and add some code that attempts to
>>> close & remove the lock file when the FileHandler is no longer
>>> referenced.
>>> Again - this will probably not help in the case of crash, and also
>>> adds the question on when the weak reference queue should be polled to
>>> ensure that the no longer referenced FileChannel are closed in a
>>> timely fashion.
>>>
>>> All in all - I feel our best options would be to revert to using
>>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>>> and live with the issue.
>>> Hopefully some nio experts will chime in ;-)
>>>
>>> On another track - we could also make MAX configurable - but that
>>> would just be shifting the issue around - wouldn't it?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 6/20/14 10:54 PM, Jason Mehrens wrote:
>>>> Daniel, Jim,
>>>>
>>>>
>>>> In JDK8 the FileHandler file locking was changed to use
>>>> FileChannel.open with CREATE_NEW. If the file exists (locked or not)
>>>> the FileHandler will rotate due to safety concerns about writing to
>>>> the same log file. The FileHandler has an upper bound of 100 as the
>>>> number of file locks that can be attempted to be acquired. Given the
>>>> right pattern, enough time, and enough failures it seems at it is
>>>> possible for a program to end up in a state where the FileHandler is
>>>> surrounded by zombie lock files refuses log or perform a clean up
>>>> action. (A.K.A Farmer Rick Grimes). This means that the lck files
>>>> have to manually be deleted or the FileHandler will just fail with
>>>> an IOException every time it is created.
>>>>
>>>>
>>>> A simple test to emulate crashing is to run (JDK7 vs. JDK8) the
>>>> following code twice without deleting the log and lck files:
>>>>
>>>>
>>>> public static void main(String[] args) throws Exception {
>>>> System.out.println(System.getProperty("java.runtime.version"));
>>>> ReferenceQueue q = new ReferenceQueue<>();
>>>>
>>>> for (int i=0; i<100; i++) {
>>>> WeakReference h = new WeakReference<>(
>>>> new FileHandler("./test_%u.log", 10000, 2, true), q);
>>>> while (q.poll() != h) {
>>>> System.runFinalization();
>>>> System.gc();
>>>> System.runFinalization();
>>>> Thread.yield();
>>>> }
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> I understand that if you can't trust that the file locking always
>>>> works then there isn't much that can be done. Leaving the number of
>>>> locks as unbounded isn't really an option either. Seems like there
>>>> should be a way to identify zombie lock files (ATOMIC_MOVE) and
>>>> delete them. Any thoughts on this?
>>>>
>>>> The source discussion on this can be found at
>>>> http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandler-in-java-8-broken
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Jason
>>>>
>>>
>



From Alan.Bateman at oracle.com  Mon Jun 23 14:53:59 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jun 2014 15:53:59 +0100
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A7F7E2.2030006@oracle.com>
References: 
	<53A7F7E2.2030006@oracle.com>
Message-ID: <53A83F87.5060505@oracle.com>

On 23/06/2014 10:48, Daniel Fuchs wrote:
> :
>
> All in all - I feel our best options would be to revert to using
> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
> and live with the issue.
> Hopefully some nio experts will chime in ;-)
>
The logging use of FileLock is a bit unusual but looking at it now then 
I don't see the reason why it needs to use CREATE_NEW. I don't think 
DELETE_ON_CLOSE is suitable here as that work is for transient work 
files which isn't the case here. Instead it could use deleteOnExit to 
have some chance of removing it on a graceful exit.

BTW: Do you know why locks is Map? Would a Set do?

-Alan.



From daniel.fuchs at oracle.com  Mon Jun 23 15:13:04 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jun 2014 17:13:04 +0200
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A83F87.5060505@oracle.com>
References: 
	<53A7F7E2.2030006@oracle.com> <53A83F87.5060505@oracle.com>
Message-ID: <53A84400.6090509@oracle.com>

On 6/23/14 4:53 PM, Alan Bateman wrote:
> On 23/06/2014 10:48, Daniel Fuchs wrote:
>> :
>>
>> All in all - I feel our best options would be to revert to using
>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>> and live with the issue.
>> Hopefully some nio experts will chime in ;-)
>>
> The logging use of FileLock is a bit unusual but looking at it now then
> I don't see the reason why it needs to use CREATE_NEW.

OK - thanks - in the discussion that ended up in the patch where
CREATE_NEW was introduced Jason (I think it was Jason) pointed at
https://bugs.openjdk.java.net/browse/JDK-4420020

I'm guessing here that maybe it would be wrong to use an already
existing lock file if you don't have the rights to write to
its directory - and that using CREATE_NEW ensures that you have
all necessary access rights all along the path.

> I don't think
> DELETE_ON_CLOSE is suitable here as that work is for transient work
> files which isn't the case here. Instead it could use deleteOnExit to
> have some chance of removing it on a graceful exit.

Right - I suggested a patch in another mail where I just use that.

>
> BTW: Do you know why locks is Map? Would a Set do?

It certainly looks as if we could use a simple HashSet here.

Thanks Alan!

-- daniel

>
> -Alan.
>



From huizhe.wang at oracle.com  Mon Jun 23 16:10:02 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 23 Jun 2014 09:10:02 -0700
Subject: RFR JDK-5077522 : Duration.compare incorrect for some values
In-Reply-To: <13FBA989-0946-483D-AE6A-D6E6DF7824F8@oracle.com>
References: <53A094DA.1000905@oracle.com> <53A406C0.2060709@oracle.com>
	<53A4EFAD.3050000@oracle.com> <53A541ED.4090303@oracle.com>
	<13FBA989-0946-483D-AE6A-D6E6DF7824F8@oracle.com>
Message-ID: <53A8515A.3090705@oracle.com>

Thanks again Daniel and Lance!

Joe

On 6/21/2014 3:32 AM, Lance @ Oracle wrote:
> Agree this is better and cleaner!
>
>
> 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 Jun 21, 2014, at 4:27 AM, Daniel Fuchs  > wrote:
>
>> Thanks Joe!
>>
>> This is much cleaner indeed :-)
>>
>> -- daniel
>>
>> On 6/21/14 4:36 AM, huizhe wang wrote:
>>> Thanks Daniel, Lance.
>>>
>>> On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
>>>> Hi Joe,
>>>>
>>>> Thanks for the detailed explanation.
>>>> It really helps reviewing the fix!
>>>
>>> Glad to know it helps. I thought this part of spec could be 
>>> unfamiliar to people.
>>>
>>>>
>>>> This looks reasonable to me. One minor nit is that you
>>>> could turn:
>>>>
>>>> 769         BigInteger maxintAsBigInteger = 
>>>> BigInteger.valueOf((long) Integer.MAX_VALUE);
>>>
>>> Good catch!  I was going to do so but then forgot.
>>>
>>> I also refactored the check method so that the checks can be done in 
>>> one loop: 24 lines of code instead of the original 170. I feel good :-)
>>>
>>> The other changes are purely clean-up and in one case, JavaDoc.
>>>
>>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/ 
>>> 
>>>
>>> Best regards,
>>> Joe
>>>
>>>
>>>>
>>>> into a static final constant in the class.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 6/17/14 9:19 PM, huizhe wang wrote:
>>>>> Hi,
>>>>>
>>>>> This is a long time compatibility issue: Duration.compare returns 
>>>>> equal
>>>>> for INDETERMINATE relations defined in XML Schema standard
>>>>> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
>>>>> following table:
>>>>>
>>>>>     Relation
>>>>> P*1Y*     > P*364D*     <> P*365D*         <> P*366D*     < P*367D*
>>>>> P*1M*     > P*27D*     <> P*28D*     <> P*29D*     <> P*30D*     <>
>>>>> P*31D*     < P*32D*
>>>>> P*5M*     > P*149D*     <> P*150D*     <> P*151D*     <> P*152D* 
>>>>>     <>
>>>>> P*153D*     < P*154D*
>>>>>
>>>>>
>>>>>
>>>>> The order-relation of two Duratoin values x and y is x < y iff s+x 
>>>>> < s+y
>>>>> for each qualified datetime s listed below:
>>>>>
>>>>>  * 1696-09-01T00:00:00Z
>>>>>  * 1697-02-01T00:00:00Z
>>>>>  * 1903-03-01T00:00:00Z
>>>>>  * 1903-07-01T00:00:00Z
>>>>>
>>>>>
>>>>> The original implementation used Unix epoch, that is, 00:00:00 UTC 
>>>>> on 1
>>>>> January 1970, as s in the above calculation which violated the above
>>>>> specification. A patch during JDK 6 development added correct
>>>>> implementation of the spec, but it was unfortunately added after the
>>>>> original calculation using Epoch time.
>>>>>
>>>>> *The fix to the issue therefore is simply removing the calculation 
>>>>> using
>>>>> Epoch time.* I also consolidated the tedious max field value 
>>>>> checks into
>>>>> a method called checkMaxValue.
>>>>>
>>>>> *Patch:*
>>>>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/ 
>>>>> 
>>>>>
>>>>> Test:
>>>>> testCompareWithInderterminateRelation: this is a copy of the JCK test
>>>>> that tests INDETERMINATE relations.
>>>>> testVerifyOtherRelations: this is added to verify edge cases, e.g. 
>>>>> +- 1
>>>>> second to the original test cases. For example, to the original test:
>>>>> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
>>>>> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>>>>>
>>>>> Below is the test result:
>>>>> Comparing P1Y and P365D: INDETERMINATE
>>>>> Comparing P1Y and P366D: INDETERMINATE
>>>>> Comparing P1M and P28D: INDETERMINATE
>>>>> Comparing P1M and P29D: INDETERMINATE
>>>>> Comparing P1M and P30D: INDETERMINATE
>>>>> Comparing P1M and P31D: INDETERMINATE
>>>>> Comparing P5M and P150D: INDETERMINATE
>>>>> Comparing P5M and P151D: INDETERMINATE
>>>>> Comparing P5M and P152D: INDETERMINATE
>>>>> Comparing P5M and P153D: INDETERMINATE
>>>>> Comparing PT2419200S and P1M: INDETERMINATE
>>>>> Comparing PT2678400S and P1M: INDETERMINATE
>>>>> Comparing PT31536000S and P1Y: INDETERMINATE
>>>>> Comparing PT31622400S and P1Y: INDETERMINATE
>>>>> Comparing PT525600M and P1Y: INDETERMINATE
>>>>> Comparing PT527040M and P1Y: INDETERMINATE
>>>>> Comparing PT8760H and P1Y: INDETERMINATE
>>>>> Comparing PT8784H and P1Y: INDETERMINATE
>>>>> Comparing P365D and P1Y: INDETERMINATE
>>>>> Comparing P1Y and P364D: expected: GREATER actual: GREATER
>>>>> Comparing P1Y and P367D: expected: LESSER actual: LESSER
>>>>> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
>>>>> Comparing P1M and P27D: expected: GREATER actual: GREATER
>>>>> Comparing P1M and P32D: expected: LESSER actual: LESSER
>>>>> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
>>>>> Comparing P5M and P149D: expected: GREATER actual: GREATER
>>>>> Comparing P5M and P154D: expected: LESSER actual: LESSER
>>>>> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
>>>>> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
>>>>> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
>>>>> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
>>>>> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
>>>>> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
>>>>> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
>>>>> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
>>>>> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>>>>>
>>>>> Number of tests passed: 36
>>>>> Number of tests failed: 0
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>
>>>
>>



From bradford.wetmore at oracle.com  Mon Jun 23 17:04:34 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 23 Jun 2014 10:04:34 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A4819F.5080906@oracle.com>
References: <53A4819F.5080906@oracle.com>
Message-ID: <53A85E22.1000009@oracle.com>

I would prefer that JCE1.2 be pulled out completely in the Cipher* 
classes.  I will be sending you a separate note about JCE logistics.

Thanks for doing this cleanup.

Brad


On 6/20/2014 11:46 AM, Henry Jen wrote:
> Hi,
>
> Please review a trivial webrev to add JDK version to @since in a format
> as Mark suggested[1].
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
>
> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html
>
> Appened is the diff as in the webrev.
>
> Cheers,
> Henry
>
>
> diff --git a/src/share/classes/java/lang/Package.java
> b/src/share/classes/java/lang/Package.java
> --- a/src/share/classes/java/lang/Package.java
> +++ b/src/share/classes/java/lang/Package.java
> @@ -107,6 +107,7 @@
>    * loader to be found.
>    *
>    * @see ClassLoader#definePackage
> + * @since 1.2
>    */
>   public class Package implements java.lang.reflect.AnnotatedElement {
>       /**
> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
> b/src/share/classes/javax/crypto/CipherInputStream.java
> --- a/src/share/classes/javax/crypto/CipherInputStream.java
> +++ b/src/share/classes/javax/crypto/CipherInputStream.java
> @@ -170,7 +170,7 @@
>        * @return  the next byte of data, or -1 if the end
> of the
>        *          stream is reached.
>        * @exception  IOException  if an I/O error occurs.
> -     * @since JCE1.2
> +     * @since 1.4, JCE1.2
>        */
>       public int read() throws IOException {
>           if (ostart >= ofinish) {
> @@ -196,7 +196,7 @@
>        *             the stream has been reached.
>        * @exception  IOException  if an I/O error occurs.
>        * @see        java.io.InputStream#read(byte[], int, int)
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public int read(byte b[]) throws IOException {
>           return read(b, 0, b.length);
> @@ -217,7 +217,7 @@
>        *             the stream has been reached.
>        * @exception  IOException  if an I/O error occurs.
>        * @see        java.io.InputStream#read()
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public int read(byte b[], int off, int len) throws IOException {
>           if (ostart >= ofinish) {
> @@ -254,7 +254,7 @@
>        * @param      n the number of bytes to be skipped.
>        * @return     the actual number of bytes skipped.
>        * @exception  IOException  if an I/O error occurs.
> -     * @since JCE1.2
> +     * @since 1.4, JCE1.2
>        */
>       public long skip(long n) throws IOException {
>           int available = ofinish - ostart;
> @@ -277,7 +277,7 @@
>        * @return     the number of bytes that can be read from this
> input stream
>        *             without blocking.
>        * @exception  IOException  if an I/O error occurs.
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public int available() throws IOException {
>           return (ofinish - ostart);
> @@ -292,7 +292,7 @@
>        * stream.
>        *
>        * @exception  IOException  if an I/O error occurs.
> -     * @since JCE1.2
> +     * @since 1.4, JCE1.2
>        */
>       public void close() throws IOException {
>           if (closed) {
> @@ -321,7 +321,7 @@
>        *          mark and reset methods.
>        * @see     java.io.InputStream#mark(int)
>        * @see     java.io.InputStream#reset()
> -     * @since   JCE1.2
> +     * @since   1.4, JCE1.2
>        */
>       public boolean markSupported() {
>           return false;
> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
> b/src/share/classes/javax/crypto/CipherOutputStream.java
> --- a/src/share/classes/javax/crypto/CipherOutputStream.java
> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java
> @@ -114,7 +114,7 @@
>        *
>        * @param      b   the byte.
>        * @exception  IOException  if an I/O error occurs.
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public void write(int b) throws IOException {
>           ibuffer[0] = (byte) b;
> @@ -138,7 +138,7 @@
>        * @exception  NullPointerException if b is null.
>        * @exception  IOException  if an I/O error occurs.
>        * @see        javax.crypto.CipherOutputStream#write(byte[], int,
> int)
> -     * @since JCE1.2
> +     * @since 1.4, JCE1.2
>        */
>       public void write(byte b[]) throws IOException {
>           write(b, 0, b.length);
> @@ -152,7 +152,7 @@
>        * @param      off   the start offset in the data.
>        * @param      len   the number of bytes to write.
>        * @exception  IOException  if an I/O error occurs.
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public void write(byte b[], int off, int len) throws IOException {
>           obuffer = cipher.update(b, off, len);
> @@ -174,7 +174,7 @@
>        * the cipher's block size, no bytes will be written out.
>        *
>        * @exception  IOException  if an I/O error occurs.
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public void flush() throws IOException {
>           if (obuffer != null) {
> @@ -198,7 +198,7 @@
>        * stream.
>        *
>        * @exception  IOException  if an I/O error occurs.
> -     * @since      JCE1.2
> +     * @since      1.4, JCE1.2
>        */
>       public void close() throws IOException {
>           if (closed) {
> diff --git a/src/share/classes/javax/naming/InitialContext.java
> b/src/share/classes/javax/naming/InitialContext.java
> --- a/src/share/classes/javax/naming/InitialContext.java
> +++ b/src/share/classes/javax/naming/InitialContext.java
> @@ -125,7 +125,7 @@
>    * @see Context
>    * @see NamingManager#setInitialContextFactoryBuilder
>    *      NamingManager.setInitialContextFactoryBuilder
> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
> + * @since 1.3, JNDI 1.1
>    */
>
>   public class InitialContext implements Context {
>


From neil.toda at oracle.com  Mon Jun 23 17:26:40 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Mon, 23 Jun 2014 10:26:40 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A4C799.900@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
	<53A4C34C.4010004@oracle.com> <53A4C799.900@oracle.com>
Message-ID: <53A86350.4020802@oracle.com>


I've spun a new webrev based on the comments for webrev-03:

     http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/

Changes are:

   1) java.c
         a) add free(envName) line 1063
         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 1056

Thanks

-neil

On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
> Neil,
>
> Generally looks good, yes JLI_* functions must be used, I missed that 
> one.
> Are you going to post another iteration ?
>
> Kumar
>
> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>
>> Thanks Joe.  It would have checked for NULL for me.
>> I'll use the JLI wrapper.
>>
>> -neil
>>
>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>> Memory allocation in the launcher should use one of the JLI_MemAlloc 
>>> wrappers, if possible.
>>>
>>> -Joe
>>>
>>>
>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>
>>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>>> non-null.
>>>>
>>>> -neil
>>>>
>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>> Neil,
>>>>>
>>>>> Thanks for quick implementation.
>>>>>
>>>>> java.c:
>>>>>   Did not check return values of malloc(), I wonder if source code 
>>>>> analyzers will complain.
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>
>>>>>> Launcher support for modified Native Memory Tracking mechanism in 
>>>>>> JVM in JDK9.
>>>>>>
>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>
>>>>
>>>
>>
>



From bradford.wetmore at oracle.com  Mon Jun 23 17:43:39 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 23 Jun 2014 10:43:39 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>
	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>
	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>
	
Message-ID: <53A8674B.9080000@oracle.com>

Martin,

Thanks for filing.  I was positive there was already a bug for this, but 
for the life of me I can't find it now.  There's some other more minor 
cleanup that needs to take place, but seems like I've been in 
escalation/firefighting mode for more than a year now and it hasn't 
bubbled to the top.

Brad


On 6/21/2014 9:05 PM, Martin Buchholz wrote:
> While looking at NativePRNG, I filed
>
> https://bugs.openjdk.java.net/browse/JDK-8047769
>
> SecureRandom should be more frugal with file descriptors
>
> If I run this java program on Linux
>
> public class SecureRandoms {
>      public static void main(String[] args) throws Throwable {
>          new java.security.SecureRandom();
>      }
> }
>
> it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
> by:
>
> strace -q -ff -e open java SecureRandoms |& grep /dev/
> [pid 20769] open("/dev/random", O_RDONLY) = 5
> [pid 20769] open("/dev/urandom", O_RDONLY) = 6
> [pid 20769] open("/dev/random", O_RDONLY) = 7
> [pid 20769] open("/dev/random", O_RDONLY) = 8
> [pid 20769] open("/dev/urandom", O_RDONLY) = 9
> [pid 20769] open("/dev/urandom", O_RDONLY) = 10
>
> Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
> it looks like 2 file descriptors are created for every variant of
> NativePRNG, whether or not they are ever used. Which is wasteful. In
> fact, you only ever need at most two file descriptors, one for
> /dev/random and one for /dev/urandom.
>
> Further, it would be nice if the file descriptors were closed when idle
> and lazily re-created. Especially /dev/random should typically be used
> at startup and never thereafter.
>
>
> On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman  > wrote:
>
>     On 20/06/2014 15:02, Peter Levart wrote:
>
>
>         And, as Martin pointed out, it seems to be used for tests that
>         exercise particular responses from NameService API to test the
>         behaviour of JDK classes. It would be a shame for those tests to
>         go away.
>
>     We've been talking about removing it for many years because it has
>     been so troublesome. If we really need to having something for
>     testing then I don't think it needs to be general purpose, we can
>     get right of the lookup at least.
>
>     -Alan.
>
>


From huizhe.wang at oracle.com  Mon Jun 23 19:05:51 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 23 Jun 2014 12:05:51 -0700
Subject: JDK9 project: XML/JAXP Approachability / Ease of Use
Message-ID: <53A87A8F.4030401@oracle.com>

Hi,

We're planning on a jaxp project to address usability issues in the JAXP 
API. One of the complaints about the JAXP API is the number of lines of 
code that are needed to implement a simple task. Tasks that should take 
one or two lines often take ten or twelve lines instead. Consider the 
following example:

         File file = new File(FILEPATH + "results.xml");
         DocumentBuilderFactory factory = 
DocumentBuilderFactory.newInstance();
         factory.setNamespaceAware(true);

         XPathFactory xf = XPathFactory.newInstance();
         XPath xp = xf.newXPath();
         xp.setNamespaceContext(new NamespaceContext() {
             @Override
             public String getNamespaceURI(String prefix) {
                 return "http://example.com/users/";
             }

             @Override
             public String getPrefix(String namespaceURI) {
                 return "ns1";
             }

             @Override
             public Iterator getPrefixes(String namespaceURI) {
                 ArrayList list = new ArrayList();
                 list.add("ns1");
                 return list.iterator();
             }

         });
         try {
             DocumentBuilder builder = factory.newDocumentBuilder();
             Document document = builder.parse(file);
             String s = (String) xp.evaluate(
"/ns1:Results/ns1:Row[ns1:USERID=2]/ns1:NAME[text()]",
                     document, XPathConstants.STRING);
             System.out.println("Company: " + s);
         } catch (ParserConfigurationException e) {
             //creating DocumentBuilder
         } catch (SAXException ex) {
             //parsing
         } catch (IOException ex) {
             //parsing
         } catch (XPathExpressionException ex) {
             //xpath evaluation
         }

The issues reflected in the above sample include:

*1. Too many abstractions*

As shown in the above sample, there are multiple layers of abstraction 
in the DOM and Xpath API: factory, builder, and document, XPathFactory 
and XPath.

*2. Unnecessary Pluggability*

The pluggability layer allows easily plugging in third party 
implementations. However, in many use cases where pluggability is not 
needed, it becomes the performance bottleneck for the applications.

*3. Too many unrelated checked exceptions*

There are four unrelated checked exceptions in the above example. None 
of them is recoverable. ParserConfigurationException actually reflects a 
design flaw in the DocumentBuilderFactory that allowed setting both a 
Schema and Schema Language. In practice, Exception is often used to 
avoid having to catch each of the checked exceptions.

*4. Lack of integration*

JAXP is an umbrella of several libraries. The sample code above 
demonstrated the lack of integration among them. First of all, A DOM 
Document and XPath have to be created separately. Secondly, as in the 
above case, the Document may be either namespace-aware or unaware, 
depending on the setting on the DOM Factory, which is unknown to XPath 
created later.



This project may have two aspects: one to provide APIs to get straight 
to the objects such as DOM Document, and another to provide convenient 
methods for some common use cases.  (*Note that, there is no intention 
to replace the existing API nor duplicate all of the features.)

For the example above, it could potentially be done in a couple of lines 
(this is just an illustration on how existing APIs could be simplified 
and may not reflect what the API would look like):

         String company =
             XMLDocument.fromFile(FILEPATH + "results.xml")
.evalXPath("/Results/Row[USERID=2]/NAME[text()]");
         System.out.printf("Company: %s%n", company);


We would love to hear from you. Any thoughts, concerns, 
experiences/complaints would be very welcome.

Thanks,
Joe


From mandy.chung at oracle.com  Mon Jun 23 20:23:32 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jun 2014 13:23:32 -0700
Subject: Review request for 8047904: Runtime.loadLibrary throws
	SecurityException when security manager is installed
Message-ID: <53A88CC4.2040605@oracle.com>

The loadLibrary implementation is missing to wrap the call
to File.getCanonicalPath  method with doPrivileged block.

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/

thanks
Mandy



From henry.jen at oracle.com  Mon Jun 23 20:50:03 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 23 Jun 2014 13:50:03 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A85E22.1000009@oracle.com>
References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com>
Message-ID: <53A892FB.8060507@oracle.com>

OK, I'll remove all @since JCE line, as the class already has @since 1.4 
as Joe pointed out earlier.

Uodated webrev at

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

Cheers,
Henry


On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
> I would prefer that JCE1.2 be pulled out completely in the Cipher*
> classes.  I will be sending you a separate note about JCE logistics.
>
> Thanks for doing this cleanup.
>
> Brad
>
>
> On 6/20/2014 11:46 AM, Henry Jen wrote:
>> Hi,
>>
>> Please review a trivial webrev to add JDK version to @since in a format
>> as Mark suggested[1].
>>
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html
>>
>> Appened is the diff as in the webrev.
>>
>> Cheers,
>> Henry
>>
>>
>> diff --git a/src/share/classes/java/lang/Package.java
>> b/src/share/classes/java/lang/Package.java
>> --- a/src/share/classes/java/lang/Package.java
>> +++ b/src/share/classes/java/lang/Package.java
>> @@ -107,6 +107,7 @@
>>    * loader to be found.
>>    *
>>    * @see ClassLoader#definePackage
>> + * @since 1.2
>>    */
>>   public class Package implements java.lang.reflect.AnnotatedElement {
>>       /**
>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
>> b/src/share/classes/javax/crypto/CipherInputStream.java
>> --- a/src/share/classes/javax/crypto/CipherInputStream.java
>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java
>> @@ -170,7 +170,7 @@
>>        * @return  the next byte of data, or -1 if the end
>> of the
>>        *          stream is reached.
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since JCE1.2
>> +     * @since 1.4, JCE1.2
>>        */
>>       public int read() throws IOException {
>>           if (ostart >= ofinish) {
>> @@ -196,7 +196,7 @@
>>        *             the stream has been reached.
>>        * @exception  IOException  if an I/O error occurs.
>>        * @see        java.io.InputStream#read(byte[], int, int)
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public int read(byte b[]) throws IOException {
>>           return read(b, 0, b.length);
>> @@ -217,7 +217,7 @@
>>        *             the stream has been reached.
>>        * @exception  IOException  if an I/O error occurs.
>>        * @see        java.io.InputStream#read()
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public int read(byte b[], int off, int len) throws IOException {
>>           if (ostart >= ofinish) {
>> @@ -254,7 +254,7 @@
>>        * @param      n the number of bytes to be skipped.
>>        * @return     the actual number of bytes skipped.
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since JCE1.2
>> +     * @since 1.4, JCE1.2
>>        */
>>       public long skip(long n) throws IOException {
>>           int available = ofinish - ostart;
>> @@ -277,7 +277,7 @@
>>        * @return     the number of bytes that can be read from this
>> input stream
>>        *             without blocking.
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public int available() throws IOException {
>>           return (ofinish - ostart);
>> @@ -292,7 +292,7 @@
>>        * stream.
>>        *
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since JCE1.2
>> +     * @since 1.4, JCE1.2
>>        */
>>       public void close() throws IOException {
>>           if (closed) {
>> @@ -321,7 +321,7 @@
>>        *          mark and reset methods.
>>        * @see     java.io.InputStream#mark(int)
>>        * @see     java.io.InputStream#reset()
>> -     * @since   JCE1.2
>> +     * @since   1.4, JCE1.2
>>        */
>>       public boolean markSupported() {
>>           return false;
>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
>> b/src/share/classes/javax/crypto/CipherOutputStream.java
>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java
>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java
>> @@ -114,7 +114,7 @@
>>        *
>>        * @param      b   the byte.
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public void write(int b) throws IOException {
>>           ibuffer[0] = (byte) b;
>> @@ -138,7 +138,7 @@
>>        * @exception  NullPointerException if b is null.
>>        * @exception  IOException  if an I/O error occurs.
>>        * @see        javax.crypto.CipherOutputStream#write(byte[], int,
>> int)
>> -     * @since JCE1.2
>> +     * @since 1.4, JCE1.2
>>        */
>>       public void write(byte b[]) throws IOException {
>>           write(b, 0, b.length);
>> @@ -152,7 +152,7 @@
>>        * @param      off   the start offset in the data.
>>        * @param      len   the number of bytes to write.
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public void write(byte b[], int off, int len) throws IOException {
>>           obuffer = cipher.update(b, off, len);
>> @@ -174,7 +174,7 @@
>>        * the cipher's block size, no bytes will be written out.
>>        *
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public void flush() throws IOException {
>>           if (obuffer != null) {
>> @@ -198,7 +198,7 @@
>>        * stream.
>>        *
>>        * @exception  IOException  if an I/O error occurs.
>> -     * @since      JCE1.2
>> +     * @since      1.4, JCE1.2
>>        */
>>       public void close() throws IOException {
>>           if (closed) {
>> diff --git a/src/share/classes/javax/naming/InitialContext.java
>> b/src/share/classes/javax/naming/InitialContext.java
>> --- a/src/share/classes/javax/naming/InitialContext.java
>> +++ b/src/share/classes/javax/naming/InitialContext.java
>> @@ -125,7 +125,7 @@
>>    * @see Context
>>    * @see NamingManager#setInitialContextFactoryBuilder
>>    *      NamingManager.setInitialContextFactoryBuilder
>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
>> + * @since 1.3, JNDI 1.1
>>    */
>>
>>   public class InitialContext implements Context {
>>


From joe.darcy at oracle.com  Mon Jun 23 20:54:22 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jun 2014 13:54:22 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A892FB.8060507@oracle.com>
References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com>
	<53A892FB.8060507@oracle.com>
Message-ID: <53A893FE.90001@oracle.com>

Looks good to me; thanks,

-Joe

On 06/23/2014 01:50 PM, Henry Jen wrote:
> OK, I'll remove all @since JCE line, as the class already has @since 
> 1.4 as Joe pointed out earlier.
>
> Uodated webrev at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
>
> Cheers,
> Henry
>
>
> On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
>> I would prefer that JCE1.2 be pulled out completely in the Cipher*
>> classes.  I will be sending you a separate note about JCE logistics.
>>
>> Thanks for doing this cleanup.
>>
>> Brad
>>
>>
>> On 6/20/2014 11:46 AM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a trivial webrev to add JDK version to @since in a format
>>> as Mark suggested[1].
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
>>>
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html
>>>
>>> Appened is the diff as in the webrev.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>> diff --git a/src/share/classes/java/lang/Package.java
>>> b/src/share/classes/java/lang/Package.java
>>> --- a/src/share/classes/java/lang/Package.java
>>> +++ b/src/share/classes/java/lang/Package.java
>>> @@ -107,6 +107,7 @@
>>>    * loader to be found.
>>>    *
>>>    * @see ClassLoader#definePackage
>>> + * @since 1.2
>>>    */
>>>   public class Package implements java.lang.reflect.AnnotatedElement {
>>>       /**
>>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
>>> b/src/share/classes/javax/crypto/CipherInputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherInputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java
>>> @@ -170,7 +170,7 @@
>>>        * @return  the next byte of data, or -1 if the end
>>> of the
>>>        *          stream is reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public int read() throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -196,7 +196,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read(byte[], int, int)
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[]) throws IOException {
>>>           return read(b, 0, b.length);
>>> @@ -217,7 +217,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read()
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[], int off, int len) throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -254,7 +254,7 @@
>>>        * @param      n the number of bytes to be skipped.
>>>        * @return     the actual number of bytes skipped.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public long skip(long n) throws IOException {
>>>           int available = ofinish - ostart;
>>> @@ -277,7 +277,7 @@
>>>        * @return     the number of bytes that can be read from this
>>> input stream
>>>        *             without blocking.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int available() throws IOException {
>>>           return (ofinish - ostart);
>>> @@ -292,7 +292,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> @@ -321,7 +321,7 @@
>>>        *          mark and reset methods.
>>>        * @see     java.io.InputStream#mark(int)
>>>        * @see     java.io.InputStream#reset()
>>> -     * @since   JCE1.2
>>> +     * @since   1.4, JCE1.2
>>>        */
>>>       public boolean markSupported() {
>>>           return false;
>>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> @@ -114,7 +114,7 @@
>>>        *
>>>        * @param      b   the byte.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(int b) throws IOException {
>>>           ibuffer[0] = (byte) b;
>>> @@ -138,7 +138,7 @@
>>>        * @exception  NullPointerException if b is null.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see javax.crypto.CipherOutputStream#write(byte[], int,
>>> int)
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void write(byte b[]) throws IOException {
>>>           write(b, 0, b.length);
>>> @@ -152,7 +152,7 @@
>>>        * @param      off   the start offset in the data.
>>>        * @param      len   the number of bytes to write.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(byte b[], int off, int len) throws 
>>> IOException {
>>>           obuffer = cipher.update(b, off, len);
>>> @@ -174,7 +174,7 @@
>>>        * the cipher's block size, no bytes will be written out.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void flush() throws IOException {
>>>           if (obuffer != null) {
>>> @@ -198,7 +198,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> diff --git a/src/share/classes/javax/naming/InitialContext.java
>>> b/src/share/classes/javax/naming/InitialContext.java
>>> --- a/src/share/classes/javax/naming/InitialContext.java
>>> +++ b/src/share/classes/javax/naming/InitialContext.java
>>> @@ -125,7 +125,7 @@
>>>    * @see Context
>>>    * @see NamingManager#setInitialContextFactoryBuilder
>>>    *      NamingManager.setInitialContextFactoryBuilder
>>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
>>> + * @since 1.3, JNDI 1.1
>>>    */
>>>
>>>   public class InitialContext implements Context {
>>>



From bradford.wetmore at oracle.com  Mon Jun 23 21:24:21 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 23 Jun 2014 14:24:21 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A892FB.8060507@oracle.com>
References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com>
	<53A892FB.8060507@oracle.com>
Message-ID: <53A89B05.4030509@oracle.com>

JCE (Cipher) changes look good to me.

Let me know if there's any problem with the point I mentioned in the 
other email.

Brad



On 6/23/2014 1:50 PM, Henry Jen wrote:
> OK, I'll remove all @since JCE line, as the class already has @since 1.4
> as Joe pointed out earlier.
>
> Uodated webrev at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
>
> Cheers,
> Henry
>
>
> On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
>> I would prefer that JCE1.2 be pulled out completely in the Cipher*
>> classes.  I will be sending you a separate note about JCE logistics.
>>
>> Thanks for doing this cleanup.
>>
>> Brad
>>
>>
>> On 6/20/2014 11:46 AM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a trivial webrev to add JDK version to @since in a format
>>> as Mark suggested[1].
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html
>>>
>>> Appened is the diff as in the webrev.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>> diff --git a/src/share/classes/java/lang/Package.java
>>> b/src/share/classes/java/lang/Package.java
>>> --- a/src/share/classes/java/lang/Package.java
>>> +++ b/src/share/classes/java/lang/Package.java
>>> @@ -107,6 +107,7 @@
>>>    * loader to be found.
>>>    *
>>>    * @see ClassLoader#definePackage
>>> + * @since 1.2
>>>    */
>>>   public class Package implements java.lang.reflect.AnnotatedElement {
>>>       /**
>>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
>>> b/src/share/classes/javax/crypto/CipherInputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherInputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java
>>> @@ -170,7 +170,7 @@
>>>        * @return  the next byte of data, or -1 if the end
>>> of the
>>>        *          stream is reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public int read() throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -196,7 +196,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read(byte[], int, int)
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[]) throws IOException {
>>>           return read(b, 0, b.length);
>>> @@ -217,7 +217,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read()
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[], int off, int len) throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -254,7 +254,7 @@
>>>        * @param      n the number of bytes to be skipped.
>>>        * @return     the actual number of bytes skipped.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public long skip(long n) throws IOException {
>>>           int available = ofinish - ostart;
>>> @@ -277,7 +277,7 @@
>>>        * @return     the number of bytes that can be read from this
>>> input stream
>>>        *             without blocking.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int available() throws IOException {
>>>           return (ofinish - ostart);
>>> @@ -292,7 +292,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> @@ -321,7 +321,7 @@
>>>        *          mark and reset methods.
>>>        * @see     java.io.InputStream#mark(int)
>>>        * @see     java.io.InputStream#reset()
>>> -     * @since   JCE1.2
>>> +     * @since   1.4, JCE1.2
>>>        */
>>>       public boolean markSupported() {
>>>           return false;
>>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> @@ -114,7 +114,7 @@
>>>        *
>>>        * @param      b   the byte.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(int b) throws IOException {
>>>           ibuffer[0] = (byte) b;
>>> @@ -138,7 +138,7 @@
>>>        * @exception  NullPointerException if b is null.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        javax.crypto.CipherOutputStream#write(byte[], int,
>>> int)
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void write(byte b[]) throws IOException {
>>>           write(b, 0, b.length);
>>> @@ -152,7 +152,7 @@
>>>        * @param      off   the start offset in the data.
>>>        * @param      len   the number of bytes to write.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(byte b[], int off, int len) throws IOException {
>>>           obuffer = cipher.update(b, off, len);
>>> @@ -174,7 +174,7 @@
>>>        * the cipher's block size, no bytes will be written out.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void flush() throws IOException {
>>>           if (obuffer != null) {
>>> @@ -198,7 +198,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> diff --git a/src/share/classes/javax/naming/InitialContext.java
>>> b/src/share/classes/javax/naming/InitialContext.java
>>> --- a/src/share/classes/javax/naming/InitialContext.java
>>> +++ b/src/share/classes/javax/naming/InitialContext.java
>>> @@ -125,7 +125,7 @@
>>>    * @see Context
>>>    * @see NamingManager#setInitialContextFactoryBuilder
>>>    *      NamingManager.setInitialContextFactoryBuilder
>>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
>>> + * @since 1.3, JNDI 1.1
>>>    */
>>>
>>>   public class InitialContext implements Context {
>>>


From pbenedict at apache.org  Mon Jun 23 21:28:47 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 23 Jun 2014 16:28:47 -0500
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: <53A892FB.8060507@oracle.com>
References: <53A4819F.5080906@oracle.com> <53A85E22.1000009@oracle.com>
	<53A892FB.8060507@oracle.com>
Message-ID: 

What's the rationale for removing the secondary version? Or I guess the
question should really be: when are secondary versions useful? At least in
the EE specs, the EE version plus the spec version are listed in many
places like this.


Cheers,
Paul


On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen  wrote:

> OK, I'll remove all @since JCE line, as the class already has @since 1.4
> as Joe pointed out earlier.
>
> Uodated webrev at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
>
> Cheers,
> Henry
>
>
>
> On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
>
>> I would prefer that JCE1.2 be pulled out completely in the Cipher*
>> classes.  I will be sending you a separate note about JCE logistics.
>>
>> Thanks for doing this cleanup.
>>
>> Brad
>>
>>
>> On 6/20/2014 11:46 AM, Henry Jen wrote:
>>
>>> Hi,
>>>
>>> Please review a trivial webrev to add JDK version to @since in a format
>>> as Mark suggested[1].
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/
>>> 000806.html
>>>
>>> Appened is the diff as in the webrev.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>> diff --git a/src/share/classes/java/lang/Package.java
>>> b/src/share/classes/java/lang/Package.java
>>> --- a/src/share/classes/java/lang/Package.java
>>> +++ b/src/share/classes/java/lang/Package.java
>>> @@ -107,6 +107,7 @@
>>>    * loader to be found.
>>>    *
>>>    * @see ClassLoader#definePackage
>>> + * @since 1.2
>>>    */
>>>   public class Package implements java.lang.reflect.AnnotatedElement {
>>>       /**
>>> diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
>>> b/src/share/classes/javax/crypto/CipherInputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherInputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherInputStream.java
>>> @@ -170,7 +170,7 @@
>>>        * @return  the next byte of data, or -1 if the end
>>> of the
>>>        *          stream is reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public int read() throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -196,7 +196,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read(byte[], int, int)
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[]) throws IOException {
>>>           return read(b, 0, b.length);
>>> @@ -217,7 +217,7 @@
>>>        *             the stream has been reached.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        java.io.InputStream#read()
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int read(byte b[], int off, int len) throws IOException {
>>>           if (ostart >= ofinish) {
>>> @@ -254,7 +254,7 @@
>>>        * @param      n the number of bytes to be skipped.
>>>        * @return     the actual number of bytes skipped.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public long skip(long n) throws IOException {
>>>           int available = ofinish - ostart;
>>> @@ -277,7 +277,7 @@
>>>        * @return     the number of bytes that can be read from this
>>> input stream
>>>        *             without blocking.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public int available() throws IOException {
>>>           return (ofinish - ostart);
>>> @@ -292,7 +292,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> @@ -321,7 +321,7 @@
>>>        *          mark and reset methods.
>>>        * @see     java.io.InputStream#mark(int)
>>>        * @see     java.io.InputStream#reset()
>>> -     * @since   JCE1.2
>>> +     * @since   1.4, JCE1.2
>>>        */
>>>       public boolean markSupported() {
>>>           return false;
>>> diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> --- a/src/share/classes/javax/crypto/CipherOutputStream.java
>>> +++ b/src/share/classes/javax/crypto/CipherOutputStream.java
>>> @@ -114,7 +114,7 @@
>>>        *
>>>        * @param      b   the byte.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(int b) throws IOException {
>>>           ibuffer[0] = (byte) b;
>>> @@ -138,7 +138,7 @@
>>>        * @exception  NullPointerException if b is null.
>>>        * @exception  IOException  if an I/O error occurs.
>>>        * @see        javax.crypto.CipherOutputStream#write(byte[], int,
>>> int)
>>> -     * @since JCE1.2
>>> +     * @since 1.4, JCE1.2
>>>        */
>>>       public void write(byte b[]) throws IOException {
>>>           write(b, 0, b.length);
>>> @@ -152,7 +152,7 @@
>>>        * @param      off   the start offset in the data.
>>>        * @param      len   the number of bytes to write.
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void write(byte b[], int off, int len) throws IOException {
>>>           obuffer = cipher.update(b, off, len);
>>> @@ -174,7 +174,7 @@
>>>        * the cipher's block size, no bytes will be written out.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void flush() throws IOException {
>>>           if (obuffer != null) {
>>> @@ -198,7 +198,7 @@
>>>        * stream.
>>>        *
>>>        * @exception  IOException  if an I/O error occurs.
>>> -     * @since      JCE1.2
>>> +     * @since      1.4, JCE1.2
>>>        */
>>>       public void close() throws IOException {
>>>           if (closed) {
>>> diff --git a/src/share/classes/javax/naming/InitialContext.java
>>> b/src/share/classes/javax/naming/InitialContext.java
>>> --- a/src/share/classes/javax/naming/InitialContext.java
>>> +++ b/src/share/classes/javax/naming/InitialContext.java
>>> @@ -125,7 +125,7 @@
>>>    * @see Context
>>>    * @see NamingManager#setInitialContextFactoryBuilder
>>>    *      NamingManager.setInitialContextFactoryBuilder
>>> - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
>>> + * @since 1.3, JNDI 1.1
>>>    */
>>>
>>>   public class InitialContext implements Context {
>>>
>>>


From bradford.wetmore at oracle.com  Mon Jun 23 22:44:58 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 23 Jun 2014 15:44:58 -0700
Subject: RFR: 8047721: @since should have JDK version
In-Reply-To: 
References: <53A4819F.5080906@oracle.com>	<53A85E22.1000009@oracle.com>	<53A892FB.8060507@oracle.com>
	
Message-ID: <53A8ADEA.7030904@oracle.com>

Except for these two classes, none of the JCE APIs ever contained @since 
until the JCE was put into JDK 1.4 back in 2002.  The unbundled JCE 
hasn't been shipped in probably almost a decade.  None of the unbundled 
JSSE/JGSS should have them either.

Carrying around this old information is just cruft, IMO.

Brad





On 6/23/2014 2:28 PM, Paul Benedict wrote:
> What's the rationale for removing the secondary version? Or I guess the
> question should really be: when are secondary versions useful? At least
> in the EE specs, the EE version plus the spec version are listed in many
> places like this.
>
>
> Cheers,
> Paul
>
>
> On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen  > wrote:
>
>     OK, I'll remove all @since JCE line, as the class already has @since
>     1.4 as Joe pointed out earlier.
>
>     Uodated webrev at
>
>     http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/2/__webrev/
>     
>
>     Cheers,
>     Henry
>
>
>
>     On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
>
>         I would prefer that JCE1.2 be pulled out completely in the Cipher*
>         classes.  I will be sending you a separate note about JCE logistics.
>
>         Thanks for doing this cleanup.
>
>         Brad
>
>
>         On 6/20/2014 11:46 AM, Henry Jen wrote:
>
>             Hi,
>
>             Please review a trivial webrev to add JDK version to @since
>             in a format
>             as Mark suggested[1].
>
>             http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/0/__webrev/
>             
>
>             [1]
>             http://mail.openjdk.java.net/__pipermail/jdk9-dev/2014-June/__000806.html
>             
>
>             Appened is the diff as in the webrev.
>
>             Cheers,
>             Henry
>
>
>             diff --git a/src/share/classes/java/lang/__Package.java
>             b/src/share/classes/java/lang/__Package.java
>             --- a/src/share/classes/java/lang/__Package.java
>             +++ b/src/share/classes/java/lang/__Package.java
>             @@ -107,6 +107,7 @@
>                 * loader to be found.
>                 *
>                 * @see ClassLoader#definePackage
>             + * @since 1.2
>                 */
>                public class Package implements
>             java.lang.reflect.__AnnotatedElement {
>                    /**
>             diff --git
>             a/src/share/classes/javax/__crypto/CipherInputStream.java
>             b/src/share/classes/javax/__crypto/CipherInputStream.java
>             --- a/src/share/classes/javax/__crypto/CipherInputStream.java
>             +++ b/src/share/classes/javax/__crypto/CipherInputStream.java
>             @@ -170,7 +170,7 @@
>                     * @return  the next byte of data, or -1
>             if the end
>             of the
>                     *          stream is reached.
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since JCE1.2
>             +     * @since 1.4, JCE1.2
>                     */
>                    public int read() throws IOException {
>                        if (ostart >= ofinish) {
>             @@ -196,7 +196,7 @@
>                     *             the stream has been reached.
>                     * @exception  IOException  if an I/O error occurs.
>                     * @see        java.io.InputStream#read(byte[__],
>             int, int)
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public int read(byte b[]) throws IOException {
>                        return read(b, 0, b.length);
>             @@ -217,7 +217,7 @@
>                     *             the stream has been reached.
>                     * @exception  IOException  if an I/O error occurs.
>                     * @see        java.io.InputStream#read()
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public int read(byte b[], int off, int len) throws
>             IOException {
>                        if (ostart >= ofinish) {
>             @@ -254,7 +254,7 @@
>                     * @param      n the number of bytes to be skipped.
>                     * @return     the actual number of bytes skipped.
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since JCE1.2
>             +     * @since 1.4, JCE1.2
>                     */
>                    public long skip(long n) throws IOException {
>                        int available = ofinish - ostart;
>             @@ -277,7 +277,7 @@
>                     * @return     the number of bytes that can be read
>             from this
>             input stream
>                     *             without blocking.
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public int available() throws IOException {
>                        return (ofinish - ostart);
>             @@ -292,7 +292,7 @@
>                     * stream.
>                     *
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since JCE1.2
>             +     * @since 1.4, JCE1.2
>                     */
>                    public void close() throws IOException {
>                        if (closed) {
>             @@ -321,7 +321,7 @@
>                     *          mark and reset
>             methods.
>                     * @see     java.io.InputStream#mark(int)
>                     * @see     java.io.InputStream#reset()
>             -     * @since   JCE1.2
>             +     * @since   1.4, JCE1.2
>                     */
>                    public boolean markSupported() {
>                        return false;
>             diff --git
>             a/src/share/classes/javax/__crypto/CipherOutputStream.java
>             b/src/share/classes/javax/__crypto/CipherOutputStream.java
>             --- a/src/share/classes/javax/__crypto/CipherOutputStream.java
>             +++ b/src/share/classes/javax/__crypto/CipherOutputStream.java
>             @@ -114,7 +114,7 @@
>                     *
>                     * @param      b   the byte.
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public void write(int b) throws IOException {
>                        ibuffer[0] = (byte) b;
>             @@ -138,7 +138,7 @@
>                     * @exception  NullPointerException if b
>             is null.
>                     * @exception  IOException  if an I/O error occurs.
>                     * @see
>               javax.crypto.__CipherOutputStream#write(byte[__], int,
>             int)
>             -     * @since JCE1.2
>             +     * @since 1.4, JCE1.2
>                     */
>                    public void write(byte b[]) throws IOException {
>                        write(b, 0, b.length);
>             @@ -152,7 +152,7 @@
>                     * @param      off   the start offset in the data.
>                     * @param      len   the number of bytes to write.
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public void write(byte b[], int off, int len) throws
>             IOException {
>                        obuffer = cipher.update(b, off, len);
>             @@ -174,7 +174,7 @@
>                     * the cipher's block size, no bytes will be written out.
>                     *
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public void flush() throws IOException {
>                        if (obuffer != null) {
>             @@ -198,7 +198,7 @@
>                     * stream.
>                     *
>                     * @exception  IOException  if an I/O error occurs.
>             -     * @since      JCE1.2
>             +     * @since      1.4, JCE1.2
>                     */
>                    public void close() throws IOException {
>                        if (closed) {
>             diff --git
>             a/src/share/classes/javax/__naming/InitialContext.java
>             b/src/share/classes/javax/__naming/InitialContext.java
>             --- a/src/share/classes/javax/__naming/InitialContext.java
>             +++ b/src/share/classes/javax/__naming/InitialContext.java
>             @@ -125,7 +125,7 @@
>                 * @see Context
>                 * @see NamingManager#__setInitialContextFactoryBuilde__r
>                 *      NamingManager.__setInitialContextFactoryBuilde__r
>             - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3
>             + * @since 1.3, JNDI 1.1
>                 */
>
>                public class InitialContext implements Context {
>
>


From coleen.phillimore at oracle.com  Mon Jun 23 23:45:44 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 23 Jun 2014 19:45:44 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A3A402.2060501@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
	<53A3A402.2060501@oracle.com>
Message-ID: <53A8BC28.6030008@oracle.com>


Please review a change to the JDK code for adding classLoader field to 
the instances of java/lang/Class.  This change restricts reflection from 
changing access to the classLoader field.  In the spec, 
AccessibleObject.setAccessible() may throw SecurityException if the 
accessibility of an object may not be changed:

http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)

Only AccessibleObject.java has changes from the previous version of this 
change.

open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
bug link https://bugs.openjdk.java.net/browse/JDK-6642881

Thanks,
Coleen

On 6/19/14, 11:01 PM, David Holmes wrote:
> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>> Hi Mandy,
>>
>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>
>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>> Hi,
>>>>
>>>> On 19 jun 2014, at 20:46, Coleen Phillimore 
>>>>  wrote:
>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>> Have you considered hiding the Class.classLoader field from 
>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on 
>>>>>> the idea of people poking at this field with Unsafe (which should 
>>>>>> go away in 9 but ?).
>>>>> I don't know how to hide the field from reflection.  It's a 
>>>>> private final field so you need to get priviledges to make it 
>>>>> setAccessible.  If you mean injecting it on the JVM side, the 
>>>>> reason for this change is so that the JIT compilers can inline 
>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>
>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides 
>>>> a field from being found using reflection. It might very well be 
>>>> the case that private and final is enough, I haven?t thought this 
>>>> through 100%. On the other hand, is there a reason to give users 
>>>> access through the field instead of having to use 
>>>> Class.getClassLoader()?
>>>>
>>> There are many getter methods that returns a private final field.
>>> I'm not sure if hiding the field is necessary nor a good precedence
>>> to set. Accessing a private field requires "accessDeclaredMember"
>>> permission although it's a different security check (vs 
>>> "getClassLoader"
>>> permission).  Arguably before this new classLoader field, one could
>>> call Class.getClassLoader0() via reflection to get a hold of class
>>> loader.
>>>
>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>> is too coarse-grained?  I think the security team is looking into
>>> the improvement in that regards.
>>
>> I think I?m a bit worried about two things, first as you wrote, 
>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since 
>> you could get the class loader through getClassLoader0() that 
>> shouldn?t be a new issue.
>>
>> The second thing is that IIRC there are ways to set a final field 
>> after initialization. I?m not sure we need to care about that either 
>> if you need Unsafe to do it.
>
> Normal reflection can set a final field if you can successfully call 
> setAccessible(true) on the Field object.
>
> David
> -----
>
>
>> cheers
>> /Joel
>>



From huizhe.wang at oracle.com  Tue Jun 24 00:14:20 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 23 Jun 2014 17:14:20 -0700
Subject: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo
In-Reply-To: <53A3FE3D.7050008@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
	<53A3301B.7070405@oracle.com> <53A3F40B.1040108@oracle.com>
	<53A3FE3D.7050008@oracle.com>
Message-ID: <53A8C2DC.2090500@oracle.com>


On 6/20/2014 2:26 AM, Alan Bateman wrote:
> On 20/06/2014 09:42, Patrick Zhang wrote:
>> Hi Team,
>>
>> 8035490 is one task used to track xml code colocation from sqe repo 
>> into jaxp repo.
>> As one initial change set, it includes below materials:
>> 1. TEST.ROOT to declare test code location.
>> 2. ProblemList.txt to exclude 6 tests which have been discussed on past.
>> 3. One Makefile to support future jprt/aurora execution.
>> 4. test code located in bugxxx dir. All are based on testNG.
>>
>>
>> webrev:
>> http://cr.openjdk.java.net/~pzhang/xml_colocation/8035490/webrev/
>>
>> :
>>
> (Moving this thread this to core-libs-dev).

+1!  Patrick, please send future review request to core-libs-dev.

It's a great effort from the SQE team and Patrick migrating all of the 
jaxp tests into the OpenJDK repo. Thanks again!

>
> At a high-level then it's good to have the tests for JAXP in the same 
> repository as the code. I've only skimmed over these webrev (not a 
> review) and they look like they are mostly regression tests for 
> specific bugs - is that right?

Yes.  This is the first set of jaxp tests to be migrated. To help 
understand jaxp test, here is what it looks like:
JAXP tests -
            - 1. JAXP Unit tests
                - a. those named after bug id
                - b. javax.xml.datatype
                - c. javax.xml.parsers
                - d. javax.xml.stream
                - e. javax.xml.transform
                - f. javax.xml.validation
                - g. javax.xml.xpath
                - h. org.w3c.dom
                - i. org.w3c.saxtest

            - 2. JAXP SQE (function) tests
                - a. product tests
                - b. ASTRO xsltc tests
                - c. Auction Portal tests
                - d. GAP tests
                - e. XSLT tests


1a were some of the oldest unit tests that were put in packages by their 
bug ids. Newer tests were named after their corresponding API package names.

Patrick's plan is to migrate 1 (unit tests) in 4 batches. The 1st (this 
one) covers 1a.

>
> One thing that concerns me a bit is that none of the .java files that 
> I looked at have any comments to say what the test does. Is there 
> anything that could be brought over from the original issue in JIRA to 
> explain what each of these tests is about?

It would have been nice if they had comments. But adding comments would 
be too much work, unnecessary I would think. These tests serve their 
purpose, that is, preventing regressions. In case any fails, its bugid 
would allow us to easily find out what it was testing.

>
> Is Hello.wsdl.data a binary file? Have any alternatives been looked at?

It's UTF-16 encoded. Patrick and I looked at it earlier. Mercurial has 
no problem handling binary. Would you think it'd cause any problem?  If 
it's really unwanted, we can look into modifying the test.

>
> As you mention ProblemList.txt then I see that it has headings that 
> don't make sense in the jaxp repository, maybe they should be removed.
>
> The webrev only has the changes for jaxp repository, will there be 
> follow-on changes to make it runnable at the top level, JPRT 
> configuration, etc.

I think that'd be jdk_jaxp. Patrick, you've run JPRT, correct?

-Joe

>
> -Alan



From henry.jen at oracle.com  Tue Jun 24 00:31:54 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 23 Jun 2014 17:31:54 -0700
Subject: RFR: 8042872: Fix raw and unchecked warnings in sun.applet
Message-ID: <53A8C6FA.2000801@oracle.com>

Hi,

Please review another webrev to clean up rawtypes and unchecked warning, 
this time for sun.applet.

The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not 
sure which repo should the webrev go once pass review.

Webrev can be found at
http://cr.openjdk.java.net/~henryjen/jdk9/8042872/0/webrev/

Please also let me know any particular test I should do other than 
regular jprt.

Cheers,
Henry


From mike.duigou at oracle.com  Tue Jun 24 00:42:16 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 23 Jun 2014 17:42:16 -0700
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
Message-ID: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>

Hello all;

This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked into the wrapped list.

This changeset adds a check on the proposed replacement value and throws a ClassCastException if the replacement value is incompatible with the list. Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.

Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.

jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/

This change will be backported to Java 8.

Mike

From joe.darcy at oracle.com  Tue Jun 24 01:03:59 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jun 2014 18:03:59 -0700
Subject: RFR: 8042872: Fix raw and unchecked warnings in sun.applet
In-Reply-To: <53A8C6FA.2000801@oracle.com>
References: <53A8C6FA.2000801@oracle.com>
Message-ID: <53A8CE7F.4030302@oracle.com>

Hi Henry,

The changes look good to me; thanks,

-Joe

On 06/23/2014 05:31 PM, Henry Jen wrote:
> Hi,
>
> Please review another webrev to clean up rawtypes and unchecked 
> warning, this time for sun.applet.
>
> The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not 
> sure which repo should the webrev go once pass review.
>
> Webrev can be found at
> http://cr.openjdk.java.net/~henryjen/jdk9/8042872/0/webrev/
>
> Please also let me know any particular test I should do other than 
> regular jprt.
>
> Cheers,
> Henry



From mandy.chung at oracle.com  Tue Jun 24 01:36:57 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jun 2014 18:36:57 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
	<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
Message-ID: <53A8D639.8030605@oracle.com>

Coleen,

On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to 
> the instances of java/lang/Class.  This change restricts reflection 
> from changing access to the classLoader field.  In the spec, 
> AccessibleObject.setAccessible() may throw SecurityException if the 
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>
>
> Only AccessibleObject.java has changes from the previous version of 
> this change.
>

This change looks reasonable.    As a side note:  Joel mentions about 
the mechanism to hide class members from reflection.   I discussed with 
Joel offline before he went on parental leave and suggest that we should 
revisit the two mechanisms that both effectively disallow access to 
private members in the future.

Mandy

> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen
>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore 
>>>>>  wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from 
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on 
>>>>>>> the idea of people poking at this field with Unsafe (which 
>>>>>>> should go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection. It's a 
>>>>>> private final field so you need to get priviledges to make it 
>>>>>> setAccessible.  If you mean injecting it on the JVM side, the 
>>>>>> reason for this change is so that the JIT compilers can inline 
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that 
>>>>> hides a field from being found using reflection. It might very 
>>>>> well be the case that private and final is enough, I haven?t 
>>>>> thought this through 100%. On the other hand, is there a reason to 
>>>>> give users access through the field instead of having to use 
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs 
>>>> "getClassLoader"
>>>> permission).  Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained?  I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote, 
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since 
>>> you could get the class loader through getClassLoader0() that 
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field 
>>> after initialization. I?m not sure we need to care about that either 
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call 
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>



From coleen.phillimore at oracle.com  Tue Jun 24 01:44:53 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 23 Jun 2014 21:44:53 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8D639.8030605@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
	<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
	<53A8D639.8030605@oracle.com>
Message-ID: <53A8D815.8000901@oracle.com>


On 6/23/14, 9:36 PM, Mandy Chung wrote:
> Coleen,
>
> On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field 
>> to the instances of java/lang/Class.  This change restricts 
>> reflection from changing access to the classLoader field.  In the 
>> spec, AccessibleObject.setAccessible() may throw SecurityException if 
>> the accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>>
>>
>> Only AccessibleObject.java has changes from the previous version of 
>> this change.
>>
>
> This change looks reasonable.    As a side note:  Joel mentions about 
> the mechanism to hide class members from reflection.   I discussed 
> with Joel offline before he went on parental leave and suggest that we 
> should revisit the two mechanisms that both effectively disallow 
> access to private members in the future.

Thanks, Mandy.  Yes, let me know what you come up with and we can 
improve this.  Thank you for the help fixing this bug.

Coleen

>
> Mandy
>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore 
>>>>>>  wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from 
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on 
>>>>>>>> the idea of people poking at this field with Unsafe (which 
>>>>>>>> should go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a 
>>>>>>> private final field so you need to get priviledges to make it 
>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the 
>>>>>>> reason for this change is so that the JIT compilers can inline 
>>>>>>> this call and not have to call into the JVM to get the class 
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that 
>>>>>> hides a field from being found using reflection. It might very 
>>>>>> well be the case that private and final is enough, I haven?t 
>>>>>> thought this through 100%. On the other hand, is there a reason 
>>>>>> to give users access through the field instead of having to use 
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs 
>>>>> "getClassLoader"
>>>>> permission).  Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained?  I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote, 
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but 
>>>> since you could get the class loader through getClassLoader0() that 
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field 
>>>> after initialization. I?m not sure we need to care about that 
>>>> either if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call 
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>



From david.holmes at oracle.com  Tue Jun 24 02:11:51 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jun 2014 12:11:51 +1000
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8D815.8000901@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
	<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
	<53A8D639.8030605@oracle.com> <53A8D815.8000901@oracle.com>
Message-ID: <53A8DE67.60808@oracle.com>

On 24/06/2014 11:44 AM, Coleen Phillimore wrote:
>
> On 6/23/14, 9:36 PM, Mandy Chung wrote:
>> Coleen,
>>
>> On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>>>
>>> Please review a change to the JDK code for adding classLoader field
>>> to the instances of java/lang/Class.  This change restricts
>>> reflection from changing access to the classLoader field.  In the
>>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>>> the accessibility of an object may not be changed:
>>>
>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>>
>>>
>>> Only AccessibleObject.java has changes from the previous version of
>>> this change.
>>>
>>
>> This change looks reasonable.    As a side note:  Joel mentions about
>> the mechanism to hide class members from reflection.   I discussed
>> with Joel offline before he went on parental leave and suggest that we
>> should revisit the two mechanisms that both effectively disallow
>> access to private members in the future.
>
> Thanks, Mandy.  Yes, let me know what you come up with and we can
> improve this.  Thank you for the help fixing this bug.

Note that completely hiding something from reflection is different to 
controlling its accessability via reflection. I think what is being done 
here is the right way to go.

The changes look okay to me.

Thanks,
David


> Coleen
>
>>
>> Mandy
>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>>
>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>>  wrote:
>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>>> should go away in 9 but ?).
>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>> loader.
>>>>>>>>
>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>>> hides a field from being found using reflection. It might very
>>>>>>> well be the case that private and final is enough, I haven?t
>>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>>> to give users access through the field instead of having to use
>>>>>>> Class.getClassLoader()?
>>>>>>>
>>>>>> There are many getter methods that returns a private final field.
>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>> permission although it's a different security check (vs
>>>>>> "getClassLoader"
>>>>>> permission).  Arguably before this new classLoader field, one could
>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>> loader.
>>>>>>
>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>> is too coarse-grained?  I think the security team is looking into
>>>>>> the improvement in that regards.
>>>>>
>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>>> since you could get the class loader through getClassLoader0() that
>>>>> shouldn?t be a new issue.
>>>>>
>>>>> The second thing is that IIRC there are ways to set a final field
>>>>> after initialization. I?m not sure we need to care about that
>>>>> either if you need Unsafe to do it.
>>>>
>>>> Normal reflection can set a final field if you can successfully call
>>>> setAccessible(true) on the Field object.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>
>>
>


From Alan.Bateman at oracle.com  Tue Jun 24 07:13:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jun 2014 08:13:29 +0100
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com>
Message-ID: <53A92519.6010407@oracle.com>

On 24/06/2014 00:45, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to 
> the instances of java/lang/Class.  This change restricts reflection 
> from changing access to the classLoader field.  In the spec, 
> AccessibleObject.setAccessible() may throw SecurityException if the 
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>
>
> Only AccessibleObject.java has changes from the previous version of 
> this change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
Having setAccessible throw SecurityException when there isn't a security 
manager set is a bit odd but as you point out, setAccessible is 
specified to allow that. The changes looks okay, although I don't think 
strictly necessary.

-Alan.


From Alan.Bateman at oracle.com  Tue Jun 24 07:19:36 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jun 2014 08:19:36 +0100
Subject: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo
In-Reply-To: <53A8C2DC.2090500@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
	<53A3301B.7070405@oracle.com> <53A3F40B.1040108@oracle.com>
	<53A3FE3D.7050008@oracle.com> <53A8C2DC.2090500@oracle.com>
Message-ID: <53A92688.50502@oracle.com>

On 24/06/2014 01:14, huizhe wang wrote:
> :
>
>>
>> One thing that concerns me a bit is that none of the .java files that 
>> I looked at have any comments to say what the test does. Is there 
>> anything that could be brought over from the original issue in JIRA 
>> to explain what each of these tests is about?
>
> It would have been nice if they had comments. But adding comments 
> would be too much work, unnecessary I would think. These tests serve 
> their purpose, that is, preventing regressions. In case any fails, its 
> bugid would allow us to easily find out what it was testing.
If there is a test failure then whoever runs into it will need to 
decypher what the test is about. I would think that it would at least be 
helpful to have a short summary at the top to give some indication as to 
what it is doing. Are we even sure that all the issues are accessible to 
all in JIRA?

-Alan


From paul.sandoz at oracle.com  Tue Jun 24 08:18:39 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Jun 2014 10:18:39 +0200
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
Message-ID: 


On Jun 24, 2014, at 2:42 AM, Mike Duigou  wrote:

> Hello all;
> 
> This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked into the wrapped list.
> 
> This changeset adds a check on the proposed replacement value and throws a ClassCastException if the replacement value is incompatible with the list.

That seems like a reasonable approach and it's in sync with the behaviour of Map.replaceAll.


> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
> 

No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:

3388      * Any attempt to insert an element of the wrong type will result in
3389      * an immediate {@link ClassCastException}.  Assuming a list contains


> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
> 
> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
> 

Are there existing tests for the checked Map.replaceAll (for keys and values)?

Paul.
 
> This change will be backported to Java 8.
> 
> Mike



From youdwei at linux.vnet.ibm.com  Tue Jun 24 08:21:22 2014
From: youdwei at linux.vnet.ibm.com (deven you)
Date: Tue, 24 Jun 2014 16:21:22 +0800
Subject: A question about Depth of container annotations
Message-ID: 

Hi All,

I have a question about repeated annotation depth. If this is not the
proper mailing list group, please tell me where I should send it to.

My question will be about the depth of container annotations. For instance,
assume there are 3 annotations.
- RepeatedAnn
- ContainerAnn
- ContainerContainerAnn

So, ContainerContainerAnn can have ContainerAnn and that can also have
RepeatbleAnn in it.

In this case, get*AnnotationsByType(RepeatableAnn) APIs wont return
repeteableAnns in depth 2.

Java docs don't talk about the depth. I wonder if the get*AnnotationsByType
api should return the annotations of all depth?

If we have below annotations:
@Retention(RetentionPolicy.RUNTIME)
@Repeatable(ContainerAnn.class)
@interface RepeatableAnn { String value(); }

@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Repeatable(ContainerContainerAnn.class)
@interface ContainerAnn { RepeatableAnn[] value(); }

@Inherited
@Retention(RetentionPolicy.RUNTIME)
@interface ContainerContainerAnn { ContainerAnn[] value(); }

And the main class is annotated by :

@ContainerAnn({@RepeatableAnn("Parent-3")})
@ContainerAnn({@RepeatableAnn("Parent-4")})
public class Test { ...

when we call getAnnotationsByType(RepeatableAnn.class) on this class, we
get nothing because RepeatableAnn is contained by ContainerAnn which is
also contained by ContainerContainerAnn. In other words, RepeatableAnn is
in depth 2 and get*AnnotationsByType APIs only searches depth 1. The test
results are:

/home/deven/jdk8_20/jdk1.8.0_20/bin$ java repeated.Test
CLASS = repeated.Test
getDeclaredAnnotationsByType(RepeatableAnn.class)
getDeclaredAnnotationsByType(ContainerAnn.class)

@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)])

@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])
getDeclaredAnnotationsByType(ContainerContainerAnn.class)

@repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]),
@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])])
getAnnotationsByType(RepeatableAnn.class)
getAnnotationsByType(ContainerAnn.class)

@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)])

@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])
getAnnotationsByType(ContainerContainerAnn.class)

@repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]),
@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])])


From peter.levart at gmail.com  Tue Jun 24 08:23:39 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Jun 2014 10:23:39 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com>
Message-ID: <53A9358B.90102@gmail.com>

On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to 
> the instances of java/lang/Class.  This change restricts reflection 
> from changing access to the classLoader field.  In the spec, 
> AccessibleObject.setAccessible() may throw SecurityException if the 
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>
>
> Only AccessibleObject.java has changes from the previous version of 
> this change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen

Hi Coleen,

So hackers are prevented from hacking...

Out of curiosity, what would happen if someone changed the classLoader 
field of some Class object? I guess VM still has it's own notion of the 
class' class loader, right? Only the code that directly uses the 
Class.getClassLoader() (and Unsafe.defineClass0) methods would be 
affected...

While we're at it, does this change in any way affect the GC logic? Will 
GC now navigate the classLoader field during marking but previously 
didn't ? Will this have any GC performance penalty ?

Regards, Peter

>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore 
>>>>>  wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from 
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on 
>>>>>>> the idea of people poking at this field with Unsafe (which 
>>>>>>> should go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection. It's a 
>>>>>> private final field so you need to get priviledges to make it 
>>>>>> setAccessible.  If you mean injecting it on the JVM side, the 
>>>>>> reason for this change is so that the JIT compilers can inline 
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that 
>>>>> hides a field from being found using reflection. It might very 
>>>>> well be the case that private and final is enough, I haven?t 
>>>>> thought this through 100%. On the other hand, is there a reason to 
>>>>> give users access through the field instead of having to use 
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs 
>>>> "getClassLoader"
>>>> permission).  Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained?  I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote, 
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since 
>>> you could get the class loader through getClassLoader0() that 
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field 
>>> after initialization. I?m not sure we need to care about that either 
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call 
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>



From frederic.parain at oracle.com  Tue Jun 24 08:41:40 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 24 Jun 2014 10:41:40 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com>
Message-ID: <53A939C4.2080703@oracle.com>

Hi Coleen,

It seems that there's still a reference to JVM_GetClassLoader
in file jdk/src/share/native/common/check_code.c. The code looks
like dead code, but it would be nice to clean it up.

Thanks,

Fred

On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to
> the instances of java/lang/Class.  This change restricts reflection from
> changing access to the classLoader field.  In the spec,
> AccessibleObject.setAccessible() may throw SecurityException if the
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>
>
> Only AccessibleObject.java has changes from the previous version of this
> change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen
>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>  wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>> go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection.  It's a
>>>>>> private final field so you need to get priviledges to make it
>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>> a field from being found using reflection. It might very well be
>>>>> the case that private and final is enough, I haven?t thought this
>>>>> through 100%. On the other hand, is there a reason to give users
>>>>> access through the field instead of having to use
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs
>>>> "getClassLoader"
>>>> permission).  Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained?  I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote,
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>> you could get the class loader through getClassLoader0() that
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field
>>> after initialization. I?m not sure we need to care about that either
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From chris.hegarty at oracle.com  Tue Jun 24 08:46:09 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Jun 2014 09:46:09 +0100
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
Message-ID: <43D2525D-ABCC-41F6-BEF7-D88E82F3B7B8@oracle.com>

Looks good to me Mike.

I agree with Paul?s comment that the javadoc change will never be seen in the public docs, but I still think it is a reasonable addition for future maintainers.

Trivially, you should probably add @SuppressWarnings("unchecked?) to typeCheck(Object).

-Chris.

On 24 Jun 2014, at 01:42, Mike Duigou  wrote:

> Hello all;
> 
> This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked into the wrapped list.
> 
> This changeset adds a check on the proposed replacement value and throws a ClassCastException if the replacement value is incompatible with the list. Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
> 
> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
> 
> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
> 
> This change will be backported to Java 8.
> 
> Mike



From kumar.x.srinivasan at oracle.com  Tue Jun 24 12:36:53 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 24 Jun 2014 05:36:53 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A86350.4020802@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
	<53A4C34C.4010004@oracle.com> <53A4C799.900@oracle.com>
	<53A86350.4020802@oracle.com>
Message-ID: <53A970E5.8060908@oracle.com>

Neil,

Some nits:

TestSpecialArgs.java:

extra space
105 for ( String line : tr.testOutput) {



This is very C'ish, I suggest.
  -106                 int index;
  -107                 if ((index = line.indexOf(envVarPidString)) >= 0) {

  +106                 int index =  line.indexOf(envVarPidString);
  +107                 if (index >= 0) {


Needs space
-146 launcherPid = line.substring(sindex,tindex);
+146 launcherPid = line.substring(sindex, tindex);

Needs space

-168             if (!tr.contains("NativeMemoryTracking: got value "+NMT_Option_Value)) {
+168             if (!tr.contains("NativeMemoryTracking: got value " + NMT_Option_Value)) {


Thanks
Kumar


On 6/23/2014 10:26 AM, Neil Toda wrote:
>
> I've spun a new webrev based on the comments for webrev-03:
>
>     http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>
> Changes are:
>
>   1) java.c
>         a) add free(envName) line 1063
>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 1056
>
> Thanks
>
> -neil
>
> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>> Neil,
>>
>> Generally looks good, yes JLI_* functions must be used, I missed that 
>> one.
>> Are you going to post another iteration ?
>>
>> Kumar
>>
>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>
>>> Thanks Joe.  It would have checked for NULL for me.
>>> I'll use the JLI wrapper.
>>>
>>> -neil
>>>
>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>> Memory allocation in the launcher should use one of the 
>>>> JLI_MemAlloc wrappers, if possible.
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>
>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>>>> non-null.
>>>>>
>>>>> -neil
>>>>>
>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>> Neil,
>>>>>>
>>>>>> Thanks for quick implementation.
>>>>>>
>>>>>> java.c:
>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>> code analyzers will complain.
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>
>>>>>>> Launcher support for modified Native Memory Tracking mechanism 
>>>>>>> in JVM in JDK9.
>>>>>>>
>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From coleen.phillimore at oracle.com  Tue Jun 24 12:51:18 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 08:51:18 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A9358B.90102@gmail.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com> <53A9358B.90102@gmail.com>
Message-ID: <53A97446.4020205@oracle.com>


Hi Peter,

On 6/24/14, 4:23 AM, Peter Levart wrote:
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field 
>> to the instances of java/lang/Class.  This change restricts 
>> reflection from changing access to the classLoader field.  In the 
>> spec, AccessibleObject.setAccessible() may throw SecurityException if 
>> the accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>>
>>
>> Only AccessibleObject.java has changes from the previous version of 
>> this change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>
> Hi Coleen,
>
> So hackers are prevented from hacking...
>
> Out of curiosity, what would happen if someone changed the classLoader 
> field of some Class object? I guess VM still has it's own notion of 
> the class' class loader, right? Only the code that directly uses the 
> Class.getClassLoader() (and Unsafe.defineClass0) methods would be 
> affected...

True, Class.getClassLoader() calls would be affected but we may use this 
call for security checks.  I'm not really an expert on this, but we 
thought it wouldn't be safe to allow user access to classLoader.

>
> While we're at it, does this change in any way affect the GC logic? 
> Will GC now navigate the classLoader field during marking but 
> previously didn't ? Will this have any GC performance penalty ?

I actually ran this through our performance testing and got a good 
improvement in one of the scimark benchmarks for no reason I could 
explain (and lost the results), but none of the other tests were 
affected.  GC would have to mark this new field for full collections but 
not young collections because it's only set during initialization.   I 
wouldn't expect this field to have any negative performance for GC.

Thanks,
Coleen

>
> Regards, Peter
>
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore 
>>>>>>  wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from 
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on 
>>>>>>>> the idea of people poking at this field with Unsafe (which 
>>>>>>>> should go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a 
>>>>>>> private final field so you need to get priviledges to make it 
>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the 
>>>>>>> reason for this change is so that the JIT compilers can inline 
>>>>>>> this call and not have to call into the JVM to get the class 
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that 
>>>>>> hides a field from being found using reflection. It might very 
>>>>>> well be the case that private and final is enough, I haven?t 
>>>>>> thought this through 100%. On the other hand, is there a reason 
>>>>>> to give users access through the field instead of having to use 
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs 
>>>>> "getClassLoader"
>>>>> permission).  Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained?  I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote, 
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but 
>>>> since you could get the class loader through getClassLoader0() that 
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field 
>>>> after initialization. I?m not sure we need to care about that 
>>>> either if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call 
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>



From coleen.phillimore at oracle.com  Tue Jun 24 12:53:15 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 08:53:15 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A939C4.2080703@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
Message-ID: <53A974BB.1000809@oracle.com>


Fred,

Thank you for finding this.  Yes, I meant to clean this up with the bug 
to remove JVM_GetClassLoader but I should remove this with this change 
instead, since the other change will be in hotspot only.
Yes, it's dead code.

Thanks!
Coleen

On 6/24/14, 4:41 AM, Frederic Parain wrote:
> Hi Coleen,
>
> It seems that there's still a reference to JVM_GetClassLoader
> in file jdk/src/share/native/common/check_code.c. The code looks
> like dead code, but it would be nice to clean it up.
>
> Thanks,
>
> Fred
>
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field to
>> the instances of java/lang/Class.  This change restricts reflection from
>> changing access to the classLoader field.  In the spec,
>> AccessibleObject.setAccessible() may throw SecurityException if the
>> accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>>
>>
>>
>> Only AccessibleObject.java has changes from the previous version of this
>> change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>  wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>> go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class 
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>> a field from being found using reflection. It might very well be
>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>> access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission).  Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained?  I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>> you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that either
>>>> if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>



From paul.sandoz at oracle.com  Tue Jun 24 13:17:00 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Jun 2014 15:17:00 +0200
Subject: RFR: JDK-8044629: (reflect)
	Constructor.getAnnotatedReceiverType() returns wrong value
In-Reply-To: <1B51A5CD-A909-42C4-97D1-1F8F5DFE55D2@oracle.com>
References: <1B51A5CD-A909-42C4-97D1-1F8F5DFE55D2@oracle.com>
Message-ID: <9E339B30-A01D-4427-A2D1-A0E96E5A978C@oracle.com>


On Jun 17, 2014, at 6:52 PM, Joel Borggr?n-Franck  wrote:

> Hi,
> 
> Can I get a review for this fix and javadoc clarification for https://bugs.openjdk.java.net/browse/JDK-8044629
> 
> The problem is with potentially annotated receiver parameters, they only exist for inner class constructors, so this fix makes sure that a ctor is for an inner class or returns null (as for a static method) otherwise.
> 
> CCC has been approved.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8044629/webrev.00/
> 

+1

I never quite realised just how convoluted it was to determine that a class is an inner class.

Paul.



From peter.levart at gmail.com  Tue Jun 24 14:03:17 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Jun 2014 16:03:17 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>	
	
Message-ID: <53A98525.9080908@gmail.com>

Hi Martin,

On 06/22/2014 07:12 PM, Martin Buchholz wrote:
> We know that loading the networking machinery is problematic.  On Linux we
> would be content to hard-code a read from /dev/urandom, which is safer and
> strictly more random than the existing network hardware determination, but
> y'all will reject that as too system-dependent (insufficient machinery!).
> Hmmmm .... maybe not .... as long as we code up a good fallback ...
>
> I learned that SecureRandom by default on Unix uses /dev/random for "seed
> bytes" and /dev/urandom for nextBytes.
>
> Here's my proposal, that in the default case on Unix doesn't load any
> machinery, and as a fallback loads the SecureRandom machinery instead of
> the network machinery, while maintaining the ultra-secure behavior of the
> java.util.secureRandomSeed system property:
>
>
>      private static long initialSeed() {
>          byte[] seedBytes = initialSeedBytes();
>          long s = (long)(seedBytes[0]) & 0xffL;
>          for (int i = 1; i < seedBytes.length; ++i)
>              s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>          return s ^ mix64(System.currentTimeMillis()) ^
> mix64(System.nanoTime());
>      }
>
>      private static byte[] initialSeedBytes() {
>          String pp = java.security.AccessController.doPrivileged(
>                  new sun.security.action.GetPropertyAction(
>                          "java.util.secureRandomSeed"));
>          boolean secureRandomSeed = (pp != null &&
> pp.equalsIgnoreCase("true"));
>          if (secureRandomSeed)
>              return java.security.SecureRandom.getSeed(8);
>          final byte[] seedBytes = new byte[8];
>          File seedSource = new File("/dev/urandom");
>          if (seedSource.exists()) {
>              try (FileInputStream stream = new FileInputStream(seedSource)) {
>                  if (stream.read(seedBytes) == 8)
>                      return seedBytes;
>              } catch (IOException ignore) { }
>          }
>          new java.security.SecureRandom().nextBytes(seedBytes);
>          return seedBytes;
>      }

So on platforms lacking "/dev/urandom" special file (Windows only?), the 
fall-back would be to use SecureRandom.nextBytes() whatever default 
SecureRandom PRNG is configured to be on such platform. This might be a 
user-supplied SecureRandom PRNG. The user might want it's own default 
SecureRandom but not use it for TLR's seed computation (unless requested 
by "java.util.secureRandomSeed" system property).

I would rather use SecureRandom.generateSeed() instance method instead 
of SecureRandom.nextBytes(). Why? Because every SecureRandom instance 
has to initialize it's seed 1st before getBytes() can provide the next 
random bytes from the PRNG. Since we only need the 1st 8 bytes from the 
SecureRandom instance to initialize TLR's seeder, we might as well 
directly call the SecureRandom.generateSeed() method. That's one reason. 
The other is the peculiar initialization of default SecureRandom 
algorithm on Windows (see below)...

Even if user does not provide it's own default SecureRandom PRNG, there 
are basically two algorithms that are used by default on OpenJDK:

On Solaris/Linux/Mac/AIX:

the "NativePRNG" algorithm from "SUN" provider (implemented by 
sun.security.provider.NativePRNG) which uses /dev/random for getBytes() 
and /dev/urandom (or whatever is configured with "java.security.egd" or 
"securerandom.source" system properties) for generateSeed(), and

On Windows:

the "SHA1PRNG" algorithm from "SUN" provider (implemented by 
sun.security.provider.SecureRandom) which uses SHA1 message digest for 
generating random numbers with seed computed by gathering system entropy...


The most problematic one is the default on Windows platform (the 
platform that does not have the "/dev/urandom" special file and would be 
used as a fall-back by your proposal) - 
sun.security.provider.SecureRandom. This one seeds itself by 
constructing an instance of itself with the result returned from 
SeedGenerator.getSystemEntropy() method. This method, among other 
things, uses networking code to gather system entropy:

                         ...
                         md.update
(InetAddress.getLocalHost().toString().getBytes());
                         ...

This is problematic since it not only initializes NameService providers 
but also uses them to resolve local host name. This can block for 
several seconds on unusual configurations and was the main motivation to 
replace similar code in TLR with code that uses 
NetworkInterface.getHardwareAddress() instead. Using 
SecureRandom.generateSeed() instead of SecureRandom.getBytes() does not 
invoke SeedGenerator.getSystemEntropy(), but uses just 
SeedGenerator.generateSeed(), which by default on Windows uses 
ThreadedSeedGenerator.getSeedBytes()...

I showed how we could suppress NameService providers initialization 
while still using NetworkInterface.getHardwareAddress() for TLR's seeder 
initialization. If that's not enough and we would like to get-away 
without using networking code at all, then I propose the following:


     private static byte[] initialSeedBytes() {

         String secureRandomSeed = 
java.security.AccessController.doPrivileged(
             new sun.security.action.GetPropertyAction(
                 "java.util.secureRandomSeed", ""))
             .toLowerCase(Locale.ROOT);

         String osName = java.security.AccessController.doPrivileged(
             new sun.security.action.GetPropertyAction(
                 "os.name"))
             .toLowerCase(Locale.ROOT);

         if (!secureRandomSeed.equals("true") && 
!secureRandomSeed.equals("blocking")) {
             secureRandomSeed = "nonblocking"; // default
         }

         SecureRandom srnd = null;

         if (secureRandomSeed.equals("nonblocking")) { // the default
             try {
                 if (osName.startsWith("windows")) {
                     // native implementation using MSCAPI implemented by
                     // sun.security.mscapi.PRNG
                     srnd = SecureRandom.getInstance("Windows-PRNG", 
"SunMSCAPI");
                 } else { // Solaris/Linux/Mac/AIX
                     // a non-blocking native implementation using 
/dev/urandom for both
                     // generateSeed() and nextBytes() implemented by
                     // sun.security.provider.NativePRNG$NonBlocking
                     srnd = 
SecureRandom.getInstance("NativePRNGNonBlocking", "SUN");
                 }
             } catch (NoSuchProviderException | NoSuchAlgorithmException 
ignore) {}
         } else if (secureRandomSeed.equals("blocking")) {
             try {
                 if (osName.startsWith("windows")) {
                     // native implementation using MSCAPI implemented by
                     // sun.security.mscapi.PRNG
                     srnd = SecureRandom.getInstance("Windows-PRNG", 
"SunMSCAPI");
                 } else { // Solaris/Linux/Mac/AIX
                     // a blocking native implementation using 
/dev/random for both
                     // generateSeed() and nextBytes() implemented by
                     // sun.security.provider.NativePRNG$Blocking
                     srnd = 
SecureRandom.getInstance("NativePRNGBlocking", "SUN");
                 }
             } catch (NoSuchProviderException | NoSuchAlgorithmException 
ignore) {}
         } else {
             assert secureRandomSeed.equals("true");
         }

         if (srnd == null) { // fall back to default SecureRandom 
algorithm / provider
             srnd = new SecureRandom();
         }

         return srnd.generateSeed(8);
     }


By default (or when "java.util.secureRandomSeed" is set to "nonblocking" 
or unrecognized value) this would use /dev/urandom on UNIX-es and MSCAPI 
on Windows. More entropy for TLR's initial seeder could be provided on 
UNIX-es by risking some blocking with "java.util.secureRandomSeed" set 
to "blocking". This would still be independend of user's choice of 
default SecureRandom provider. The backward-compatible 
("java.util.secureRandomSeed" set to "true") or fall-back would be to 
use default SecureRandom algorithm / provider.

Regards, Peter

>
>
>
> On Sat, Jun 21, 2014 at 9:05 PM, Martin Buchholz 
> wrote:
>
>> While looking at NativePRNG, I filed
>>
>> https://bugs.openjdk.java.net/browse/JDK-8047769
>>
>> SecureRandom should be more frugal with file descriptors
>>
>> If I run this java program on Linux
>>
>> public class SecureRandoms {
>>      public static void main(String[] args) throws Throwable {
>>          new java.security.SecureRandom();
>>      }
>> }
>>
>> it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
>> by:
>>
>> strace -q -ff -e open java SecureRandoms |& grep /dev/
>> [pid 20769] open("/dev/random", O_RDONLY) = 5
>> [pid 20769] open("/dev/urandom", O_RDONLY) = 6
>> [pid 20769] open("/dev/random", O_RDONLY) = 7
>> [pid 20769] open("/dev/random", O_RDONLY) = 8
>> [pid 20769] open("/dev/urandom", O_RDONLY) = 9
>> [pid 20769] open("/dev/urandom", O_RDONLY) = 10
>>
>> Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
>> it looks like 2 file descriptors are created for every variant of
>> NativePRNG, whether or not they are ever used. Which is wasteful. In fact,
>> you only ever need at most two file descriptors, one for /dev/random and
>> one for /dev/urandom.
>>
>> Further, it would be nice if the file descriptors were closed when idle
>> and lazily re-created. Especially /dev/random should typically be used at
>> startup and never thereafter.
>>
>>
>> On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman 
>> wrote:
>>
>>> On 20/06/2014 15:02, Peter Levart wrote:
>>>
>>>> And, as Martin pointed out, it seems to be used for tests that exercise
>>>> particular responses from NameService API to test the behaviour of JDK
>>>> classes. It would be a shame for those tests to go away.
>>>>
>>> We've been talking about removing it for many years because it has been
>>> so troublesome. If we really need to having something for testing then I
>>> don't think it needs to be general purpose, we can get right of the lookup
>>> at least.
>>>
>>> -Alan.
>>>
>>



From coleen.phillimore at oracle.com  Tue Jun 24 15:03:29 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 11:03:29 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <2657473.M2SI7jRyYi@mgerdin03>
References: <539F1066.8080302@oracle.com> <53A9358B.90102@gmail.com>
	<53A97446.4020205@oracle.com> <2657473.M2SI7jRyYi@mgerdin03>
Message-ID: <53A99341.2000301@oracle.com>


Mikael,   see below.
On 6/24/14, 9:48 AM, Mikael Gerdin wrote:
> On Tuesday 24 June 2014 08.51.18 Coleen Phillimore wrote:
>> Hi Peter,
>>
>> On 6/24/14, 4:23 AM, Peter Levart wrote:
>>> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>>> Please review a change to the JDK code for adding classLoader field
>>>> to the instances of java/lang/Class.  This change restricts
>>>> reflection from changing access to the classLoader field.  In the
>>>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>>>> the accessibility of an object may not be changed:
>>>>
>>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObje
>>>> ct.html#setAccessible(boolean)
>>>>
>>>>
>>>> Only AccessibleObject.java has changes from the previous version of
>>>> this change.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>>
>>>> Thanks,
>>>> Coleen
>>> Hi Coleen,
>>>
>>> So hackers are prevented from hacking...
>>>
>>> Out of curiosity, what would happen if someone changed the classLoader
>>> field of some Class object? I guess VM still has it's own notion of
>>> the class' class loader, right? Only the code that directly uses the
>>> Class.getClassLoader() (and Unsafe.defineClass0) methods would be
>>> affected...
>> True, Class.getClassLoader() calls would be affected but we may use this
>> call for security checks.  I'm not really an expert on this, but we
>> thought it wouldn't be safe to allow user access to classLoader.
>>
>>> While we're at it, does this change in any way affect the GC logic?
>>> Will GC now navigate the classLoader field during marking but
>>> previously didn't ? Will this have any GC performance penalty ?
>> I actually ran this through our performance testing and got a good
>> improvement in one of the scimark benchmarks for no reason I could
>> explain (and lost the results), but none of the other tests were
>> affected.  GC would have to mark this new field for full collections but
>> not young collections because it's only set during initialization.   I
>> wouldn't expect this field to have any negative performance for GC.
> Peter has a good point actually. If the classLoader field is trustworthy we
> can get rid of some code in InstanceMirrorKlass::{oop_follow_contents,
> oop_oop_iterate} which currently picks up the class loader through the Klass*
> field injected into java/lang/Class. It would be a nice simplification if the
> ClassLoader objects were the only places where the GC would need to find the
> link to the ClassLoaderData metadata.
>
> But that won't work because anonymous (as in Unsafe.defineAnonymousClass)
> classes don't interact with class loaders in the same way and have their own
> ClassLoaderData objects.

Yes, one version of this patch removed class_loader_data from 
InstanceKlass so we'd be space-neutral but since there isn't a 1-1 
relationship to class_loader and ClassLoaderData for Unsafe anonymous 
classes, it doesn't work.  We might think of a way around this because 
we want to go in this direction.

Thanks,
Coleen
>
> /Mikael
>
>> Thanks,
>> Coleen
>>
>>> Regards, Peter
>>>
>>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>>> Hi Mandy,
>>>>>>
>>>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>>>
>>>>>>>>  wrote:
>>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>>>> should go away in 9 but ?).
>>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>>> loader.
>>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>>>> hides a field from being found using reflection. It might very
>>>>>>>> well be the case that private and final is enough, I haven?t
>>>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>>>> to give users access through the field instead of having to use
>>>>>>>> Class.getClassLoader()?
>>>>>>> There are many getter methods that returns a private final field.
>>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>>> permission although it's a different security check (vs
>>>>>>> "getClassLoader"
>>>>>>> permission).  Arguably before this new classLoader field, one could
>>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>>> loader.
>>>>>>>
>>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>>> is too coarse-grained?  I think the security team is looking into
>>>>>>> the improvement in that regards.
>>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>>>> since you could get the class loader through getClassLoader0() that
>>>>>> shouldn?t be a new issue.
>>>>>>
>>>>>> The second thing is that IIRC there are ways to set a final field
>>>>>> after initialization. I?m not sure we need to care about that
>>>>>> either if you need Unsafe to do it.
>>>>> Normal reflection can set a final field if you can successfully call
>>>>> setAccessible(true) on the Field object.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> cheers
>>>>>> /Joel



From coleen.phillimore at oracle.com  Tue Jun 24 15:11:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 11:11:49 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A939C4.2080703@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
Message-ID: <53A99535.4050809@oracle.com>


On 6/24/14, 4:41 AM, Frederic Parain wrote:
> Hi Coleen,
>
> It seems that there's still a reference to JVM_GetClassLoader
> in file jdk/src/share/native/common/check_code.c. The code looks
> like dead code, but it would be nice to clean it up.

I removed this code.  There are no other instances of the macro 
BROKEN_JAVAC.  I update the copyrights when I commit the changeset.

http://cr.openjdk.java.net/~coleenp/6642881_jdk_5/

Thanks!
Coleen
>
> Thanks,
>
> Fred
>
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field to
>> the instances of java/lang/Class.  This change restricts reflection from
>> changing access to the classLoader field.  In the spec,
>> AccessibleObject.setAccessible() may throw SecurityException if the
>> accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) 
>>
>>
>>
>> Only AccessibleObject.java has changes from the previous version of this
>> change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>  wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>> go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class 
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>> a field from being found using reflection. It might very well be
>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>> access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission).  Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained?  I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>> you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that either
>>>> if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>



From frederic.parain at oracle.com  Tue Jun 24 15:14:58 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 24 Jun 2014 17:14:58 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A99535.4050809@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>	<53A3301B.7070405@oracle.com>	<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>	<53A34949.6040607@oracle.com>	<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>	<53A3A402.2060501@oracle.com>
	<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
	<53A99535.4050809@oracle.com>
Message-ID: <53A995F2.9090502@oracle.com>

Looks good to me.

Thanks,

Fred

On 24/06/2014 17:11, Coleen Phillimore wrote:
>
> On 6/24/14, 4:41 AM, Frederic Parain wrote:
>> Hi Coleen,
>>
>> It seems that there's still a reference to JVM_GetClassLoader
>> in file jdk/src/share/native/common/check_code.c. The code looks
>> like dead code, but it would be nice to clean it up.
>
> I removed this code.  There are no other instances of the macro
> BROKEN_JAVAC.  I update the copyrights when I commit the changeset.
>
> http://cr.openjdk.java.net/~coleenp/6642881_jdk_5/
>
> Thanks!
> Coleen
>>
>> Thanks,
>>
>> Fred
>>
>> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>>
>>> Please review a change to the JDK code for adding classLoader field to
>>> the instances of java/lang/Class.  This change restricts reflection from
>>> changing access to the classLoader field.  In the spec,
>>> AccessibleObject.setAccessible() may throw SecurityException if the
>>> accessibility of an object may not be changed:
>>>
>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>>
>>>
>>>
>>> Only AccessibleObject.java has changes from the previous version of this
>>> change.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> On 19 jun 2014, at 22:34, Mandy Chung  wrote:
>>>>>
>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>>  wrote:
>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>>> go away in 9 but ?).
>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>> setAccessible.  If you mean injecting it on the JVM side, the
>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>> loader.
>>>>>>>>
>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>>> a field from being found using reflection. It might very well be
>>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>>> access through the field instead of having to use
>>>>>>> Class.getClassLoader()?
>>>>>>>
>>>>>> There are many getter methods that returns a private final field.
>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>> permission although it's a different security check (vs
>>>>>> "getClassLoader"
>>>>>> permission).  Arguably before this new classLoader field, one could
>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>> loader.
>>>>>>
>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>> is too coarse-grained?  I think the security team is looking into
>>>>>> the improvement in that regards.
>>>>>
>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>>> you could get the class loader through getClassLoader0() that
>>>>> shouldn?t be a new issue.
>>>>>
>>>>> The second thing is that IIRC there are ways to set a final field
>>>>> after initialization. I?m not sure we need to care about that either
>>>>> if you need Unsafe to do it.
>>>>
>>>> Normal reflection can set a final field if you can successfully call
>>>> setAccessible(true) on the Field object.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>
>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From martinrb at google.com  Tue Jun 24 15:40:18 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Jun 2014 08:40:18 -0700
Subject: [concurrency-interest] Deadlock
In-Reply-To: <53A9897A.7010803@gmail.com>
References: 
	<53A98733.4060401@gmail.com> <53A9897A.7010803@gmail.com>
Message-ID: 

[+openjdk mailing lists]


Yeah, I'm trying to excise all the networking code from TLR and
SplittableRandom.

There is also likely to be a missing wrapping in doPrivileged.


On Tue, Jun 24, 2014 at 7:21 AM, Peter Levart 
wrote:

> On 06/24/2014 04:12 PM, Peter Levart wrote:
>
>> On 06/24/2014 01:09 PM, David Holmes wrote:
>>
>>> Hi Peter,
>>>
>>> What a strange coincidence - the fact that the initialization of
>>> ThreadLocalRandom can lead to arbitrary code execution has just been a
>>> topic
>>> of discussion, and it looks like your deadlock is related to that.
>>>
>>
>> Uf, this time it's a combination of a custom SecurityManager being in
>> effect when NetworkInterface.getHardwareAddress() is called. It looks
>> like we should not use any networking code at all for TLR's initialization.
>>
>
> Or make NetworkInterface.getHardwareAddress() a @CallerSensitive method
> and avoid SecurityManager invocation when called from one of system
> classes. That's still an alternative.
>
> Peter
>
>
>
>> Regards, Peter
>>
>>
>>> David Holmes
>>>
>>>  -----Original Message-----
>>>> From: concurrency-interest-bounces at cs.oswego.edu
>>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
>>>> Firmstone
>>>> Sent: Tuesday, 24 June 2014 8:25 PM
>>>> To: concurrency-interest at cs.oswego.edu
>>>> Subject: [concurrency-interest] Deadlock
>>>>
>>>>
>>>> This appears to be a ClassLoader deadlock in Java 7.
>>>>
>>>> The stack trace from the main thread is missing.
>>>>
>>>> Any ideas?
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Attaching to process ID 7124, please wait...
>>>> Debugger attached successfully.
>>>> Client compiler detected.
>>>> JVM version is 25.0-b70
>>>> Deadlock Detection:
>>>>
>>>> Found one Java-level deadlock:
>>>> =============================
>>>>
>>>> "main":
>>>>     waiting to lock Monitor at 0x0094bb2c (Object at 0x03d73c38, a
>>>> java/lang/Object),
>>>>     which is held by "Thread-1"
>>>> "Thread-1":
>>>>     waiting to lock Monitor at 0x0094c99c (Object at 0x03f02e50, a [I),
>>>>     which is held by "main"
>>>>
>>>> Found a total of 1 deadlock.
>>>>
>>>> Thread 8: (state = BLOCKED)
>>>>    - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object,
>>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229,
>>>> line=60 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=37, line=128 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=4, line=44 (Interpreted frame)
>>>>    - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object,
>>>> boolean, boolean) @bci=7, line=248 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan
>>>> g.Object,
>>>> java.lang.Object) @bci=8, line=67 (Interpreted frame)
>>>>    -
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission,
>>>> java.lang.Object) @bci=161, line=260 (Interpreted frame)
>>>>    -
>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr
>>>> ustPermission(java.lang.Class)
>>>> @bci=59, line=1848 (Interpreted frame)
>>>>    -
>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea
>>>> n(java.lang.Object,
>>>> javax.management.ObjectName) @bci=25, line=322 (Interpreted frame)
>>>>    - com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() @bci=17, line=1225
>>>> (Interpreted frame)
>>>>    -
>>>> java.security.AccessController.doPrivileged(java.security.Privileg
>>>> edExceptionAction)
>>>> @bci=0 (Interpreted frame)
>>>>    - com.sun.jmx.mbeanserver.JmxMBeanServer.initialize() @bci=25,
>>>> line=1223 (Interpreted frame)
>>>>    - com.sun.jmx.mbeanserver.JmxMBeanServer.(java.lang.String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate,
>>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) @bci=133,
>>>> line=255 (Interpreted frame)
>>>>    -
>>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate,
>>>> boolean) @bci=13, line=1437 (Interpreted frame)
>>>>    - javax.management.MBeanServerBuilder.newMBeanServer(java.lang.
>>>> String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate)
>>>> @bci=4, line=110 (Interpreted frame)
>>>>    - javax.management.MBeanServerFactory.newMBeanServer(java.lang.
>>>> String)
>>>> @bci=36, line=329 (Interpreted frame)
>>>>    -
>>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String)
>>>> @bci=6, line=231 (Interpreted frame)
>>>>    - javax.management.MBeanServerFactory.createMBeanServer() @bci=1,
>>>> line=192 (Interpreted frame)
>>>>    - java.lang.management.ManagementFactory.getPlatformMBeanServer()
>>>> @bci=29, line=468 (Interpreted frame)
>>>>    -
>>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer()
>>>> @bci=66, line=518 (Interpreted frame)
>>>>    - sun.management.Agent.startLocalManagementAgent() @bci=13, line=138
>>>> (Interpreted frame)
>>>>    - sun.management.Agent.startAgent(java.util.Properties) @bci=76,
>>>> line=260 (Interpreted frame)
>>>>    - sun.management.Agent.agentmain(java.lang.String) @bci=45, line=128
>>>> (Interpreted frame)
>>>>    -
>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method,
>>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame)
>>>>    - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object,
>>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame)
>>>>    - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object,
>>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame)
>>>>    - java.lang.reflect.Method.invoke(java.lang.Object,
>>>> java.lang.Object[]) @bci=56, line=483 (Interpreted frame)
>>>>    -
>>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan
>>>> g.String,
>>>> java.lang.String, java.lang.String) @bci=192, line=388 (Interpreted
>>>> frame)
>>>>    -
>>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java.
>>>> lang.String,
>>>> java.lang.String) @bci=5, line=411 (Interpreted frame)
>>>>
>>>>
>>>> Thread 7: (state = BLOCKED)
>>>>
>>>>
>>>> Thread 5: (state = BLOCKED)
>>>>    - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object,
>>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229,
>>>> line=60 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=37, line=128 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=4, line=44 (Interpreted frame)
>>>>    - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object,
>>>> boolean, boolean) @bci=7, line=248 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan
>>>> g.Object,
>>>> java.lang.Object) @bci=8, line=67 (Interpreted frame)
>>>>    -
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission,
>>>> java.lang.Object) @bci=161, line=260 (Interpreted frame)
>>>>    -
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission)
>>>> @bci=27, line=202 (Interpreted frame)
>>>>    - java.net.NetworkInterface.getHardwareAddress() @bci=18, line=447
>>>> (Interpreted frame)
>>>>    - java.util.concurrent.ThreadLocalRandom.initialSeed() @bci=116,
>>>> line=158 (Interpreted frame)
>>>>    - java.util.concurrent.ThreadLocalRandom.() @bci=14,
>>>> line=137
>>>> (Interpreted frame)
>>>>    - java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean)
>>>> @bci=0, line=2526 (Interpreted frame)
>>>>    - java.util.concurrent.ConcurrentHashMap.addCount(long, int)
>>>> @bci=104,
>>>> line=2266 (Interpreted frame)
>>>>    - java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object,
>>>> java.lang.Object, boolean) @bci=357, line=1070 (Interpreted frame)
>>>>    - java.util.concurrent.ConcurrentHashMap.putIfAbsent(
>>>> java.lang.Object,
>>>> java.lang.Object) @bci=4, line=1535 (Interpreted frame)
>>>>    - java.lang.ClassLoader.getClassLoadingLock(java.lang.String)
>>>> @bci=23,
>>>> line=463 (Interpreted frame)
>>>>    - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=2,
>>>> line=404 (Interpreted frame)
>>>>    - java.lang.ClassLoader.loadClass(java.lang.String, boolean)
>>>> @bci=38,
>>>> line=411 (Interpreted frame)
>>>>    - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String,
>>>> boolean) @bci=36, line=308 (Interpreted frame)
>>>>    - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357
>>>> (Interpreted frame)
>>>>    -
>>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.(org.
>>>>
>>> cliffc.high_scale_lib.NonBlockingHashMap)
>>>
>>>> @bci=10, line=1167 (Interpreted frame)
>>>>    - org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() @bci=8,
>>>> line=1200 (Interpreted frame)
>>>>    - au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run()
>>>> @bci=15, line=166 (Interpreted frame)
>>>>    - java.util.concurrent.Executors$RunnableAdapter.call() @bci=4,
>>>> line=511 (Interpreted frame)
>>>>    - java.util.concurrent.FutureTask.runAndReset() @bci=47, line=308
>>>> (Interpreted frame)
>>>>    -
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa
>>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch
>>>> eduledFutureTask)
>>>> @bci=1, line=180 (Interpreted frame)
>>>>    -
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa
>>>> sk.run()
>>>> @bci=37, line=294 (Interpreted frame)
>>>>    -
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur
>>>> rent.ThreadPoolExecutor$Worker)
>>>> @bci=95, line=1142 (Interpreted frame)
>>>>    - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5,
>>>> line=617 (Interpreted frame)
>>>>    - java.lang.Thread.run() @bci=11, line=744 (Interpreted frame)
>>>>
>>>>
>>>> Thread 4: (state = BLOCKED)
>>>>    - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
>>>>    - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=142
>>>> (Interpreted frame)
>>>>    - java.lang.ref.ReferenceQueue.remove() @bci=2, line=158
>>>> (Interpreted
>>>> frame)
>>>>    - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209
>>>> (Interpreted frame)
>>>>
>>>>
>>>> Thread 3: (state = BLOCKED)
>>>>    - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
>>>>    - java.lang.Object.wait() @bci=2, line=502 (Interpreted frame)
>>>>    - java.lang.ref.Reference$ReferenceHandler.run() @bci=36, line=157
>>>> (Interpreted frame)
>>>>
>>>>
>>>> Thread 1: (state = BLOCKED)
>>>>    - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=8,
>>>> line=406 (Interpreted frame)
>>>>    - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String,
>>>> boolean) @bci=36, line=308 (Interpreted frame)
>>>>    - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357
>>>> (Interpreted frame)
>>>>    - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object,
>>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229,
>>>> line=60 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=37, line=128 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) @bci=4, line=44 (Interpreted frame)
>>>>    - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object,
>>>> boolean, boolean) @bci=7, line=248 (Interpreted frame)
>>>>    -
>>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan
>>>> g.Object,
>>>> java.lang.Object) @bci=8, line=67 (Interpreted frame)
>>>>    -
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission,
>>>> java.lang.Object) @bci=161, line=260 (Interpreted frame)
>>>>    -
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission)
>>>> @bci=27, line=202 (Interpreted frame)
>>>>    - java.lang.System.checkIO() @bci=18, line=253 (Interpreted frame)
>>>>    - java.lang.System.setErr(java.io.PrintStream) @bci=0, line=199
>>>> (Interpreted frame)
>>>>    - com.sun.jini.qa.harness.MasterTest.main(java.lang.String[])
>>>> @bci=9,
>>>> line=84 (Interpreted frame)
>>>>
>>>> The long version:
>>>>
>>>> Attaching to process ID 7124, please wait...
>>>> Debugger attached successfully.
>>>> Client compiler detected.
>>>> JVM version is 25.0-b70
>>>> Deadlock Detection:
>>>>
>>>> Found one Java-level deadlock:
>>>> =============================
>>>>
>>>> "main":
>>>>     waiting to lock Monitor at 0x0094bb2c (Object at 0x03d73c38, a
>>>> java/lang/Object),
>>>>     which is held by "Thread-1"
>>>> "Thread-1":
>>>>     waiting to lock Monitor at 0x0094c99c (Object at 0x03f02e50, a [I),
>>>>     which is held by "main"
>>>>
>>>> Found a total of 1 deadlock.
>>>>
>>>> ----------------- 0 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x00e64d7b    java + 0x4d7b
>>>> 0x00e631ca    java + 0x31ca
>>>> 0x00e642ab    java + 0x42ab
>>>> 0x00e63440    java + 0x3440
>>>> 0x00130138        ????????
>>>> ----------------- 1 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6b3d    jvm!_JVM_FindSignal at 4 + 0x286d
>>>> 0x5bf7857e    jvm!JVM_GetThreadStateNames + 0x4c12e
>>>> 0x5bf78b23    jvm!JVM_GetThreadStateNames + 0x4c6d3
>>>> 0x5bf8e107    jvm!JVM_GetThreadStateNames + 0x61cb7
>>>> 0x5bf8e6be    jvm!JVM_GetThreadStateNames + 0x6226e
>>>> 0x5bea1b28    jvm + 0x71b28
>>>> 0x01aa1cef    * java.lang.ClassLoader.loadClass(java.lang.String,
>>>> boolean) bci:8 line:406 (Interpreted frame)
>>>> 0x01a94054    *
>>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean)
>>>> bci:36 line:308 (Interpreted frame)
>>>> 0x01a94054    * java.lang.ClassLoader.loadClass(java.lang.String) bci:3
>>>> line:357 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf724a6    jvm!JVM_GetThreadStateNames + 0x46056
>>>> 0x5bf7258f    jvm!JVM_GetThreadStateNames + 0x4613f
>>>> 0x5be77d6f    jvm + 0x47d6f
>>>> 0x5be7822a    jvm + 0x4822a
>>>> 0x5be794c0    jvm + 0x494c0
>>>> 0x5be7950a    jvm + 0x4950a
>>>> 0x5bf20de5    jvm!_JVM_FindClassFromClass at 16 + 0x135
>>>> 0x73b515cd    verify + 0x15cd
>>>> 0x73b51d53    verify + 0x1d53
>>>> 0x73b52c67    verify + 0x2c67
>>>> 0x14d6f5e8        ????????
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 2 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6b3d    jvm!_JVM_FindSignal at 4 + 0x286d
>>>> 0x5bf73ecc    jvm!JVM_GetThreadStateNames + 0x47a7c
>>>> 0x5bf741fc    jvm!JVM_GetThreadStateNames + 0x47dac
>>>> 0x5bf99671    jvm!JVM_GetThreadStateNames + 0x6d221
>>>> 0x5bf99a32    jvm!JVM_GetThreadStateNames + 0x6d5e2
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> ----------------- 3 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6c49    jvm!_JVM_FindSignal at 4 + 0x2979
>>>> 0x5bf78f56    jvm!JVM_GetThreadStateNames + 0x4cb06
>>>> 0x5bf8e334    jvm!JVM_GetThreadStateNames + 0x61ee4
>>>> 0x5bf20c15    jvm!_JVM_MonitorWait at 16 + 0x95
>>>> 0x01a9ac63    * java.lang.Object.wait(long) bci:0 (Interpreted frame)
>>>> 0x01a940f4    * java.lang.Object.wait() bci:2 line:502 (Interpreted
>>>> frame)
>>>> 0x01a940f4    * java.lang.ref.Reference$ReferenceHandler.run() bci:36
>>>> line:157 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf724a6    jvm!JVM_GetThreadStateNames + 0x46056
>>>> 0x5bf72517    jvm!JVM_GetThreadStateNames + 0x460c7
>>>> 0x5bf1de0f    jvm!jio_printf + 0x9f
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 4 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6c49    jvm!_JVM_FindSignal at 4 + 0x2979
>>>> 0x5bf78f56    jvm!JVM_GetThreadStateNames + 0x4cb06
>>>> 0x5bf8e334    jvm!JVM_GetThreadStateNames + 0x61ee4
>>>> 0x5bf20c15    jvm!_JVM_MonitorWait at 16 + 0x95
>>>> 0x01a9ac63    * java.lang.Object.wait(long) bci:0 (Interpreted frame)
>>>> 0x01a940f4    * java.lang.ref.ReferenceQueue.remove(long) bci:44
>>>> line:142 (Interpreted frame)
>>>> 0x01a94054    * java.lang.ref.ReferenceQueue.remove() bci:2 line:158
>>>> (Interpreted frame)
>>>> 0x01a94054    * java.lang.ref.Finalizer$FinalizerThread.run() bci:36
>>>> line:209 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf724a6    jvm!JVM_GetThreadStateNames + 0x46056
>>>> 0x5bf72517    jvm!JVM_GetThreadStateNames + 0x460c7
>>>> 0x5bf1de0f    jvm!jio_printf + 0x9f
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 5 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6b3d    jvm!_JVM_FindSignal at 4 + 0x286d
>>>> 0x5bf7857e    jvm!JVM_GetThreadStateNames + 0x4c12e
>>>> 0x5bf78b23    jvm!JVM_GetThreadStateNames + 0x4c6d3
>>>> 0x5bf8e107    jvm!JVM_GetThreadStateNames + 0x61cb7
>>>> 0x5bf8e6be    jvm!JVM_GetThreadStateNames + 0x6226e
>>>> 0x5bf8e78f    jvm!JVM_GetThreadStateNames + 0x6233f
>>>> 0x5bee0d10    jvm + 0xb0d10
>>>> 0x5bee2854    jvm + 0xb2854
>>>> 0x5bee3548    jvm + 0xb3548
>>>> 0x5bea5641    jvm + 0x75641
>>>> 0x01aa17be    *
>>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object,
>>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229
>>>> line:60 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) bci:37 line:128 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) bci:4 line:44 (Interpreted frame)
>>>> 0x01a94089    *
>>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean,
>>>> boolean) bci:7 line:248 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan
>>>> g.Object,
>>>> java.lang.Object) bci:8 line:67 (Interpreted frame)
>>>> 0x01a94089    *
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission,
>>>> java.lang.Object) bci:161 line:260 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission)
>>>> bci:27 line:202 (Interpreted frame)
>>>> 0x01a940f4    * java.net.NetworkInterface.getHardwareAddress() bci:18
>>>> line:447 (Interpreted frame)
>>>> 0x01a94054    * java.util.concurrent.ThreadLocalRandom.initialSeed()
>>>> bci:116 line:158 (Interpreted frame)
>>>> 0x01a93e20    * java.util.concurrent.ThreadLocalRandom.()
>>>> bci:14
>>>> line:137 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bee0f44    jvm + 0xb0f44
>>>> 0x5bee2b21    jvm + 0xb2b21
>>>> 0x5bee3548    jvm + 0xb3548
>>>> 0x5bea9796    jvm + 0x79796
>>>> 0x5beaa7b2    jvm + 0x7a7b2
>>>> 0x5bea5dc7    jvm + 0x75dc7
>>>> 0x01aa12ae    *
>>>> java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean)
>>>> bci:0
>>>> line:2526 (Interpreted frame)
>>>> 0x01a940f4    * java.util.concurrent.ConcurrentHashMap.addCount(long,
>>>> int) bci:104 line:2266 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object,
>>>> java.lang.Object, boolean) bci:357 line:1070 (Interpreted frame)
>>>> 0x01a94054    *
>>>> java.util.concurrent.ConcurrentHashMap.putIfAbsent(java.lang.Object,
>>>> java.lang.Object) bci:4 line:1535 (Interpreted frame)
>>>> 0x01a94054    *
>>>> java.lang.ClassLoader.getClassLoadingLock(java.lang.String) bci:23
>>>> line:463 (Interpreted frame)
>>>> 0x01a94054    * java.lang.ClassLoader.loadClass(java.lang.String,
>>>> boolean) bci:2 line:404 (Interpreted frame)
>>>> 0x01a94054    * java.lang.ClassLoader.loadClass(java.lang.String,
>>>> boolean) bci:38 line:411 (Interpreted frame)
>>>> 0x01a94054    *
>>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean)
>>>> bci:36 line:308 (Interpreted frame)
>>>> 0x01a94054    * java.lang.ClassLoader.loadClass(java.lang.String) bci:3
>>>> line:357 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf724a6    jvm!JVM_GetThreadStateNames + 0x46056
>>>> 0x5bf7258f    jvm!JVM_GetThreadStateNames + 0x4613f
>>>> 0x5be77d6f    jvm + 0x47d6f
>>>> 0x5be7822a    jvm + 0x4822a
>>>> 0x5be794c0    jvm + 0x494c0
>>>> 0x5be7950a    jvm + 0x4950a
>>>> 0x5be79f66    jvm + 0x49f66
>>>> 0x5be715c7    jvm + 0x415c7
>>>> 0x5be7a53c    jvm + 0x4a53c
>>>> 0x5be817e2    jvm + 0x517e2
>>>> 0x5be822d9    jvm + 0x522d9
>>>> 0x5be82414    jvm + 0x52414
>>>> 0x5bed85dd    jvm + 0xa85dd
>>>> 0x5bee0d80    jvm + 0xb0d80
>>>> 0x5bee2854    jvm + 0xb2854
>>>> 0x5bee3548    jvm + 0xb3548
>>>> 0x5bea5641    jvm + 0x75641
>>>> 0x01aa17be    *
>>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.(org.
>>>>
>>> cliffc.high_scale_lib.NonBlockingHashMap)
>>>
>>>> bci:10 line:1167 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() bci:8
>>>> line:1200 (Interpreted frame)
>>>> 0x01a94089    *
>>>> au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run() bci:15
>>>> line:166 (Interpreted frame)
>>>> 0x01a94129    * java.util.concurrent.Executors$RunnableAdapter.call()
>>>> bci:4 line:511 (Interpreted frame)
>>>> 0x01a94089    * java.util.concurrent.FutureTask.runAndReset() bci:47
>>>> line:308 (Interpreted frame)
>>>> 0x01a93ba0    *
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa
>>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch
>>>> eduledFutureTask)
>>>> bci:1 line:180 (Interpreted frame)
>>>> 0x01a93ba0    *
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa
>>>> sk.run()
>>>> bci:37 line:294 (Interpreted frame)
>>>> 0x01a94129    *
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur
>>>> rent.ThreadPoolExecutor$Worker)
>>>> bci:95 line:1142 (Interpreted frame)
>>>> 0x01a940f4    * java.util.concurrent.ThreadPoolExecutor$Worker.run()
>>>> bci:5 line:617 (Interpreted frame)
>>>> 0x01a94129    * java.lang.Thread.run() bci:11 line:744 (Interpreted
>>>> frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf724a6    jvm!JVM_GetThreadStateNames + 0x46056
>>>> 0x5bf72517    jvm!JVM_GetThreadStateNames + 0x460c7
>>>> 0x5bf1de0f    jvm!jio_printf + 0x9f
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - <0x03d58650>, (a java/util/concurrent/
>>>> ThreadPoolExecutor$Worker)
>>>> ----------------- 6 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> ----------------- 7 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd9539    jvm!_JVM_FindSignal at 4 + 0x5269
>>>> 0x5bfd9607    jvm!_JVM_FindSignal at 4 + 0x5337
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 8 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6c49    jvm!_JVM_FindSignal at 4 + 0x2979
>>>> 0x5bf7856b    jvm!JVM_GetThreadStateNames + 0x4c11b
>>>> 0x5bf78b23    jvm!JVM_GetThreadStateNames + 0x4c6d3
>>>> 0x5bf8e107    jvm!JVM_GetThreadStateNames + 0x61cb7
>>>> 0x5bf8e6be    jvm!JVM_GetThreadStateNames + 0x6226e
>>>> 0x5bf8e78f    jvm!JVM_GetThreadStateNames + 0x6233f
>>>> 0x5bee0d10    jvm + 0xb0d10
>>>> 0x5bee2854    jvm + 0xb2854
>>>> 0x5bee3548    jvm + 0xb3548
>>>> 0x5bea5641    jvm + 0x75641
>>>> 0x01aa17be    *
>>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object,
>>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229
>>>> line:60 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) bci:37 line:128 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object,
>>>> boolean, boolean) bci:4 line:44 (Interpreted frame)
>>>> 0x01a94089    *
>>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean,
>>>> boolean) bci:7 line:248 (Interpreted frame)
>>>> 0x01a94054    *
>>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan
>>>> g.Object,
>>>> java.lang.Object) bci:8 line:67 (Interpreted frame)
>>>> 0x01a94089    *
>>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss
>>>> ion(java.security.Permission,
>>>> java.lang.Object) bci:161 line:260 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr
>>>> ustPermission(java.lang.Class)
>>>> bci:59 line:1848 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea
>>>> n(java.lang.Object,
>>>> javax.management.ObjectName) bci:25 line:322 (Interpreted frame)
>>>> 0x01a94089    * com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() bci:17
>>>> line:1225 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf299ed    jvm!_JVM_DoPrivileged at 20 + 0x2bd
>>>> 0x73b21047
>>>> java_73b20000!_Java_java_security_AccessController_doPrivileged__L
>>>> java_security_PrivilegedExceptionAction_2 at 12
>>>> + 0x15
>>>> 0x01a94054    * com.sun.jmx.mbeanserver.JmxMBeanServer.initialize()
>>>> bci:25 line:1223 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> com.sun.jmx.mbeanserver.JmxMBeanServer.(java.lang.String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate,
>>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) bci:133
>>>> line:255 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate,
>>>> boolean) bci:13 line:1437 (Interpreted frame)
>>>> 0x01a94054    *
>>>> javax.management.MBeanServerBuilder.newMBeanServer(java.lang.String,
>>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate)
>>>> bci:4 line:110 (Interpreted frame)
>>>> 0x01a94054    *
>>>> javax.management.MBeanServerFactory.newMBeanServer(java.lang.String)
>>>> bci:36 line:329 (Interpreted frame)
>>>> 0x01a94054    *
>>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String)
>>>> bci:6 line:231 (Interpreted frame)
>>>> 0x01a94054    * javax.management.MBeanServerFactory.createMBeanServer()
>>>> bci:1 line:192 (Interpreted frame)
>>>> 0x01a94054    *
>>>> java.lang.management.ManagementFactory.getPlatformMBeanServer() bci:29
>>>> line:468 (Interpreted frame)
>>>> 0x01a94054    *
>>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer()
>>>> bci:66 line:518 (Interpreted frame)
>>>> 0x01a94054    * sun.management.Agent.startLocalManagementAgent() bci:13
>>>> line:138 (Interpreted frame)
>>>> 0x01a940f4    * sun.management.Agent.startAgent(java.util.Properties)
>>>> bci:76 line:260 (Interpreted frame)
>>>> 0x01a940f4    * sun.management.Agent.agentmain(java.lang.String) bci:45
>>>> line:128 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5bf7e73a    jvm!JVM_GetThreadStateNames + 0x522ea
>>>> 0x5bf7e993    jvm!JVM_GetThreadStateNames + 0x52543
>>>> 0x5bf22b03    jvm!_JVM_InvokeMethod at 16 + 0xb3
>>>> 0x73b23a6e
>>>> java_73b20000!_Java_sun_reflect_NativeMethodAccessorImpl_invoke0 at 20 +
>>>> 0x15
>>>> 0x01a94054    *
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object,
>>>> java.lang.Object[]) bci:100 line:62 (Interpreted frame)
>>>> 0x01a94054    *
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object,
>>>> java.lang.Object[]) bci:6 line:43 (Interpreted frame)
>>>> 0x01a94089    * java.lang.reflect.Method.invoke(java.lang.Object,
>>>> java.lang.Object[]) bci:56 line:483 (Interpreted frame)
>>>> 0x01a94054    *
>>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan
>>>> g.String,
>>>> java.lang.String, java.lang.String) bci:192 line:388 (Interpreted frame)
>>>> 0x01a940f4    *
>>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java.
>>>> lang.String,
>>>> java.lang.String) bci:5 line:411 (Interpreted frame)
>>>> 0x01a903d7 
>>>> 0x5bf72285    jvm!JVM_GetThreadStateNames + 0x45e35
>>>> 0x5c0370be    jvm!_JVM_FindSignal at 4 + 0x62dee
>>>> 0x5bf7231e    jvm!JVM_GetThreadStateNames + 0x45ece
>>>> 0x5befe951    jvm!JNI_GetCreatedJavaVMs + 0x71a1
>>>> 0x5bf01788    jvm!JNI_GetCreatedJavaVMs + 0x9fd8
>>>> 0x6db62878    instrument!Agent_OnAttach + 0x76b
>>>> 0x6db63eea    instrument!Agent_OnAttach + 0x1ddd
>>>> 0x6db6234a    instrument!Agent_OnAttach + 0x23d
>>>> 0x5bf3c50c    jvm!JVM_GetThreadStateNames + 0x100bc
>>>> 0x5bf9b05e    jvm!JVM_GetThreadStateNames + 0x6ec0e
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 9 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6b3d    jvm!_JVM_FindSignal at 4 + 0x286d
>>>> 0x5bf73ecc    jvm!JVM_GetThreadStateNames + 0x47a7c
>>>> 0x5bf7424a    jvm!JVM_GetThreadStateNames + 0x47dfa
>>>> 0x5be9253b    jvm + 0x6253b
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 10 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6c49    jvm!_JVM_FindSignal at 4 + 0x2979
>>>> 0x5bf73ec1    jvm!JVM_GetThreadStateNames + 0x47a71
>>>> 0x5bf741fc    jvm!JVM_GetThreadStateNames + 0x47dac
>>>> 0x5bf829a5    jvm!JVM_GetThreadStateNames + 0x56555
>>>> 0x5bf945fc    jvm!JVM_GetThreadStateNames + 0x681ac
>>>> 0x5bf94e8a    jvm!JVM_GetThreadStateNames + 0x68a3a
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>> Locked ownable synchronizers:
>>>>       - None
>>>> ----------------- 11 -----------------
>>>> 0x77c870f4    ntdll!KiFastSystemCallRet
>>>> 0x76a9c3d3    kernel32!WaitForSingleObjectEx + 0x43
>>>> 0x76a9c382    kernel32!WaitForSingleObject + 0x12
>>>> 0x5bfd6b3d    jvm!_JVM_FindSignal at 4 + 0x286d
>>>> 0x5bf73ecc    jvm!JVM_GetThreadStateNames + 0x47a7c
>>>> 0x5bf741fc    jvm!JVM_GetThreadStateNames + 0x47dac
>>>> 0x5bf8f904    jvm!JVM_GetThreadStateNames + 0x634b4
>>>> 0x5bf8f9a7    jvm!JVM_GetThreadStateNames + 0x63557
>>>> 0x5bfd9186    jvm!_JVM_FindSignal at 4 + 0x4eb6
>>>> 0x614dc556    msvcr100!_endthreadex + 0x3a
>>>> 0x614dc600    msvcr100!_endthreadex + 0xe4
>>>> 0x76a9ee1c    kernel32!BaseThreadInitThunk + 0x12
>>>> 0x77ca37eb    ntdll!RtlInitializeExceptionChain + 0xef
>>>> 0x77ca37be    ntdll!RtlInitializeExceptionChain + 0xc2
>>>>
>>>>
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


From martinrb at google.com  Tue Jun 24 16:01:53 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Jun 2014 09:01:53 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A98525.9080908@gmail.com>
References: 
	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
	<53A43055.5070803@oracle.com> <53A43EF3.8000206@gmail.com>
	<53A44C3A.6000607@oracle.com>
	
	
	<53A98525.9080908@gmail.com>
Message-ID: 

On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart 
wrote:

>
> I would rather use SecureRandom.generateSeed() instance method instead of
> SecureRandom.nextBytes(). Why? Because every SecureRandom instance has to
> initialize it's seed 1st before getBytes() can provide the next random
> bytes from the PRNG. Since we only need the 1st 8 bytes from the
> SecureRandom instance to initialize TLR's seeder, we might as well directly
> call the SecureRandom.generateSeed() method.
>

If I strace this program on Linux using strace -ff -q java SecureRandoms:

public class SecureRandoms {
    public static void main(String[] args) throws Throwable {
        byte[] bytes = new byte[8];
        new java.security.SecureRandom().nextBytes(bytes);
    }
}

I see a read from /dev/urandom, but not from /dev/random, so I conclude
your intuitive understanding of how the seeding works must be wrong.  It
makes sense that NativePRNG doesn't need to do any special seeding of its
own, since it reuses the operating system's.


From paul.sandoz at oracle.com  Tue Jun 24 16:04:03 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Jun 2014 18:04:03 +0200
Subject: Review request for 8047904: Runtime.loadLibrary throws
	SecurityException when security manager is installed
In-Reply-To: <53A88CC4.2040605@oracle.com>
References: <53A88CC4.2040605@oracle.com>
Message-ID: 


On Jun 23, 2014, at 10:23 PM, Mandy Chung  wrote:

> The loadLibrary implementation is missing to wrap the call
> to File.getCanonicalPath  method with doPrivileged block.
> 
> Webrev:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
> 

Looks ok to me.

Paul.


From Alan.Bateman at oracle.com  Tue Jun 24 16:10:51 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jun 2014 17:10:51 +0100
Subject: Review request for 8047904: Runtime.loadLibrary throws
	SecurityException when security manager is installed
In-Reply-To: <53A88CC4.2040605@oracle.com>
References: <53A88CC4.2040605@oracle.com>
Message-ID: <53A9A30B.60108@oracle.com>

On 23/06/2014 21:23, Mandy Chung wrote:
> The loadLibrary implementation is missing to wrap the call
> to File.getCanonicalPath  method with doPrivileged block.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
I think this is okay too, one shouldn't require anymore than the runtime 
permission "loadLibrary."+lib.

-Alan


From huizhe.wang at oracle.com  Tue Jun 24 17:01:04 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 24 Jun 2014 10:01:04 -0700
Subject: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo
In-Reply-To: <53A92688.50502@oracle.com>
References: <539F1066.8080302@oracle.com>	<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
	<53A3301B.7070405@oracle.com> <53A3F40B.1040108@oracle.com>
	<53A3FE3D.7050008@oracle.com> <53A8C2DC.2090500@oracle.com>
	<53A92688.50502@oracle.com>
Message-ID: <53A9AED0.6010204@oracle.com>


On 6/24/2014 12:19 AM, Alan Bateman wrote:
> On 24/06/2014 01:14, huizhe wang wrote:
>> :
>>
>>>
>>> One thing that concerns me a bit is that none of the .java files 
>>> that I looked at have any comments to say what the test does. Is 
>>> there anything that could be brought over from the original issue in 
>>> JIRA to explain what each of these tests is about?
>>
>> It would have been nice if they had comments. But adding comments 
>> would be too much work, unnecessary I would think. These tests serve 
>> their purpose, that is, preventing regressions. In case any fails, 
>> its bugid would allow us to easily find out what it was testing.
> If there is a test failure then whoever runs into it will need to 
> decypher what the test is about. I would think that it would at least 
> be helpful to have a short summary at the top to give some indication 
> as to what it is doing. Are we even sure that all the issues are 
> accessible to all in JIRA?

If there is a test failure, we can narrow it down to the cause pretty 
quickly since we have a context, that is, the current patch. Rather than 
some comments, we generally rely on the test code itself to identify the 
culprit or browse the original bug report to understand the whole story 
(when change happened, the whole history and etc.).

Furthermore, they don't really fail often, in fact, some of the tests 
have never failed because of the nature of related fixes. For someone 
like Patrick who doesn't have knowledge of the original fixes or bug 
reports to go into them and try to figure out a proper write-up, it may 
not be an easy task. There are hundreds of tests, plus the function 
tests that did not have comments either. I'm just not sure it's worth it 
to spend all that time (and then, not used in most of the cases :-) ).

-Joe

>
> -Alan



From jason_mehrens at hotmail.com  Tue Jun 24 17:08:41 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Jun 2014 12:08:41 -0500
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A84400.6090509@oracle.com>
References: ,
	<53A7F7E2.2030006@oracle.com>, <53A83F87.5060505@oracle.com>,
	<53A84400.6090509@oracle.com>
Message-ID: 

Daniel,


With regard to JDK-4420020, in the original webrev Jim was incorrectly using java.io.File.canWrite() but that webrev was replaced by the current version. The NIO.2 code performs the effective access checks correctly.


With regard to JDK-6244047 my concern was that checking the permissions and preconditions up front is a small 'TOCTOU' race and redundant because the next step after that is to open the FileChannel. I would assume both CREATE or CREATE_NEW plus WRITE would perform the effective access checks on open.

The use of delete on exit is a deal breaker because you can't undo a registration on close of the FileHandler which can trigger an OOME. See https://bugs.openjdk.java.net/browse/JDK-4872014. I've used custom proxy handlers that generate a file name based off of the LogRecord which results in generating lots of file names and opening and close the FileHandler on demand.


If the behavior is reverted to use CREATE instead of CREATE_NEW then we have to deal with JDK-8031438 because any user code can lock a file ahead of opening the FileHandler.

Jason



----------------------------------------
> Date: Mon, 23 Jun 2014 17:13:04 +0200
> From: daniel.fuchs at oracle.com
> To: Alan.Bateman at oracle.com; jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>
> On 6/23/14 4:53 PM, Alan Bateman wrote:
>> On 23/06/2014 10:48, Daniel Fuchs wrote:
>>> :
>>>
>>> All in all - I feel our best options would be to revert to using
>>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>>> and live with the issue.
>>> Hopefully some nio experts will chime in ;-)
>>>
>> The logging use of FileLock is a bit unusual but looking at it now then
>> I don't see the reason why it needs to use CREATE_NEW.
>
> OK - thanks - in the discussion that ended up in the patch where
> CREATE_NEW was introduced Jason (I think it was Jason) pointed at
> https://bugs.openjdk.java.net/browse/JDK-4420020
>
> I'm guessing here that maybe it would be wrong to use an already
> existing lock file if you don't have the rights to write to
> its directory - and that using CREATE_NEW ensures that you have
> all necessary access rights all along the path.
>
>> I don't think
>> DELETE_ON_CLOSE is suitable here as that work is for transient work
>> files which isn't the case here. Instead it could use deleteOnExit to
>> have some chance of removing it on a graceful exit.
>
> Right - I suggested a patch in another mail where I just use that.
>
>>
>> BTW: Do you know why locks is Map? Would a Set do?
>
> It certainly looks as if we could use a simple HashSet here.
>
> Thanks Alan!
>
> -- daniel
>
>>
>> -Alan.
>>
> 		 	   		  

From joe.darcy at oracle.com  Tue Jun 24 17:13:03 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 Jun 2014 10:13:03 -0700
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private
	methods
Message-ID: <53A9B19F.6090300@oracle.com>

Hello,

Please review the libraries update portion of allowing @SafeVarargs on 
private instance methods:

     JDK-8048014: Update java.lang.SafeVararags for private methods

The patch is

diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
--- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23 
12:12:30 2014 -0700
+++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24 
10:03:21 2014 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2010, 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 @@
   * 
  •   the declaration is a fixed arity method or constructor
   *
   * 
  •  the declaration is a variable arity method that is neither
- * {@code static} nor {@code final}.
+ * {@code static} nor {@code final} nor {@code private}.
   *
   * 
   *

The bulk of the change to allow @SafeVarargs on private methods, 
including the tests, are over in the langtools repo with javac updates. 
The javac changes have been reviewed and approved on compiler-dev:

http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html

Thanks,

-Joe


From Lance.Andersen at oracle.com  Tue Jun 24 17:27:01 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Tue, 24 Jun 2014 13:27:01 -0400
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for
	private methods
In-Reply-To: <53A9B19F.6090300@oracle.com>
References: <53A9B19F.6090300@oracle.com>
Message-ID: 

+1
On Jun 24, 2014, at 1:13 PM, Joe Darcy  wrote:

> Hello,
> 
> Please review the libraries update portion of allowing @SafeVarargs on private instance methods:
> 
>    JDK-8048014: Update java.lang.SafeVararags for private methods
> 
> The patch is
> 
> diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
> --- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23 12:12:30 2014 -0700
> +++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24 10:03:21 2014 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2010, 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 @@
>  * 
  •   the declaration is a fixed arity method or constructor
>  *
>  * 
  •  the declaration is a variable arity method that is neither
> - * {@code static} nor {@code final}.
> + * {@code static} nor {@code final} nor {@code private}.
>  *
>  * 
>  *
> 
> The bulk of the change to allow @SafeVarargs on private methods, including the tests, are over in the langtools repo with javac updates. The javac changes have been reviewed and approved on compiler-dev:
> 
> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html
> 
> Thanks,
> 
> -Joe




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 daniel.fuchs at oracle.com  Tue Jun 24 17:37:24 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Jun 2014 19:37:24 +0200
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: 
References: ,
	<53A7F7E2.2030006@oracle.com>, <53A83F87.5060505@oracle.com>,
	<53A84400.6090509@oracle.com>
	
Message-ID: <53A9B754.5010600@oracle.com>

Hi Jason,

Thanks for the feedback!

On 6/24/14 7:08 PM, Jason Mehrens wrote:
> Daniel,
>
>
> With regard to JDK-4420020, in the original webrev Jim was incorrectly using java.io.File.canWrite() but that webrev was replaced by the current version. The NIO.2 code performs the effective access checks correctly.

Thanks.

> With regard to JDK-6244047 my concern was that checking the permissions and preconditions up front is a small 'TOCTOU' race and redundant because the next step after that is to open the FileChannel. I would assume both CREATE or CREATE_NEW plus WRITE would perform the effective access checks on open.

OK.

> The use of delete on exit is a deal breaker because you can't undo a registration on close of the FileHandler which can trigger an OOME. See https://bugs.openjdk.java.net/browse/JDK-4872014. I've used custom proxy handlers that generate a file name based off of the LogRecord which results in generating lots of file names and opening and close the FileHandler on demand.

ah. hmmmm. I didn't think there would be that many FileHandlers...
Well - I guess that if we find a way to reuse the zombie
lock files then we don't really need the delete on exit.
Someone creating a FileHandler programmatically should be responsible
for closing it - so if an application creates FileHandlers without
closing them then it's a bug in the application.

> If the behavior is reverted to use CREATE instead of CREATE_NEW then we have to deal with JDK-8031438 because any user code can lock a file ahead of opening the FileHandler.

Yes - I discovered that while writing a test for my suggested fix ;-)
Catching OverlappingFileLockException in FileHandler.openFiles
and setting available to false when it's thrown fixes the issue.

So let's just remove the deleteOnExit & add the catch for 
OverlappingFileLockException to my patch and we should be
good.

On the other hand we could just use replace CREATE_NEW by
CREATE but I have some misgivings about the part that
sets available to true when tryLock throws an IOException.
I'm not sure we should be doing that if we haven't actually
created the lock file. So I think I'd prefer keeping the
two steps behavior - first try CREATE_NEW - then attempt
to use CREATE if CREATE_NEW failed...
I'm not sure CREATE will check the access rights for writing
in the directory if the file already exists - so checking
the directory for write access in that case is probably
the right thing to do.

Would you agree?

-- daniel

>
> Jason
>
>
>
> ----------------------------------------
>> Date: Mon, 23 Jun 2014 17:13:04 +0200
>> From: daniel.fuchs at oracle.com
>> To: Alan.Bateman at oracle.com; jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
>> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>>
>> On 6/23/14 4:53 PM, Alan Bateman wrote:
>>> On 23/06/2014 10:48, Daniel Fuchs wrote:
>>>> :
>>>>
>>>> All in all - I feel our best options would be to revert to using
>>>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>>>> and live with the issue.
>>>> Hopefully some nio experts will chime in ;-)
>>>>
>>> The logging use of FileLock is a bit unusual but looking at it now then
>>> I don't see the reason why it needs to use CREATE_NEW.
>>
>> OK - thanks - in the discussion that ended up in the patch where
>> CREATE_NEW was introduced Jason (I think it was Jason) pointed at
>> https://bugs.openjdk.java.net/browse/JDK-4420020
>>
>> I'm guessing here that maybe it would be wrong to use an already
>> existing lock file if you don't have the rights to write to
>> its directory - and that using CREATE_NEW ensures that you have
>> all necessary access rights all along the path.
>>
>>> I don't think
>>> DELETE_ON_CLOSE is suitable here as that work is for transient work
>>> files which isn't the case here. Instead it could use deleteOnExit to
>>> have some chance of removing it on a graceful exit.
>>
>> Right - I suggested a patch in another mail where I just use that.
>>
>>>
>>> BTW: Do you know why locks is Map? Would a Set do?
>>
>> It certainly looks as if we could use a simple HashSet here.
>>
>> Thanks Alan!
>>
>> -- daniel
>>
>>>
>>> -Alan.
>>>
>> 		 	   		



From pbenedict at apache.org  Tue Jun 24 17:43:16 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 24 Jun 2014 12:43:16 -0500
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for
	private methods
In-Reply-To: 
References: <53A9B19F.6090300@oracle.com>
	
Message-ID: 

Will there be another ticket to update the section (9.6.4.7.) in JLS 9?


Cheers,
Paul


On Tue, Jun 24, 2014 at 12:27 PM, Lance Andersen 
wrote:

> +1
> On Jun 24, 2014, at 1:13 PM, Joe Darcy  wrote:
>
> > Hello,
> >
> > Please review the libraries update portion of allowing @SafeVarargs on
> private instance methods:
> >
> >    JDK-8048014: Update java.lang.SafeVararags for private methods
> >
> > The patch is
> >
> > diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
> > --- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23
> 12:12:30 2014 -0700
> > +++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24
> 10:03:21 2014 -0700
> > @@ -1,5 +1,5 @@
> > /*
> > - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights
> reserved.
> > + * Copyright (c) 2010, 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 @@
> >  * 
  •   the declaration is a fixed arity method or constructor
> >  *
> >  * 
  •  the declaration is a variable arity method that is neither
> > - * {@code static} nor {@code final}.
> > + * {@code static} nor {@code final} nor {@code private}.
> >  *
> >  * 
> >  *
> >
> > The bulk of the change to allow @SafeVarargs on private methods,
> including the tests, are over in the langtools repo with javac updates. The
> javac changes have been reviewed and approved on compiler-dev:
> >
> >
> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html
> >
> > Thanks,
> >
> > -Joe
>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>
>


From joe.darcy at oracle.com  Tue Jun 24 17:48:47 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 Jun 2014 10:48:47 -0700
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for
	private methods
In-Reply-To: 
References: <53A9B19F.6090300@oracle.com>	
	
Message-ID: <53A9B9FF.9060802@oracle.com>

On 06/24/2014 10:43 AM, Paul Benedict wrote:
> Will there be another ticket to update the section (9.6.4.7.) in JLS 9?

     JDK-8047159: 9.6.4.7: Allow @SafeVarargs on private methods
     https://bugs.openjdk.java.net/browse/JDK-8047159

Cheers,

-Joe

>
>
> Cheers,
> Paul
>
>
> On Tue, Jun 24, 2014 at 12:27 PM, Lance Andersen 
> > wrote:
>
>     +1
>     On Jun 24, 2014, at 1:13 PM, Joe Darcy      > wrote:
>
>     > Hello,
>     >
>     > Please review the libraries update portion of allowing
>     @SafeVarargs on private instance methods:
>     >
>     >    JDK-8048014: Update java.lang.SafeVararags for private methods
>     >
>     > The patch is
>     >
>     > diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
>     > --- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23
>     12:12:30 2014 -0700
>     > +++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24
>     10:03:21 2014 -0700
>     > @@ -1,5 +1,5 @@
>     > /*
>     > - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All
>     rights reserved.
>     > + * Copyright (c) 2010, 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 @@
>     >  * 
  •   the declaration is a fixed arity method or constructor
>     >  *
>     >  * 
  •  the declaration is a variable arity method that is neither
>     > - * {@code static} nor {@code final}.
>     > + * {@code static} nor {@code final} nor {@code private}.
>     >  *
>     >  * 
>     >  *
>     >
>     > The bulk of the change to allow @SafeVarargs on private methods,
>     including the tests, are over in the langtools repo with javac
>     updates. The javac changes have been reviewed and approved on
>     compiler-dev:
>     >
>     >
>     http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html
>     >
>     > Thanks,
>     >
>     > -Joe
>
>
>
>
>     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  Tue Jun 24 18:06:03 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 24 Jun 2014 11:06:03 -0700
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: <43D2525D-ABCC-41F6-BEF7-D88E82F3B7B8@oracle.com>
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
	<43D2525D-ABCC-41F6-BEF7-D88E82F3B7B8@oracle.com>
Message-ID: <17576F26-39FC-4591-8B61-0D8E7488A52F@oracle.com>


On Jun 24 2014, at 01:46 , Chris Hegarty  wrote:

> Looks good to me Mike.
> 
> I agree with Paul?s comment that the javadoc change will never be seen in the public docs, but I still think it is a reasonable addition for future maintainers.
> 
> Trivially, you should probably add @SuppressWarnings("unchecked?) to typeCheck(Object).

Done.


> 
> -Chris.
> 
> On 24 Jun 2014, at 01:42, Mike Duigou  wrote:
> 
>> Hello all;
>> 
>> This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked into the wrapped list.
>> 
>> This changeset adds a check on the proposed replacement value and throws a ClassCastException if the replacement value is incompatible with the list. Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>> 
>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>> 
>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>> 
>> This change will be backported to Java 8.
>> 
>> Mike
> 



From joe.darcy at oracle.com  Tue Jun 24 18:23:37 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 Jun 2014 11:23:37 -0700
Subject: A question about Depth of container annotations
In-Reply-To: 
References: 
Message-ID: <53A9C229.60103@oracle.com>

Hello,

The behavior you're interested in is defined in the AnnotatedElement 
specification:

http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html

In brief, none of the methods in AnnotatedElement look through more than 
one level of containment. (Likewise, when writing repeated annotation in 
source code, the compiler will only create one level of containers.)

You may be interested in reviewing design discussions of this feature 
that occurred on

http://mail.openjdk.java.net/mailman/listinfo/enhanced-metadata-spec-discuss

Cheers,

-Joe

On 06/24/2014 01:21 AM, deven you wrote:
> Hi All,
>
> I have a question about repeated annotation depth. If this is not the
> proper mailing list group, please tell me where I should send it to.
>
> My question will be about the depth of container annotations. For instance,
> assume there are 3 annotations.
> - RepeatedAnn
> - ContainerAnn
> - ContainerContainerAnn
>
> So, ContainerContainerAnn can have ContainerAnn and that can also have
> RepeatbleAnn in it.
>
> In this case, get*AnnotationsByType(RepeatableAnn) APIs wont return
> repeteableAnns in depth 2.
>
> Java docs don't talk about the depth. I wonder if the get*AnnotationsByType
> api should return the annotations of all depth?
>
> If we have below annotations:
> @Retention(RetentionPolicy.RUNTIME)
> @Repeatable(ContainerAnn.class)
> @interface RepeatableAnn { String value(); }
>
> @Inherited
> @Retention(RetentionPolicy.RUNTIME)
> @Repeatable(ContainerContainerAnn.class)
> @interface ContainerAnn { RepeatableAnn[] value(); }
>
> @Inherited
> @Retention(RetentionPolicy.RUNTIME)
> @interface ContainerContainerAnn { ContainerAnn[] value(); }
>
> And the main class is annotated by :
>
> @ContainerAnn({@RepeatableAnn("Parent-3")})
> @ContainerAnn({@RepeatableAnn("Parent-4")})
> public class Test { ...
>
> when we call getAnnotationsByType(RepeatableAnn.class) on this class, we
> get nothing because RepeatableAnn is contained by ContainerAnn which is
> also contained by ContainerContainerAnn. In other words, RepeatableAnn is
> in depth 2 and get*AnnotationsByType APIs only searches depth 1. The test
> results are:
>
> /home/deven/jdk8_20/jdk1.8.0_20/bin$ java repeated.Test
> CLASS = repeated.Test
> getDeclaredAnnotationsByType(RepeatableAnn.class)
> getDeclaredAnnotationsByType(ContainerAnn.class)
>
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)])
>
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])
> getDeclaredAnnotationsByType(ContainerContainerAnn.class)
>
> @repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]),
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])])
> getAnnotationsByType(RepeatableAnn.class)
> getAnnotationsByType(ContainerAnn.class)
>
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)])
>
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])
> getAnnotationsByType(ContainerContainerAnn.class)
>
> @repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]),
> @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])])



From mike.duigou at oracle.com  Tue Jun 24 18:25:52 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 24 Jun 2014 11:25:52 -0700
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: 
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
	
Message-ID: 


On Jun 24 2014, at 01:18 , Paul Sandoz  wrote:
>> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>> 
> 
> No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:
> 
> 3388      * Any attempt to insert an element of the wrong type will result in
> 3389      * an immediate {@link ClassCastException}.  Assuming a list contains

Yes, it is redundant but might be informative if a user goes to the examine the source when encountering a CCE. I can remove it if that is really preferred.

>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>> 
>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>> 
> 
> Are there existing tests for the checked Map.replaceAll (for keys and values)?

Not specifically for illegal values returned by the operator. I can easily adapt the new test I added to specifically test for this case.

Updated webrev with additional Map test and Chris's suggestion is here: http://cr.openjdk.java.net/~mduigou/JDK-8047795/1/webrev/

Mike

From daniel.fuchs at oracle.com  Tue Jun 24 18:34:46 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Jun 2014 20:34:46 +0200
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: 
References: 
Message-ID: <53A9C4C6.3060405@oracle.com>

Hi,

Please find below a patch [1] for [2]:

8048020 - Regression on java.util.logging.FileHandler

This corresponds to the problem that was discussed on this list
in the following email thread:

"Zombie FileHandler locks can exhaust all available log file locks."
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html


[1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8048020

This patch would be a good candidate for being backported on 8, since
the issue was introduced in 8.

best regards,

-- daniel


From henry.jen at oracle.com  Tue Jun 24 20:00:27 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Jun 2014 13:00:27 -0700
Subject: RFR: 8048021: Remove @version tag in jaxp repo
In-Reply-To: <53A4D0A8.5040104@oracle.com>
References: <53A4AA24.40309@oracle.com> <53A4B76A.70608@oracle.com>
	<53A4D0A8.5040104@oracle.com>
Message-ID: <53A9D8DB.9020908@oracle.com>

Hi,

As a follow up task, please review the trivial webrev to remove @version 
tags used with SCM, which is likely to be meaningless to javadoc readers.

In this webrev, we only remove @version with $Id or $Revision for .jave 
or package.html cause appearance to javadoc.

We keep those in .properties files also those @version tags with 
specific version information.

Cheers,
Henry


On 06/20/2014 05:24 PM, Henry Jen wrote:
> Looks like it's pretty easy to do a find and replace in files in jaxp
> folder. If this is desired, we can do it in a separate webrev to be
> clear on changeset history?
>
> Cheers,
> Henry
>
> On 06/20/2014 03:36 PM, huizhe wang wrote:
>> Hi Henry,
>>
>> Is it possible to add to the @since tool/script to remove repository
>> revision notes?  They appear in the API document as if they reflect
>> meaningful "version". An example in
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html
>>
>>
>>
>>    * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $
>>


From jason_mehrens at hotmail.com  Tue Jun 24 20:55:20 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Jun 2014 15:55:20 -0500
Subject: Zombie FileHandler locks can exhaust all available log file locks.
In-Reply-To: <53A9B754.5010600@oracle.com>
References: ,
	<53A7F7E2.2030006@oracle.com>, <53A83F87.5060505@oracle.com>,
	<53A84400.6090509@oracle.com>
	,
	<53A9B754.5010600@oracle.com>
Message-ID: 

Daniel,


I agree with you.  I think you have it all covered.


Thanks for working on this!


Jason


----------------------------------------
> Date: Tue, 24 Jun 2014 19:37:24 +0200
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com; alan.bateman at oracle.com; core-libs-dev at openjdk.java.net
> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>
> Hi Jason,
>
> Thanks for the feedback!
>
> On 6/24/14 7:08 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> With regard to JDK-4420020, in the original webrev Jim was incorrectly using java.io.File.canWrite() but that webrev was replaced by the current version. The NIO.2 code performs the effective access checks correctly.
>
> Thanks.
>
>> With regard to JDK-6244047 my concern was that checking the permissions and preconditions up front is a small 'TOCTOU' race and redundant because the next step after that is to open the FileChannel. I would assume both CREATE or CREATE_NEW plus WRITE would perform the effective access checks on open.
>
> OK.
>
>> The use of delete on exit is a deal breaker because you can't undo a registration on close of the FileHandler which can trigger an OOME. See https://bugs.openjdk.java.net/browse/JDK-4872014. I've used custom proxy handlers that generate a file name based off of the LogRecord which results in generating lots of file names and opening and close the FileHandler on demand.
>
> ah. hmmmm. I didn't think there would be that many FileHandlers...
> Well - I guess that if we find a way to reuse the zombie
> lock files then we don't really need the delete on exit.
> Someone creating a FileHandler programmatically should be responsible
> for closing it - so if an application creates FileHandlers without
> closing them then it's a bug in the application.
>
>> If the behavior is reverted to use CREATE instead of CREATE_NEW then we have to deal with JDK-8031438 because any user code can lock a file ahead of opening the FileHandler.
>
> Yes - I discovered that while writing a test for my suggested fix ;-)
> Catching OverlappingFileLockException in FileHandler.openFiles
> and setting available to false when it's thrown fixes the issue.
>
> So let's just remove the deleteOnExit & add the catch for
> OverlappingFileLockException to my patch and we should be
> good.
>
> On the other hand we could just use replace CREATE_NEW by
> CREATE but I have some misgivings about the part that
> sets available to true when tryLock throws an IOException.
> I'm not sure we should be doing that if we haven't actually
> created the lock file. So I think I'd prefer keeping the
> two steps behavior - first try CREATE_NEW - then attempt
> to use CREATE if CREATE_NEW failed...
> I'm not sure CREATE will check the access rights for writing
> in the directory if the file already exists - so checking
> the directory for write access in that case is probably
> the right thing to do.
>
> Would you agree?
>
> -- daniel
>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>> Date: Mon, 23 Jun 2014 17:13:04 +0200
>>> From: daniel.fuchs at oracle.com
>>> To: Alan.Bateman at oracle.com; jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net
>>> Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
>>>
>>> On 6/23/14 4:53 PM, Alan Bateman wrote:
>>>> On 23/06/2014 10:48, Daniel Fuchs wrote:
>>>>> :
>>>>>
>>>>> All in all - I feel our best options would be to revert to using
>>>>> CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
>>>>> and live with the issue.
>>>>> Hopefully some nio experts will chime in ;-)
>>>>>
>>>> The logging use of FileLock is a bit unusual but looking at it now then
>>>> I don't see the reason why it needs to use CREATE_NEW.
>>>
>>> OK - thanks - in the discussion that ended up in the patch where
>>> CREATE_NEW was introduced Jason (I think it was Jason) pointed at
>>> https://bugs.openjdk.java.net/browse/JDK-4420020
>>>
>>> I'm guessing here that maybe it would be wrong to use an already
>>> existing lock file if you don't have the rights to write to
>>> its directory - and that using CREATE_NEW ensures that you have
>>> all necessary access rights all along the path.
>>>
>>>> I don't think
>>>> DELETE_ON_CLOSE is suitable here as that work is for transient work
>>>> files which isn't the case here. Instead it could use deleteOnExit to
>>>> have some chance of removing it on a graceful exit.
>>>
>>> Right - I suggested a patch in another mail where I just use that.
>>>
>>>>
>>>> BTW: Do you know why locks is Map? Would a Set do?
>>>
>>> It certainly looks as if we could use a simple HashSet here.
>>>
>>> Thanks Alan!
>>>
>>> -- daniel
>>>
>>>>
>>>> -Alan.
>>>>
>>>
> 		 	   		  

From huizhe.wang at oracle.com  Tue Jun 24 20:56:04 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 24 Jun 2014 13:56:04 -0700
Subject: RFR: 8048021: Remove @version tag in jaxp repo
In-Reply-To: <53A9D8DB.9020908@oracle.com>
References: <53A4AA24.40309@oracle.com> <53A4B76A.70608@oracle.com>
	<53A4D0A8.5040104@oracle.com> <53A9D8DB.9020908@oracle.com>
Message-ID: <53A9E5E4.1070602@oracle.com>

Looks good. Thanks for the extra work!

I think your webrev is here: 
http://cr.openjdk.java.net/~henryjen/jdk9/8048021/0/webrev/

Cheers,
Joe

On 6/24/2014 1:00 PM, Henry Jen wrote:
> Hi,
>
> As a follow up task, please review the trivial webrev to remove 
> @version tags used with SCM, which is likely to be meaningless to 
> javadoc readers.
>
> In this webrev, we only remove @version with $Id or $Revision for 
> .jave or package.html cause appearance to javadoc.
>
> We keep those in .properties files also those @version tags with 
> specific version information.
>
> Cheers,
> Henry
>
>
> On 06/20/2014 05:24 PM, Henry Jen wrote:
>> Looks like it's pretty easy to do a find and replace in files in jaxp
>> folder. If this is desired, we can do it in a separate webrev to be
>> clear on changeset history?
>>
>> Cheers,
>> Henry
>>
>> On 06/20/2014 03:36 PM, huizhe wang wrote:
>>> Hi Henry,
>>>
>>> Is it possible to add to the @since tool/script to remove repository
>>> revision notes?  They appear in the API document as if they reflect
>>> meaningful "version". An example in
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html 
>>>
>>>
>>>
>>>
>>>    * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $
>>>



From henry.jen at oracle.com  Tue Jun 24 21:04:45 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Jun 2014 14:04:45 -0700
Subject: RFR: 8048021: Remove @version tag in jaxp repo
In-Reply-To: <53A9E5E4.1070602@oracle.com>
References: <53A4AA24.40309@oracle.com> <53A4B76A.70608@oracle.com>
	<53A4D0A8.5040104@oracle.com> <53A9D8DB.9020908@oracle.com>
	<53A9E5E4.1070602@oracle.com>
Message-ID: <53A9E7ED.8060408@oracle.com>

Thanks for reviewing, glad you find out where it is.

Cheers,
Henry

On 06/24/2014 01:56 PM, huizhe wang wrote:
> Looks good. Thanks for the extra work!
>
> I think your webrev is here:
> http://cr.openjdk.java.net/~henryjen/jdk9/8048021/0/webrev/
>
> Cheers,
> Joe
>
> On 6/24/2014 1:00 PM, Henry Jen wrote:
>> Hi,
>>
>> As a follow up task, please review the trivial webrev to remove
>> @version tags used with SCM, which is likely to be meaningless to
>> javadoc readers.
>>
>> In this webrev, we only remove @version with $Id or $Revision for
>> .jave or package.html cause appearance to javadoc.
>>
>> We keep those in .properties files also those @version tags with
>> specific version information.
>>
>> Cheers,
>> Henry
>>
>>
>> On 06/20/2014 05:24 PM, Henry Jen wrote:
>>> Looks like it's pretty easy to do a find and replace in files in jaxp
>>> folder. If this is desired, we can do it in a separate webrev to be
>>> clear on changeset history?
>>>
>>> Cheers,
>>> Henry
>>>
>>> On 06/20/2014 03:36 PM, huizhe wang wrote:
>>>> Hi Henry,
>>>>
>>>> Is it possible to add to the @since tool/script to remove repository
>>>> revision notes?  They appear in the API document as if they reflect
>>>> meaningful "version". An example in
>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>>    * @version $Revision: 1.9 $, $Date: 2010/05/25 16:19:44 $
>>>>
>


From neil.toda at oracle.com  Tue Jun 24 21:28:48 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Tue, 24 Jun 2014 14:28:48 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A970E5.8060908@oracle.com>
References: <53A38068.6010200@oracle.com> <53A42284.4020707@oracle.com>
	<53A46656.3010105@oracle.com> <53A4BDEE.8040305@oracle.com>
	<53A4C34C.4010004@oracle.com> <53A4C799.900@oracle.com>
	<53A86350.4020802@oracle.com> <53A970E5.8060908@oracle.com>
Message-ID: <53A9ED90.6060905@oracle.com>


New webrev-05 with Kumar's comments except for the "C'ish" style. 
Explained below.

http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/

105 : DONE
146: DONE
168: DONE

106: Your suggestion was the way I had originally coded it for Linux.  
However
          on Windows/Cygwin, the code will not compile  There is some 
interaction
          with the doExec() preceeding it and the fact that it is a 
varlist.  This coding
          was the simplest workaround.

Thanks for the nits Kumar.


On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
> Neil,
>
> Some nits:
>
> TestSpecialArgs.java:
>
> extra space
> 105 for ( String line : tr.testOutput) {
>
>
>
> This is very C'ish, I suggest.
>  -106                 int index;
>  -107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>
>  +106                 int index =  line.indexOf(envVarPidString);
>  +107                 if (index >= 0) {
>
>
> Needs space
> -146 launcherPid = line.substring(sindex,tindex);
> +146 launcherPid = line.substring(sindex, tindex);
>
> Needs space
>
> -168             if (!tr.contains("NativeMemoryTracking: got value 
> "+NMT_Option_Value)) {
> +168             if (!tr.contains("NativeMemoryTracking: got value " + 
> NMT_Option_Value)) {
>
>
> Thanks
> Kumar
>
>
> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>
>> I've spun a new webrev based on the comments for webrev-03:
>>
>>     http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>
>> Changes are:
>>
>>   1) java.c
>>         a) add free(envName) line 1063
>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 1056
>>
>> Thanks
>>
>> -neil
>>
>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>> Neil,
>>>
>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>> that one.
>>> Are you going to post another iteration ?
>>>
>>> Kumar
>>>
>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>
>>>> Thanks Joe.  It would have checked for NULL for me.
>>>> I'll use the JLI wrapper.
>>>>
>>>> -neil
>>>>
>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>> Memory allocation in the launcher should use one of the 
>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>
>>>>> -Joe
>>>>>
>>>>>
>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>
>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>>>>> non-null.
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>> Neil,
>>>>>>>
>>>>>>> Thanks for quick implementation.
>>>>>>>
>>>>>>> java.c:
>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>> code analyzers will complain.
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>
>>>>>>>> Launcher support for modified Native Memory Tracking mechanism 
>>>>>>>> in JVM in JDK9.
>>>>>>>>
>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From peter.levart at gmail.com  Tue Jun 24 21:35:37 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Jun 2014 23:35:37 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>			<53A98525.9080908@gmail.com>
	
Message-ID: <53A9EF29.7030208@gmail.com>


On 06/24/2014 06:01 PM, Martin Buchholz wrote:
>
>
>
> On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart  > wrote:
>
>
>     I would rather use SecureRandom.generateSeed() instance method
>     instead of SecureRandom.nextBytes(). Why? Because every
>     SecureRandom instance has to initialize it's seed 1st before
>     getBytes() can provide the next random bytes from the PRNG. Since
>     we only need the 1st 8 bytes from the SecureRandom instance to
>     initialize TLR's seeder, we might as well directly call the
>     SecureRandom.generateSeed() method.
>
>
> If I strace this program on Linux using strace -ff -q java SecureRandoms:
>
> public class SecureRandoms {
>     public static void main(String[] args) throws Throwable {
>         byte[] bytes = new byte[8];
>         new java.security.SecureRandom().nextBytes(bytes);
>     }
> }
>
> I see a read from /dev/urandom, but not from /dev/random, so I 
> conclude your intuitive understanding of how the seeding works must be 
> wrong.  It makes sense that NativePRNG doesn't need to do any special 
> seeding of its own, since it reuses the operating system's.

You're right. I checked again. The  NativePRNG is actually using 
/dev/urandom (by default unless java.security.egd or securerandom.source 
is defined). It's mixing the /dev/urandom stream with the stream 
obtained from SHA1 generator which is seeded by 20 bytes from 
/dev/urandom too. So by default yes, plain NativePRNG (the default on 
UNIX-es) is using /dev/urandom for nextBytes(), but this can be changed 
by defining java.security.egd or securerandom.source system property. I 
still think that for configuration-independent PRNG seed on UNIX-es it's 
better to invoke generateSeed() on NativePRNG$NonBlocking, which 
hard-codes /dev/urandom and doesn't mix it with SHA1 stream.

On Windows, there's a different story, since the default SecureRandom 
algorithm is SHA1, seeded by SeedGenerator.getSystemEntropy() and 
SeedGenerator.generateSeed(). The former call includes invoking 
networking code and resolving local host name. Which we would like to 
avoid. So I think we need a nicer story on windows then just: new 
SecureRandom().nextBytes(). I propose requesting explicit algorithm / 
provider on each particular platform that we know does best what we 
want, rather than using default which can still be used as a fall-back.

Regards, Peter



From paul.sandoz at oracle.com  Wed Jun 25 08:30:31 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Jun 2014 10:30:31 +0200
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: 
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
	
	
Message-ID: <6A16A7C2-49D2-440A-ABD7-88BA2FF2F5FB@oracle.com>

On Jun 24, 2014, at 8:25 PM, Mike Duigou  wrote:
> 
> On Jun 24 2014, at 01:18 , Paul Sandoz  wrote:
>>> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>>> 
>> 
>> No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:
>> 
>> 3388      * Any attempt to insert an element of the wrong type will result in
>> 3389      * an immediate {@link ClassCastException}.  Assuming a list contains
> 
> Yes, it is redundant but might be informative if a user goes to the examine the source when encountering a CCE. I can remove it if that is really preferred.
> 

I don't have a strong opinion, but i feel what is written is mostly stating the obvious. The important aspect, which is implied, "fail-first" rather than "all-or-nothing" is not mentioned. It might be better to do so and contrast it with the addAll implementation (same applies to the Map.replaceAll method if you want to be consistent). No need to block the review or another round on this if you make any further changes.


>>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>>> 
>>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>>> 
>> 
>> Are there existing tests for the checked Map.replaceAll (for keys and values)?
> 
> Not specifically for illegal values returned by the operator. I can easily adapt the new test I added to specifically test for this case.
> 

Ah, yes, it's just values.


> Updated webrev with additional Map test and Chris's suggestion is here: http://cr.openjdk.java.net/~mduigou/JDK-8047795/1/webrev/
> 

+1

--

I thought the javac compiler configuration would have flagged the need for @SuppressWarnings as an error, or is that not switched on yet?

Paul.



From forax at univ-mlv.fr  Wed Jun 25 08:35:38 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 25 Jun 2014 10:35:38 +0200
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for
	private methods
In-Reply-To: <53A9B19F.6090300@oracle.com>
References: <53A9B19F.6090300@oracle.com>
Message-ID: <53AA89DA.9070800@univ-mlv.fr>

Hi Joe,

Just for completeness, there is another case where @SafeVarargs is safe,
any methods of an internal class (inner class static or not) declared 
private that is not overridden.

because the internal class is private, the compiler can easily check all 
possible subclasses in the compilation unit of that class.

cheers,
R?mi

On 06/24/2014 07:13 PM, Joe Darcy wrote:
> Hello,
>
> Please review the libraries update portion of allowing @SafeVarargs on 
> private instance methods:
>
>     JDK-8048014: Update java.lang.SafeVararags for private methods
>
> The patch is
>
> diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
> --- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23 
> 12:12:30 2014 -0700
> +++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24 
> 10:03:21 2014 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2010, 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 @@
>   * 
  •   the declaration is a fixed arity method or constructor
>   *
>   * 
  •  the declaration is a variable arity method that is neither
> - * {@code static} nor {@code final}.
> + * {@code static} nor {@code final} nor {@code private}.
>   *
>   * 
>   *
>
> The bulk of the change to allow @SafeVarargs on private methods, 
> including the tests, are over in the langtools repo with javac 
> updates. The javac changes have been reviewed and approved on 
> compiler-dev:
>
> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html
>
> Thanks,
>
> -Joe



From jason_mehrens at hotmail.com  Wed Jun 25 12:34:23 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 25 Jun 2014 07:34:23 -0500
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: <53A9C4C6.3060405@oracle.com>
References: ,
	<53A9C4C6.3060405@oracle.com>
Message-ID: 

Daniel,


FileChannel.open(WRITE,APPEND) could throw NoSuchFileException during a startup and shutdown race between two VMs.  That case needs to either perform a bounded retry or continue and rotate.


Jason

----------------------------------------
> Date: Tue, 24 Jun 2014 20:34:46 +0200
> From: daniel.fuchs at oracle.com
> To: core-libs-dev at openjdk.java.net
> CC: jason_mehrens at hotmail.com; Alan.Bateman at oracle.com
> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
>
> Hi,
>
> Please find below a patch [1] for [2]:
>
> 8048020 - Regression on java.util.logging.FileHandler
>
> This corresponds to the problem that was discussed on this list
> in the following email thread:
>
> "Zombie FileHandler locks can exhaust all available log file locks."
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html
>
>
> [1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8048020
>
> This patch would be a good candidate for being backported on 8, since
> the issue was introduced in 8.
>
> best regards,
>
> -- daniel 		 	   		  

From joe.darcy at oracle.com  Wed Jun 25 14:48:01 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 25 Jun 2014 07:48:01 -0700
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: <6A16A7C2-49D2-440A-ABD7-88BA2FF2F5FB@oracle.com>
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>		
	<6A16A7C2-49D2-440A-ABD7-88BA2FF2F5FB@oracle.com>
Message-ID: <53AAE121.4060204@oracle.com>

On 06/25/2014 01:30 AM, Paul Sandoz wrote:
> On Jun 24, 2014, at 8:25 PM, Mike Duigou  wrote:
>> On Jun 24 2014, at 01:18 , Paul Sandoz  wrote:
>>>> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>>>>
>>> No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:
>>>
>>> 3388      * Any attempt to insert an element of the wrong type will result in
>>> 3389      * an immediate {@link ClassCastException}.  Assuming a list contains
>> Yes, it is redundant but might be informative if a user goes to the examine the source when encountering a CCE. I can remove it if that is really preferred.
>>
> I don't have a strong opinion, but i feel what is written is mostly stating the obvious. The important aspect, which is implied, "fail-first" rather than "all-or-nothing" is not mentioned. It might be better to do so and contrast it with the addAll implementation (same applies to the Map.replaceAll method if you want to be consistent). No need to block the review or another round on this if you make any further changes.
>
>
>>>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>>>>
>>>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>>>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>>>>
>>> Are there existing tests for the checked Map.replaceAll (for keys and values)?
>> Not specifically for illegal values returned by the operator. I can easily adapt the new test I added to specifically test for this case.
>>
> Ah, yes, it's just values.
>
>
>> Updated webrev with additional Map test and Chris's suggestion is here: http://cr.openjdk.java.net/~mduigou/JDK-8047795/1/webrev/
>>
> +1
>
> --
>
> I thought the javac compiler configuration would have flagged the need for @SuppressWarnings as an error, or is that not switched on yet?
>
> Paul.
>

Unchecked and rawtypes warnings are the only ones not yet enabled in the 
build of the jdk repo in JDK 9, but that goal is getting closer :-)

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

-Joe



From Alan.Bateman at oracle.com  Wed Jun 25 15:07:25 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jun 2014 16:07:25 +0100
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: <53A9C4C6.3060405@oracle.com>
References: 
	<53A9C4C6.3060405@oracle.com>
Message-ID: <53AAE5AD.10600@oracle.com>

On 24/06/2014 19:34, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch [1] for [2]:
>
> 8048020 - Regression on java.util.logging.FileHandler
>
> This corresponds to the problem that was discussed on this list
> in the following email thread:
>
> "Zombie FileHandler locks can exhaust all available log file locks."
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html 
>
>
>
> [1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8048020
>
> This patch would be a good candidate for being backported on 8, since
> the issue was introduced in 8.
Catching OverlappingFileLockException is usually a sign of a mis-use. 
Can you summarize how this comes about (given the locking on "locks").

The three Files.isXXX are expensive. This may be a case where you just 
attempt to create the file with FileChannel.open. It probably should be 
CREATE + WRITE + APPEND to avoid the case of another process or VM 
removing the file at around the same time.

-Alan.


From daniel.fuchs at oracle.com  Wed Jun 25 15:21:03 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 25 Jun 2014 17:21:03 +0200
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: <53AAE5AD.10600@oracle.com>
References: 
	<53A9C4C6.3060405@oracle.com> <53AAE5AD.10600@oracle.com>
Message-ID: <53AAE8DF.5070700@oracle.com>

On 6/25/14 5:07 PM, Alan Bateman wrote:
> On 24/06/2014 19:34, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch [1] for [2]:
>>
>> 8048020 - Regression on java.util.logging.FileHandler
>>
>> This corresponds to the problem that was discussed on this list
>> in the following email thread:
>>
>> "Zombie FileHandler locks can exhaust all available log file locks."
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027296.html
>>
>>
>>
>> [1] http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8048020
>>
>> This patch would be a good candidate for being backported on 8, since
>> the issue was introduced in 8.
> Catching OverlappingFileLockException is usually a sign of a mis-use.
> Can you summarize how this comes about (given the locking on "locks").

A file is just a file. So nothing prevents some other piece of code in
the same process to call FileChannel.lock() directly. For instance,
another Handler implementation might do that - given that our 'locks'
HashMap is private - it wouldn't be able to use it.

> The three Files.isXXX are expensive. This may be a case where you just
> attempt to create the file with FileChannel.open. It probably should be
> CREATE + WRITE + APPEND to avoid the case of another process or VM
> removing the file at around the same time.

The issue here is that CREATE + WRITE + APPEND will probably succeed
if the file exists - even though we can't write in its parent dir.
I am not sure we should be concerned about the performance of
opening the file for the FileHandler. It's usually not something
you do very often.

However - Jason is right - there is the potential for a race
condition - so I should probably catch FileNotFoundException
for the second call to FileChannel.open.

-- daniel
>
> -Alan.



From jason_mehrens at hotmail.com  Wed Jun 25 15:27:30 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 25 Jun 2014 10:27:30 -0500
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: <53AAE5AD.10600@oracle.com>
References: 
	<53A9C4C6.3060405@oracle.com>,<53AAE5AD.10600@oracle.com>
Message-ID: 

Alan,


> Catching OverlappingFileLockException is usually a sign of a mis-use. 
> Can you summarize how this comes about (given the locking on "locks"). 


Malicious intent or ignorant mis-use by code outside of the FileHandler can turn the FileHandler into a victim of that misuse.


=======

public static void main(String[] args) throws Exception {
        Path p = Files.createTempFile("test", "test");
        try (FileChannel pathogen = FileChannel.open(p, CREATE, WRITE)) {
            FileLock lck = pathogen.lock();
            System.out.println(lck);
            try (FileChannel fileHandler = FileChannel.open(p, WRITE, APPEND)) {
                FileLock fhl = fileHandler.lock();
                System.out.println(fhl);
            }
        } finally {
            Files.deleteIfExists(p);
        }
    }

=========

sun.nio.ch.FileLockImpl[0:9223372036854775807 exclusive valid]
Exception in thread "main" java.nio.channels.OverlappingFileLockException

=================


Jason 		 	   		  

From Alan.Bateman at oracle.com  Wed Jun 25 15:38:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jun 2014 16:38:29 +0100
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
In-Reply-To: <53AAE8DF.5070700@oracle.com>
References: 
	<53A9C4C6.3060405@oracle.com> <53AAE5AD.10600@oracle.com>
	<53AAE8DF.5070700@oracle.com>
Message-ID: <53AAECF5.6050508@oracle.com>

On 25/06/2014 16:21, Daniel Fuchs wrote:
> On 6/25/14 5:07 PM, Alan Bateman wrote:
>> Catching OverlappingFileLockException is usually a sign of a mis-use.
>> Can you summarize how this comes about (given the locking on "locks").
>
> A file is just a file. So nothing prevents some other piece of code in
> the same process to call FileChannel.lock() directly. For instance,
> another Handler implementation might do that - given that our 'locks'
> HashMap is private - it wouldn't be able to use it.
Okay, so this concern isn'tFileHandler but rather malicious or misguided 
usages in other code running in the same VM. In that case I think the 
comment could be a bit clearer that it's something other than the 
FileHandler that is locking the file.

>
> The issue here is that CREATE + WRITE + APPEND will probably succeed
> if the file exists - even though we can't write in its parent dir.
> I am not sure we should be concerned about the performance of
> opening the file for the FileHandler. It's usually not something
> you do very often.
I don't think the Files.isXXX is useful here, especially if there are 
other things changing the file system at the same time. There is no 
guarantee that FileChannel.open will succeed. This may be a case where 
you have to catch the IOException and continue  (it's not nice to use 
exceptions for control-flow but this may be one of these cases where it 
becomes necessary.

-Alan.


From joe.darcy at oracle.com  Wed Jun 25 16:16:15 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 25 Jun 2014 09:16:15 -0700
Subject: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for
	private methods
In-Reply-To: <53AA89DA.9070800@univ-mlv.fr>
References: <53A9B19F.6090300@oracle.com> <53AA89DA.9070800@univ-mlv.fr>
Message-ID: <53AAF5CF.60409@oracle.com>

Hi Remi,

Thanks for the note. However, I don't plan to extend @SafeVarargs to 
cover this case.

Cheers,

-Joe

On 6/25/2014 1:35 AM, Remi Forax wrote:
> Hi Joe,
>
> Just for completeness, there is another case where @SafeVarargs is safe,
> any methods of an internal class (inner class static or not) declared 
> private that is not overridden.
>
> because the internal class is private, the compiler can easily check 
> all possible subclasses in the compilation unit of that class.
>
> cheers,
> R?mi
>
> On 06/24/2014 07:13 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review the libraries update portion of allowing @SafeVarargs 
>> on private instance methods:
>>
>>     JDK-8048014: Update java.lang.SafeVararags for private methods
>>
>> The patch is
>>
>> diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java
>> --- a/src/share/classes/java/lang/SafeVarargs.java    Mon Jun 23 
>> 12:12:30 2014 -0700
>> +++ b/src/share/classes/java/lang/SafeVarargs.java    Tue Jun 24 
>> 10:03:21 2014 -0700
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2010, 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 @@
>>   * 
  •   the declaration is a fixed arity method or constructor
>>   *
>>   * 
  •  the declaration is a variable arity method that is neither
>> - * {@code static} nor {@code final}.
>> + * {@code static} nor {@code final} nor {@code private}.
>>   *
>>   * 
>>   *
>>
>> The bulk of the change to allow @SafeVarargs on private methods, 
>> including the tests, are over in the langtools repo with javac 
>> updates. The javac changes have been reviewed and approved on 
>> compiler-dev:
>>
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html 
>>
>>
>> Thanks,
>>
>> -Joe
>



From paul.sandoz at oracle.com  Wed Jun 25 16:43:09 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Jun 2014 18:43:09 +0200
Subject: RFR [9] 8041972: Add improved parse/format methods for
	Long/Integer
In-Reply-To: <53A32043.7070008@oracle.com>
References: <539CCE6D.6040207@oracle.com>	<539D8821.3070808@univ-mlv.fr>	<539D91A0.9050901@oracle.com>	<539E1CB4.2050502@oracle.com>	<539F4A6A.5020002@oracle.com>	<539F4FCE.9080903@oracle.com>	<53A04EE7.6090309@oracle.com>
	<53A06224.1040600@oracle.com> <53A32043.7070008@oracle.com>
Message-ID: <39373F79-DC28-4A51-B617-680C6C508538@oracle.com>

On Jun 19, 2014, at 7:39 PM, Claes Redestad  wrote:
> Hi,
> 
> an updated webrev with reworked, public methods is available here:
> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
> 
> Reviews are yet again appreciated!
> 

I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.)

Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException.

You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ).

Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case.

In Integer.java#643 you can combine the if statements like you have done for the equivalent method on Long.

Hth,
Paul.


From peter.levart at gmail.com  Wed Jun 25 17:41:57 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Jun 2014 19:41:57 +0200
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53A9EF29.7030208@gmail.com>
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>			<53A98525.9080908@gmail.com>
	
	<53A9EF29.7030208@gmail.com>
Message-ID: <53AB09E5.9070303@gmail.com>

To sum-up: We have a problem with TLR initialization since by default it 
uses networking code to compute initial "seeder" value which can execute 
user code in at least two situations:

- when "sun.net.spi.nameservice.provider" system property is defined to 
use custom NameService provider
- when custom SecurityManager is in effect while TLR is being initialized
- also, when "java.util.secureRandomSeed" is defined, at least on 
Windows this means that default SecureRandom algorithm will be using 
networking code too to gather system entropy

We could work-around these problems by delaying initialization of 
NameService provider(s), by-passing SecurityManager when obtaining MAC 
address from NetworkInterface and extending the semantics of 
"java.util.secureRandomSeed" property to specify explicit SecureRandom 
algorithm and provider to use when obtaining SecureRandom instance, like 
in the following patch:

http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR.initialSeed/webrev.01/

But on the other hand this seems too many knobs to worry about. Ideally 
one would like to always use OS provided native seed source, but 
SecureRandom (with all the security providers infrastructure) seems too 
heavy-weight to be used in classes like ThreadLocalRandom or 
SplittableRandom by default since they can be initialized very early in 
the start-up sequence. I made an experiment with class-loading. Recent 
JDK9 build loads 381 classes when running the following empty program on 
Linux:

public class test0 {
         public static void main(String[] args) {
         }
}

...ThreadLocalRandom is not among them. But in special configurations 
(like when using java agents) or in the future, it could be. The 
following program:

public class test {
         public static void main(String[] args) {
                 java.util.concurrent.ThreadLocalRandom.current();
         }
}

...loads 403 classes. That's 22 more than an empty program. The 
following classes are loaded in addition:

+ java.util.Random
+ java.util.concurrent.ThreadLocalRandom
+ java.net.NetworkInterface
+ java.net.NetworkInterface$1
+ java.net.InterfaceAddress
+ java.net.InetAddress
+ sun.security.action.GetBooleanAction
+ java.net.InetAddress$1
+ java.net.InetAddress$InetAddressHolder
+ java.net.InetAddress$Cache
+ java.net.InetAddress$Cache$Type
+ java.net.InetAddressImplFactory
+ java.net.InetAddressImpl
+ java.net.Inet6AddressImpl
+ sun.net.spi.nameservice.NameService
+ java.net.InetAddress$2
+ java.net.Inet4Address
+ java.net.Inet6Address
+ java.net.Inet6Address$Inet6AddressHolder
+ java.net.DefaultInterface
+ java.net.NetworkInterface$2
+ sun.nio.ch.Interruptible

If I run the same program but set the "java.util.secureRandomSeed=true", 
it loads 435 classes. Besides 381 classes loaded by an empty program, 
the following 54 classes are loaded in addition:

+ java.util.Random
+ java.util.concurrent.ThreadLocalRandom
+ java.security.SecureRandom
+ sun.security.jca.Providers
+ java.lang.InheritableThreadLocal
+ sun.security.jca.ProviderList
+ sun.security.jca.ProviderConfig
+ java.security.Provider
+ sun.security.jca.ProviderList$3
+ sun.security.jca.ProviderList$1
+ java.security.Provider$ServiceKey
+ java.security.Provider$EngineDescription
+ sun.misc.FloatingDecimal
+ sun.misc.FloatingDecimal$BinaryToASCIIConverter
+ sun.misc.FloatingDecimal$ExceptionalBinaryToASCIIBuffer
+ sun.misc.FloatingDecimal$BinaryToASCIIBuffer
+ sun.misc.FloatingDecimal$1
+ sun.misc.FloatingDecimal$ASCIIToBinaryConverter
+ sun.misc.FloatingDecimal$PreparedASCIIToBinaryBuffer
+ sun.misc.FDBigInteger
+ sun.security.jca.ProviderList$2
+ java.security.Security
+ java.security.Security$1
+ java.util.Properties$LineReader
+ java.util.AbstractList$Itr
+ sun.security.jca.ProviderConfig$2
+ sun.security.provider.Sun
+ sun.security.provider.SunEntries
+ sun.security.provider.SunEntries$1
+ java.security.SecureRandomSpi
+ sun.security.provider.NativePRNG
+ sun.security.provider.NativePRNG$Variant
+ sun.security.provider.NativePRNG$1
+ sun.security.provider.NativePRNG$2
+ java.net.URI
+ java.net.URI$Parser
+ sun.security.provider.NativePRNG$RandomIO
+ sun.security.provider.NativePRNG$Blocking
+ sun.security.provider.NativePRNG$NonBlocking
+ java.util.LinkedHashMap$LinkedEntrySet
+ java.util.LinkedHashMap$LinkedHashIterator
+ java.util.LinkedHashMap$LinkedEntryIterator
+ java.security.Provider$Service
+ java.security.Provider$UString
+ java.util.LinkedHashSet
+ java.util.LinkedHashMap$LinkedValues
+ java.util.LinkedHashMap$LinkedValueIterator
+ java.util.Collections$UnmodifiableSet
+ java.util.Collections$UnmodifiableCollection$1
+ java.util.LinkedHashMap$LinkedKeySet
+ java.util.LinkedHashMap$LinkedKeyIterator
+ sun.security.jca.GetInstance
+ sun.security.jca.GetInstance$Instance
+ sun.nio.ch.Interruptible


This seems too heavy-weight even if the initialization issue on Windows 
where default SecureRandom algorithm is using networking code to gather 
system entropy is worked-around by requesting explicit "Windows-PRNG" 
SecureRandom algorithm from "SunMSCAPI" provider.

Peeking around in the sun.security.provider package, I found there 
already is a minimal internal infrastructure for obtaining random seed. 
It's encapsulated in package-private abstract class 
sun.security.provider.SeedGenerator with 4 implementations. It turns out 
that, besides Java-only fall-back implementation called 
ThreadedSeedGenerator and generic URLSeedGenerator, there are also two 
implementations of NativeSeedGenerator (one for UNIX-es which is just an 
extension of URLSeedGenerator and the other for Windows which uses MS 
CryptoAPI). I made a few tweaks that allow this sub-infrastructure to be 
used directly in ThreadLocalRandom and SplittableRandom:

http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/

The changes are as follows:
- modified SeedGenerator to be a public class (was package-private as 
are still all it's subclasses)
- made its only public static method package-private (was public for no 
reason)
- made its only abstract method public (was package-private)
- made SeedGenerator implement AutoCloseable with empty close() method 
(overriden in URLSeedGenerator to close the underlying stream)
- added public static factory method to return a new instance of 
NativeSeedGenerator (using /dev/urandom on UNIX-es, MSCAPI on Windows) 
and protected it with a runtime check so that it can only be used internally

With these changes and modified TLR, running the test program (see 
above) loads only the following 15 additional classes besides those that 
are loaded by an empty program on Linux (and I assume the number is the 
same on Windows):


+ java.util.Random
+ java.util.concurrent.ThreadLocalRandom
+ sun.security.provider.SeedGenerator
+ sun.security.provider.SunEntries
+ sun.security.provider.SunEntries$1
+ java.security.Security
+ java.security.Security$1
+ java.util.Properties$LineReader
+ sun.security.provider.SeedGenerator$URLSeedGenerator
+ sun.security.provider.NativeSeedGenerator
+ sun.security.provider.SeedGenerator$1
+ sun.security.provider.SeedGenerator$URLSeedGenerator$1
+ java.net.URI
+ java.net.URI$Parser
+ sun.nio.ch.Interruptible


So what do you think is the best direction to go further with this? 
Patching networking or exposing NativeSeedGenerator to internal JDK code?


Regards, Peter



From neil.toda at oracle.com  Wed Jun 25 17:58:46 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Wed, 25 Jun 2014 10:58:46 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53A9ED90.6060905@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
Message-ID: <53AB0DD6.2060305@oracle.com>

Sorry.  One more webrev .. 06

http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/

Kumar's nit was correct and in fact index was old and should have been 
removed
allowing .contains member to be used instead of .indexOf.  So cleaned up 
a bit more
as can be seen below.  Other of Kumar's nits done.

Thanks Kumar.

webrev-06

  102             // get the PID from the env var we set for the JVM
  103             String envVarPid = null;
  104             for (String line : tr.testOutput) {
  105                 if (line.contains(envVarPidString)) {
  106                     int sindex = envVarPidString.length();
  107                     envVarPid = line.substring(sindex);
  108                     break;
  109                 }
  110             }
  111             // did we find envVarPid?
  112             if (envVarPid == null) {
  113                 System.out.println(tr);
  114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
  115             }



webrev-05

  102             // get the PID from the env var we set for the JVM
  103             haveLauncherPid = false;
  104             String envVarPid = null;
  105             for (String line : tr.testOutput) {
  106                 int index;
  107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
  108                     int sindex = envVarPidString.length();
  109                     envVarPid = line.substring(sindex);
  110                     haveLauncherPid = true;
  111                     break;
  112                 }
  113             }
  114             // did we find envVarPid?
  115             if (!haveLauncherPid) {
  116                 System.out.println(tr);
  117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
  118             }



On 6/24/2014 2:28 PM, Neil Toda wrote:
>
> New webrev-05 with Kumar's comments except for the "C'ish" style. 
> Explained below.
>
> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>
> 105 : DONE
> 146: DONE
> 168: DONE
>
> 106: Your suggestion was the way I had originally coded it for Linux.  
> However
>          on Windows/Cygwin, the code will not compile  There is some 
> interaction
>          with the doExec() preceeding it and the fact that it is a 
> varlist.  This coding
>          was the simplest workaround.
>
> Thanks for the nits Kumar.
>
>
> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>> Neil,
>>
>> Some nits:
>>
>> TestSpecialArgs.java:
>>
>> extra space
>> 105 for ( String line : tr.testOutput) {
>>
>>
>>
>> This is very C'ish, I suggest.
>>  -106                 int index;
>>  -107                 if ((index = line.indexOf(envVarPidString)) >= 
>> 0) {
>>
>>  +106                 int index = line.indexOf(envVarPidString);
>>  +107                 if (index >= 0) {
>>
>>
>> Needs space
>> -146 launcherPid = line.substring(sindex,tindex);
>> +146 launcherPid = line.substring(sindex, tindex);
>>
>> Needs space
>>
>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>> "+NMT_Option_Value)) {
>> +168             if (!tr.contains("NativeMemoryTracking: got value " 
>> + NMT_Option_Value)) {
>>
>>
>> Thanks
>> Kumar
>>
>>
>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>
>>> I've spun a new webrev based on the comments for webrev-03:
>>>
>>>     http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>
>>> Changes are:
>>>
>>>   1) java.c
>>>         a) add free(envName) line 1063
>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 1056
>>>
>>> Thanks
>>>
>>> -neil
>>>
>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>> Neil,
>>>>
>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>> that one.
>>>> Are you going to post another iteration ?
>>>>
>>>> Kumar
>>>>
>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>
>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>> I'll use the JLI wrapper.
>>>>>
>>>>> -neil
>>>>>
>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>> Memory allocation in the launcher should use one of the 
>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>
>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>
>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these are 
>>>>>>> non-null.
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>> Neil,
>>>>>>>>
>>>>>>>> Thanks for quick implementation.
>>>>>>>>
>>>>>>>> java.c:
>>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>>> code analyzers will complain.
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>
>>>>>>>>> Launcher support for modified Native Memory Tracking mechanism 
>>>>>>>>> in JVM in JDK9.
>>>>>>>>>
>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> -neil
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>



From zhengyu.gu at oracle.com  Wed Jun 25 19:05:12 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Wed, 25 Jun 2014 15:05:12 -0400
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AB0DD6.2060305@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com>
Message-ID: <53AB1D68.6000204@oracle.com>

Hi Neil,

I tried out this patch with my hotspot, it does not work.

The reason is that, the environment variable is setup too late, it has 
to be set before it launches JavaVM (before calling LoadJavaVM()) method.

Thanks,

-Zhengyu

On 6/25/2014 1:58 PM, Neil Toda wrote:
> Sorry.  One more webrev .. 06
>
> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>
> Kumar's nit was correct and in fact index was old and should have been 
> removed
> allowing .contains member to be used instead of .indexOf.  So cleaned 
> up a bit more
> as can be seen below.  Other of Kumar's nits done.
>
> Thanks Kumar.
>
> webrev-06
>   102             // get the PID from the env var we set for the JVM
>   103             String envVarPid = null;
>   104             for (String line : tr.testOutput) {
>   105                 if (line.contains(envVarPidString)) {
>   106                     int sindex = envVarPidString.length();
>   107                     envVarPid = line.substring(sindex);
>   108                     break;
>   109                 }
>   110             }
>   111             // did we find envVarPid?
>   112             if (envVarPid == null) {
>   113                 System.out.println(tr);
>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>   115             }
>
>
> webrev-05
>   102             // get the PID from the env var we set for the JVM
>   103             haveLauncherPid = false;
>   104             String envVarPid = null;
>   105             for (String line : tr.testOutput) {
>   106                 int index;
>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>   108                     int sindex = envVarPidString.length();
>   109                     envVarPid = line.substring(sindex);
>   110                     haveLauncherPid = true;
>   111                     break;
>   112                 }
>   113             }
>   114             // did we find envVarPid?
>   115             if (!haveLauncherPid) {
>   116                 System.out.println(tr);
>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>   118             }
>
>
> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>
>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>> Explained below.
>>
>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>
>> 105 : DONE
>> 146: DONE
>> 168: DONE
>>
>> 106: Your suggestion was the way I had originally coded it for 
>> Linux.  However
>>          on Windows/Cygwin, the code will not compile  There is some 
>> interaction
>>          with the doExec() preceeding it and the fact that it is a 
>> varlist.  This coding
>>          was the simplest workaround.
>>
>> Thanks for the nits Kumar.
>>
>>
>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>> Neil,
>>>
>>> Some nits:
>>>
>>> TestSpecialArgs.java:
>>>
>>> extra space
>>> 105 for ( String line : tr.testOutput) {
>>>
>>>
>>>
>>> This is very C'ish, I suggest.
>>>  -106                 int index;
>>>  -107                 if ((index = line.indexOf(envVarPidString)) >= 
>>> 0) {
>>>
>>>  +106                 int index = line.indexOf(envVarPidString);
>>>  +107                 if (index >= 0) {
>>>
>>>
>>> Needs space
>>> -146 launcherPid = line.substring(sindex,tindex);
>>> +146 launcherPid = line.substring(sindex, tindex);
>>>
>>> Needs space
>>>
>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>> "+NMT_Option_Value)) {
>>> +168             if (!tr.contains("NativeMemoryTracking: got value " 
>>> + NMT_Option_Value)) {
>>>
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>
>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>
>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>
>>>> Changes are:
>>>>
>>>>   1) java.c
>>>>         a) add free(envName) line 1063
>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 
>>>> 1056
>>>>
>>>> Thanks
>>>>
>>>> -neil
>>>>
>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>> Neil,
>>>>>
>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>> that one.
>>>>> Are you going to post another iteration ?
>>>>>
>>>>> Kumar
>>>>>
>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>
>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>> I'll use the JLI wrapper.
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>>
>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>
>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>> are non-null.
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>> Neil,
>>>>>>>>>
>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>
>>>>>>>>> java.c:
>>>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>>>> code analyzers will complain.
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>
>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>
>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> -neil
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>



From mike.duigou at oracle.com  Wed Jun 25 19:38:54 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 25 Jun 2014 12:38:54 -0700
Subject: RFR: 8047795: Collections.checkedList checking bypassed by
	List.replaceAll
In-Reply-To: <6A16A7C2-49D2-440A-ABD7-88BA2FF2F5FB@oracle.com>
References: <44CA8A07-687A-4159-B09A-C1072D70586E@oracle.com>
	
	
	<6A16A7C2-49D2-440A-ABD7-88BA2FF2F5FB@oracle.com>
Message-ID: <5475FFB1-0A52-4F36-B8DA-3247A22F6CE4@oracle.com>


On Jun 25 2014, at 01:30 , Paul Sandoz  wrote:

> On Jun 24, 2014, at 8:25 PM, Mike Duigou  wrote:
>> 
>> On Jun 24 2014, at 01:18 , Paul Sandoz  wrote:
>>>> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>>>> 
>>> 
>>> No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:
>>> 
>>> 3388      * Any attempt to insert an element of the wrong type will result in
>>> 3389      * an immediate {@link ClassCastException}.  Assuming a list contains
>> 
>> Yes, it is redundant but might be informative if a user goes to the examine the source when encountering a CCE. I can remove it if that is really preferred.
>> 
> 
> I don't have a strong opinion, but i feel what is written is mostly stating the obvious. The important aspect, which is implied, "fail-first" rather than "all-or-nothing" is not mentioned.

I added a sentence to the pushed version which better clarifies that it is not all-or-nothing.

> It might be better to do so and contrast it with the addAll implementation (same applies to the Map.replaceAll method if you want to be consistent). No need to block the review or another round on this if you make any further changes.
> 
> 
>>>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>>>> 
>>>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>>>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>>>> 
>>> 
>>> Are there existing tests for the checked Map.replaceAll (for keys and values)?
>> 
>> Not specifically for illegal values returned by the operator. I can easily adapt the new test I added to specifically test for this case.
>> 
> 
> Ah, yes, it's just values.
> 
> 
>> Updated webrev with additional Map test and Chris's suggestion is here: http://cr.openjdk.java.net/~mduigou/JDK-8047795/1/webrev/
>> 
> 
> +1
> 
> --
> 
> I thought the javac compiler configuration would have flagged the need for @SuppressWarnings as an error, or is that not switched on yet?
> 
> Paul.
> 



From mandy.chung at oracle.com  Wed Jun 25 20:21:12 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Jun 2014 13:21:12 -0700
Subject: Review request: 8029548 (jdeps) use @jdk.Exported to determine
	supported vs JDK internal API
Message-ID: <53AB2F38.7030700@oracle.com>

This patch is also intended to target for 8u40 backport.  It fixes
the following issues:

JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API
JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs
JDK-8031092 jdeps does not recognize --help option.
JDK-8048063 (jdeps) Add filtering capability

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/

jdeps will determine if it's a JDK internal API by checking the @jdk.Exported.
It also reads tools.jar and flags if they are non-exported.  javax.jnlp is
supported API but not annotated with @jdk.Exported and so we special case
it as a workaround. A new -filter option is added to provide an easy
way to do filtering e.g. -filter java.lang.*, -filter:archive to filter
out all dependences from the same archive (i.e the input JAR file or
directory).  The default is changed to filter out the dependences
within the same package.  I also have cleaned up and refactored some code
between JdepsTask and Analyzer to prepare for source restructuring
and modularization work.

thanks
Mandy



From neil.toda at oracle.com  Wed Jun 25 20:40:34 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Wed, 25 Jun 2014 13:40:34 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AB1D68.6000204@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
Message-ID: <53AB33C2.5050005@oracle.com>


Okay, Very glad you checked.  It really does need to go as early as your 
prototype suggested.
I'll get right on it.

-neil

On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
> Hi Neil,
>
> I tried out this patch with my hotspot, it does not work.
>
> The reason is that, the environment variable is setup too late, it has 
> to be set before it launches JavaVM (before calling LoadJavaVM()) method.
>
> Thanks,
>
> -Zhengyu
>
> On 6/25/2014 1:58 PM, Neil Toda wrote:
>> Sorry.  One more webrev .. 06
>>
>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>
>> Kumar's nit was correct and in fact index was old and should have 
>> been removed
>> allowing .contains member to be used instead of .indexOf.  So cleaned 
>> up a bit more
>> as can be seen below.  Other of Kumar's nits done.
>>
>> Thanks Kumar.
>>
>> webrev-06
>>   102             // get the PID from the env var we set for the JVM
>>   103             String envVarPid = null;
>>   104             for (String line : tr.testOutput) {
>>   105                 if (line.contains(envVarPidString)) {
>>   106                     int sindex = envVarPidString.length();
>>   107                     envVarPid = line.substring(sindex);
>>   108                     break;
>>   109                 }
>>   110             }
>>   111             // did we find envVarPid?
>>   112             if (envVarPid == null) {
>>   113                 System.out.println(tr);
>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   115             }
>>
>>
>> webrev-05
>>   102             // get the PID from the env var we set for the JVM
>>   103             haveLauncherPid = false;
>>   104             String envVarPid = null;
>>   105             for (String line : tr.testOutput) {
>>   106                 int index;
>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>   108                     int sindex = envVarPidString.length();
>>   109                     envVarPid = line.substring(sindex);
>>   110                     haveLauncherPid = true;
>>   111                     break;
>>   112                 }
>>   113             }
>>   114             // did we find envVarPid?
>>   115             if (!haveLauncherPid) {
>>   116                 System.out.println(tr);
>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   118             }
>>
>>
>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>
>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>> Explained below.
>>>
>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>
>>> 105 : DONE
>>> 146: DONE
>>> 168: DONE
>>>
>>> 106: Your suggestion was the way I had originally coded it for 
>>> Linux.  However
>>>          on Windows/Cygwin, the code will not compile  There is some 
>>> interaction
>>>          with the doExec() preceeding it and the fact that it is a 
>>> varlist.  This coding
>>>          was the simplest workaround.
>>>
>>> Thanks for the nits Kumar.
>>>
>>>
>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>> Neil,
>>>>
>>>> Some nits:
>>>>
>>>> TestSpecialArgs.java:
>>>>
>>>> extra space
>>>> 105 for ( String line : tr.testOutput) {
>>>>
>>>>
>>>>
>>>> This is very C'ish, I suggest.
>>>>  -106                 int index;
>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>> >= 0) {
>>>>
>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>  +107                 if (index >= 0) {
>>>>
>>>>
>>>> Needs space
>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>
>>>> Needs space
>>>>
>>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> "+NMT_Option_Value)) {
>>>> +168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> " + NMT_Option_Value)) {
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>
>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>
>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>
>>>>> Changes are:
>>>>>
>>>>>   1) java.c
>>>>>         a) add free(envName) line 1063
>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 
>>>>> 1056
>>>>>
>>>>> Thanks
>>>>>
>>>>> -neil
>>>>>
>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>> Neil,
>>>>>>
>>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>>> that one.
>>>>>> Are you going to post another iteration ?
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>
>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>> I'll use the JLI wrapper.
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>
>>>>>>>> -Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>
>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>> are non-null.
>>>>>>>>>
>>>>>>>>> -neil
>>>>>>>>>
>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>> Neil,
>>>>>>>>>>
>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>
>>>>>>>>>> java.c:
>>>>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>>>>> code analyzers will complain.
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>
>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>
>>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> -neil
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>



From kumar.x.srinivasan at oracle.com  Wed Jun 25 20:48:11 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Jun 2014 13:48:11 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AB1D68.6000204@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
Message-ID: <53AB358B.8090104@oracle.com>

Hi Zhengyu,

You are right then this needs to happen before LoadJavaVM, I think that 
is where it was initially,
but I had Neil move it to ParseArguments where all the arguments are parsed.

Also it is probably best that you push this changeset when it is 
complete,  into hotspot-dev,  along
with the JVM changes.

Kumar



On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
> Hi Neil,
>
> I tried out this patch with my hotspot, it does not work.
>
> The reason is that, the environment variable is setup too late, it has 
> to be set before it launches JavaVM (before calling LoadJavaVM()) method.
>
> Thanks,
>
> -Zhengyu
>
> On 6/25/2014 1:58 PM, Neil Toda wrote:
>> Sorry.  One more webrev .. 06
>>
>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>
>> Kumar's nit was correct and in fact index was old and should have 
>> been removed
>> allowing .contains member to be used instead of .indexOf.  So cleaned 
>> up a bit more
>> as can be seen below.  Other of Kumar's nits done.
>>
>> Thanks Kumar.
>>
>> webrev-06
>>   102             // get the PID from the env var we set for the JVM
>>   103             String envVarPid = null;
>>   104             for (String line : tr.testOutput) {
>>   105                 if (line.contains(envVarPidString)) {
>>   106                     int sindex = envVarPidString.length();
>>   107                     envVarPid = line.substring(sindex);
>>   108                     break;
>>   109                 }
>>   110             }
>>   111             // did we find envVarPid?
>>   112             if (envVarPid == null) {
>>   113                 System.out.println(tr);
>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   115             }
>>
>>
>> webrev-05
>>   102             // get the PID from the env var we set for the JVM
>>   103             haveLauncherPid = false;
>>   104             String envVarPid = null;
>>   105             for (String line : tr.testOutput) {
>>   106                 int index;
>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>   108                     int sindex = envVarPidString.length();
>>   109                     envVarPid = line.substring(sindex);
>>   110                     haveLauncherPid = true;
>>   111                     break;
>>   112                 }
>>   113             }
>>   114             // did we find envVarPid?
>>   115             if (!haveLauncherPid) {
>>   116                 System.out.println(tr);
>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   118             }
>>
>>
>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>
>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>> Explained below.
>>>
>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>
>>> 105 : DONE
>>> 146: DONE
>>> 168: DONE
>>>
>>> 106: Your suggestion was the way I had originally coded it for 
>>> Linux.  However
>>>          on Windows/Cygwin, the code will not compile  There is some 
>>> interaction
>>>          with the doExec() preceeding it and the fact that it is a 
>>> varlist.  This coding
>>>          was the simplest workaround.
>>>
>>> Thanks for the nits Kumar.
>>>
>>>
>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>> Neil,
>>>>
>>>> Some nits:
>>>>
>>>> TestSpecialArgs.java:
>>>>
>>>> extra space
>>>> 105 for ( String line : tr.testOutput) {
>>>>
>>>>
>>>>
>>>> This is very C'ish, I suggest.
>>>>  -106                 int index;
>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>> >= 0) {
>>>>
>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>  +107                 if (index >= 0) {
>>>>
>>>>
>>>> Needs space
>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>
>>>> Needs space
>>>>
>>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> "+NMT_Option_Value)) {
>>>> +168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> " + NMT_Option_Value)) {
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>
>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>
>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>
>>>>> Changes are:
>>>>>
>>>>>   1) java.c
>>>>>         a) add free(envName) line 1063
>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 
>>>>> 1056
>>>>>
>>>>> Thanks
>>>>>
>>>>> -neil
>>>>>
>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>> Neil,
>>>>>>
>>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>>> that one.
>>>>>> Are you going to post another iteration ?
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>
>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>> I'll use the JLI wrapper.
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>
>>>>>>>> -Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>
>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>> are non-null.
>>>>>>>>>
>>>>>>>>> -neil
>>>>>>>>>
>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>> Neil,
>>>>>>>>>>
>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>
>>>>>>>>>> java.c:
>>>>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>>>>> code analyzers will complain.
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>
>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>
>>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> -neil
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>



From roger.riggs at oracle.com  Wed Jun 25 21:52:56 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 25 Jun 2014 17:52:56 -0400
Subject: Process trees and termination
Message-ID: <53AB44B8.2080601@oracle.com>

Hi,

The next step for JEP 102, Process API Updates is to provide an API to
enumerate the hierarchy of processes and to be able to terminate a 
process tree.

This draft javadoc update [1] includes:
  - ProcessHandle class to provide handles to processes, their children,
     parent, process id and liveness
  - Process extends ProcessHandle and inherits the new behaviors
  - Method destroyProcessTree() terminates a process tree

Additional functions related to termination and information about processes
will be added in a later update.

Comments appreciated, Roger

[1] http://cr.openjdk.java.net/~rriggs/ph-apidraft/


From david.lloyd at redhat.com  Wed Jun 25 22:05:58 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Jun 2014 17:05:58 -0500
Subject: Process trees and termination
In-Reply-To: <53AB44B8.2080601@oracle.com>
References: <53AB44B8.2080601@oracle.com>
Message-ID: <53AB47C6.30305@redhat.com>

On 06/25/2014 04:52 PM, roger riggs wrote:
> Hi,
>
> The next step for JEP 102, Process API Updates is to provide an API to
> enumerate the hierarchy of processes and to be able to terminate a
> process tree.
>
> This draft javadoc update [1] includes:
>   - ProcessHandle class to provide handles to processes, their children,
>      parent, process id and liveness
>   - Process extends ProcessHandle and inherits the new behaviors
>   - Method destroyProcessTree() terminates a process tree
>
> Additional functions related to termination and information about processes
> will be added in a later update.
>
> Comments appreciated, Roger

I still have a not-great feeling about the lack of atomicity inherent in 
these operations.  At least when you're dealing with direct child 
processes (on UNIX-likes), there is some measure of control, in that a 
process is zombified until reaped by wait() and friends.

Also I have a much higher level of concern about destroyProcessTree(), 
which I don't think has any place in this API.  Control of any process 
belongs solely with their parent (or PID 1), in my opinion.

Those concerns aside, what about making the allChildren() and 
allProcesses() methods lazy in some way?

-- 
- DML


From peter.levart at gmail.com  Thu Jun 26 08:55:09 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Jun 2014 10:55:09 +0200
Subject: Process trees and termination
In-Reply-To: <53AB47C6.30305@redhat.com>
References: <53AB44B8.2080601@oracle.com> <53AB47C6.30305@redhat.com>
Message-ID: <53ABDFED.3070103@gmail.com>

On 06/26/2014 12:05 AM, David M. Lloyd wrote:
> On 06/25/2014 04:52 PM, roger riggs wrote:
>> Hi,
>>
>> The next step for JEP 102, Process API Updates is to provide an API to
>> enumerate the hierarchy of processes and to be able to terminate a
>> process tree.
>>
>> This draft javadoc update [1] 
>> includes:
>>   - ProcessHandle class to provide handles to processes, their children,
>>      parent, process id and liveness
>>   - Process extends ProcessHandle and inherits the new behaviors
>>   - Method destroyProcessTree() terminates a process tree
>>
>> Additional functions related to termination and information about 
>> processes
>> will be added in a later update.
>>
>> Comments appreciated, Roger
>
> I still have a not-great feeling about the lack of atomicity inherent 
> in these operations.  At least when you're dealing with direct child 
> processes (on UNIX-likes), there is some measure of control, in that a 
> process is zombified until reaped by wait() and friends.
>
> Also I have a much higher level of concern about destroyProcessTree(), 
> which I don't think has any place in this API.  Control of any process 
> belongs solely with their parent (or PID 1), in my opinion.
>
> Those concerns aside, what about making the allChildren() and 
> allProcesses() methods lazy in some way?
>
Hi Roger, David,

- Will there be a guarantee that ProcessHandle objects returned from 
factory methods: |current()| 
, 
|of(long)| 
, 
|children()| 
, 
|allChildren()| 
, 
|getParent()| 
 
and |allProcesses()| 
 
representing those processes that were started by ProcessBuilder API are 
actually the same Process objects that were returned from the 
ProcessBuilder API? The Process object can be viewed as a proxy of an OS 
process so as long as we have a reference to it, we can obtain it's exit 
status even though it has already been waited for (reaped) and we can 
reliably terminate it, because Process object is tracking the state of 
OS process and only forwards the termination request if it knows the OS 
process is still alive or zombified and so minimizes the probability to 
kill wrong process that just reused the same pid.

The following expression: ProcessHandle.current().children() would 
therefore return just canonicalized Process objects (unless some native 
code embedded in the JVM process started sub-processes too).

If returning canonicalized Process objects from factory methods is not 
desirable (some part of the program could mess with Input/Output streams 
of Process-es it did not have access to before), then perhaps 
ProcessHandle representing a process created by ProcessBuilder API would 
just have an internal private reference to the Process object to which 
it would forward method invocations...


- There is an inconsistency in the javadoc for 
ProcessHandle.destroyForcibly():

public abstractProcessHandle    destroyForcibly()

Kills the process. The process represented by this |ProcessHandle| 
object is forcibly terminated. If the process is not alive no action is 
taken.

Note: The process may not terminate immediately. i.e. |isAlive()| may 
return true for a brief period after |destroyForcibly()| is called. This 
method may be chained to |waitFor()| if needed.


...the method has a co-variant return type and there's no waitFor() 
method on the ProcessHandle. Why not? If ProcessHandle is a (or 
delegates to) Process then it could use it's waitFor(), if it is just a 
"foreign" ProcessHandle it could be implemented as a poll-ing wait for 
the isAlive() to return false...


- Will there not be any destroyGracefully() method (which would be a 
no-op on platforms not supporting graceful termination)?


- Depending on the OS facilities used to obtain process information 
(/proc/ ?) there might be some other attributes already available. 
The name of a process would be nice to have.


Regards, Peter



From chris.hegarty at oracle.com  Thu Jun 26 09:58:30 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 26 Jun 2014 10:58:30 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
Message-ID: 

Otavio,

I skimmed over the patches and they look ok to me. I think they would be suitable for inclusion in jdk9/dev.

-Chris.

P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who may be able to help get his in.

On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana  wrote:

> Reason: The Long class has cache and using it, will save memory and will
> faster than using create new instance of Long.
> 
> webrev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
> 
> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> -- 
> 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  Thu Jun 26 10:15:17 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 26 Jun 2014 07:15:17 -0300
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
Message-ID: 

Thank you Chris.
I don't know if is better, but I did with all wrapper in this path.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027285.html

But if will better, I can split each wrapper as path.


On Thu, Jun 26, 2014 at 6:58 AM, Chris Hegarty 
wrote:

> Otavio,
>
> I skimmed over the patches and they look ok to me. I think they would be
> suitable for inclusion in jdk9/dev.
>
> -Chris.
>
> P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who
> may be able to help get his in.
>
> On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana 
> wrote:
>
> > Reason: The Long class has cache and using it, will save memory and will
> > faster than using create new instance of Long.
> >
> > webrev:
> > https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
> >
> > similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> > --
> > 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 mike at saxonica.com  Thu Jun 26 11:02:04 2014
From: mike at saxonica.com (Michael Kay)
Date: Thu, 26 Jun 2014 12:02:04 +0100
Subject: JDK9 project: XML/JAXP Approachability / Ease of Use
Message-ID: <9645C61E-B815-45CB-A7A4-49B10948B43D@saxonica.com>

Here are some quick thoughts about the state of XML support in the JDK:

1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one has been fixing the bugs. It needs to be replaced with a more recent version of Apache Xerces if that hasn't already been done.

2. DOM. From a usability perspective DOM is awful. There are much better alternatives available, for example JDOM2 or XOM. The only reason anyone uses DOM rather than these alternatives is either (a) because they aren't aware of the alternatives, or (b) because of some kind of perception that DOM is "more standard". If we want to address the usability of XML processing in the JDK then an alternative/replacement for DOM would seem to be a high priority. If someone wants a summary of the badness of DOM then I'll address that in a separate thread.

3. JAXP factory mechanism. While the goal of allowing multiple implementations of core interfaces such as DOM, XPath, and XSLT is laudable, the current mechanism has many failings. It's hideously expensive because of the classpath search; it's fragile because the APIs are so weakly defined that the implemntations aren't 100% interoperable (for example you have no way of knowing whether the XPath factory will give you an XPath 1.0 or 2.0 processor, and no way of finding out which you have got); so in practice we see lots of problems where applications get a processor that doesn't work as the applications expects, just because it happens to be lying around on the classpath.

4. XQJ. The XQJ spec never found its way into the JDK, so there is no out-of-the-box XQuery support. The licensing terms for XQJ are also unsatisfactory (the license doesn't allow modification, which purists say means it's not a true open source license).

5. General lack of integration across the whole XML scene, e.g, separate and potentially incompatible factories for different services; a lack of clarity as to whether the XPath API is supposed to handle object models other than DOM, etc; weak typing of interfaces such as setParameter() in order to accomodate variation, at the cost of interoperability.

6. Failure to keep up to date with the W3C specs; if you want support for recent versions of XSLT or XPath then you need to go to third-party products. Even at the DOM level, namespaces are a bolt-on optional extra rather than an intrinsic capability.

7. Inconsistent policy on concrete classes versus interfaces.

Is this project attempting to address the fundamental problems, or only to paper over the cracks?


> We're planning on a jaxp project to address usability issues in the JAXP 
> API. One of the complaints about the JAXP API is the number of lines of 
> code that are needed to implement a simple task. Tasks that should take 
> one or two lines often take ten or twelve lines instead.


Michael Kay
Saxonica
mike at saxonica.com
+44 (0118) 946 5893





From Alan.Bateman at oracle.com  Thu Jun 26 11:16:53 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Jun 2014 12:16:53 +0100
Subject: JDK9 project: XML/JAXP Approachability / Ease of Use
In-Reply-To: <9645C61E-B815-45CB-A7A4-49B10948B43D@saxonica.com>
References: <9645C61E-B815-45CB-A7A4-49B10948B43D@saxonica.com>
Message-ID: <53AC0125.6080708@oracle.com>

On 26/06/2014 12:02, Michael Kay wrote:
> Here are some quick thoughts about the state of XML support in the JDK:
>
> 1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one has been fixing the bugs. It needs to be replaced with a more recent version of Apache Xerces if that hasn't already been done.
The discussion on updating Xerces is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024805.html

-Alan.


From paul.sandoz at oracle.com  Thu Jun 26 13:15:28 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Jun 2014 15:15:28 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
Message-ID: <9D2AA1E5-FAFB-4424-B694-29060C1E2C70@oracle.com>


On Jun 26, 2014, at 11:58 AM, Chris Hegarty  wrote:

> Otavio,
> 
> I skimmed over the patches and they look ok to me. I think they would be suitable for inclusion in jdk9/dev.

Seems fine to me (pending a full test run). 

Just a syntax niggle in the following, too many brackets:

+++ new/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java	2014-06-14 10:16:02.486298421 -0300
@@ -544,7 +544,7 @@
             }
 
             // convert seconds to milliseconds for time comparison
-            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
+            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
             if (currencyPeriod < 0) {
                 /* if currencyTimeLimit is -1 then value is never cached */
                 returnCachedValue = false;
@@ -580,7 +580,7 @@
                 if (tStamp == null)
                     tStamp = "0";
 
-                long lastTime = (new Long(tStamp)).longValue();
+                long lastTime = (Long.valueOf(tStamp)).longValue();


Paul.



From andrej.golovnin at gmail.com  Thu Jun 26 13:29:35 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Thu, 26 Jun 2014 15:29:35 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: <9D2AA1E5-FAFB-4424-B694-29060C1E2C70@oracle.com>
References: 
	
	<9D2AA1E5-FAFB-4424-B694-29060C1E2C70@oracle.com>
Message-ID: 

Hi Paul,

Seems fine to me (pending a full test run).
>
> Just a syntax niggle in the following, too many brackets:
>
> +++
> new/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
> 2014-06-14 10:16:02.486298421 -0300
> @@ -544,7 +544,7 @@
>              }
>
>              // convert seconds to milliseconds for time comparison
> -            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
> +            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
>              if (currencyPeriod < 0) {
>                  /* if currencyTimeLimit is -1 then value is never cached
> */
>                  returnCachedValue = false;
> @@ -580,7 +580,7 @@
>                  if (tStamp == null)
>                      tStamp = "0";
>
> -                long lastTime = (new Long(tStamp)).longValue();
> +                long lastTime = (Long.valueOf(tStamp)).longValue();
>
>
> Paul.
>
>
Wouldn't it be better to use here Long.parseLong(String)?
Long.valueOf(String) would always create a new object here, as expTime and
tStamp represents the time and they are never in the range [-128;127].

Best regards,
Andrej Golovnin


From pbenedict at apache.org  Thu Jun 26 13:43:28 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 26 Jun 2014 08:43:28 -0500
Subject: Process trees and termination
In-Reply-To: <53AB44B8.2080601@oracle.com>
References: <53AB44B8.2080601@oracle.com>
Message-ID: 

I have a question on the way this is modeled. By introducing a superclass,
Process becomes a type of ProcessHandle. That doesn't seem right to me. I
expect a Process to have a handle (not be one). Also I think these
operations may make more sense as an interface.


Cheers,
Paul


On Wed, Jun 25, 2014 at 4:52 PM, roger riggs  wrote:

> Hi,
>
> The next step for JEP 102, Process API Updates is to provide an API to
> enumerate the hierarchy of processes and to be able to terminate a process
> tree.
>
> This draft javadoc update [1]
> includes:
>  - ProcessHandle class to provide handles to processes, their children,
>     parent, process id and liveness
>  - Process extends ProcessHandle and inherits the new behaviors
>  - Method destroyProcessTree() terminates a process tree
>
> Additional functions related to termination and information about processes
> will be added in a later update.
>
> Comments appreciated, Roger
>
> [1] http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>


From paul.sandoz at oracle.com  Thu Jun 26 13:59:35 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Jun 2014 15:59:35 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	<9D2AA1E5-FAFB-4424-B694-29060C1E2C70@oracle.com>
	
Message-ID: 


On Jun 26, 2014, at 3:29 PM, Andrej Golovnin  wrote:

> Hi Paul,
> 
> Seems fine to me (pending a full test run).
> 
> Just a syntax niggle in the following, too many brackets:
> 
> +++ new/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java   2014-06-14 10:16:02.486298421 -0300
> @@ -544,7 +544,7 @@
>              }
> 
>              // convert seconds to milliseconds for time comparison
> -            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
> +            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
>              if (currencyPeriod < 0) {
>                  /* if currencyTimeLimit is -1 then value is never cached */
>                  returnCachedValue = false;
> @@ -580,7 +580,7 @@
>                  if (tStamp == null)
>                      tStamp = "0";
> 
> -                long lastTime = (new Long(tStamp)).longValue();
> +                long lastTime = (Long.valueOf(tStamp)).longValue();
> 
> 
> Paul.
> 
> 
> Wouldn't it be better to use here Long.parseLong(String)? Long.valueOf(String) would always create a new object here, as expTime and tStamp represents the time and they are never in the range [-128;127].
> 

Well spotted, there is no need to box at all.

There are a couple of other cases too (and probably more, need to look more carefully):

--- old/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java	2014-06-14 10:15:58.646298533 -0300
+++ new/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java	2014-06-14 10:15:58.514298537 -0300
@@ -87,7 +87,7 @@
      *                  represented as a long.
      */
     public UnixNumericUserPrincipal(long name) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();   <--- this.name = Long.toString(name);
     }
 
     /**
@@ -113,7 +113,7 @@
      *          UnixNumericUserPrincipal as a long.
      */
     public long longValue() {
-        return ((new Long(name)).longValue());
+        return Long.valueOf(name);  <--- Long.parseLong(name);
     }

Paul.


From roger.riggs at oracle.com  Thu Jun 26 14:02:35 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 26 Jun 2014 10:02:35 -0400
Subject: Process trees and termination
In-Reply-To: <53AB47C6.30305@redhat.com>
References: <53AB44B8.2080601@oracle.com> <53AB47C6.30305@redhat.com>
Message-ID: <53AC27FB.4030708@oracle.com>

Hi David,

On 6/25/2014 6:05 PM, David M. Lloyd wrote:
> On 06/25/2014 04:52 PM, roger riggs wrote:
>> Hi,
>>
>> The next step for JEP 102, Process API Updates is to provide an API to
>> enumerate the hierarchy of processes and to be able to terminate a
>> process tree.
>>
>> This draft javadoc update [1] 
>> includes:
>>   - ProcessHandle class to provide handles to processes, their children,
>>      parent, process id and liveness
>>   - Process extends ProcessHandle and inherits the new behaviors
>>   - Method destroyProcessTree() terminates a process tree
>>
>> Additional functions related to termination and information about 
>> processes
>> will be added in a later update.
>>
>> Comments appreciated, Roger
>
> I still have a not-great feeling about the lack of atomicity inherent 
> in these operations.  At least when you're dealing with direct child 
> processes (on UNIX-likes), there is some measure of control, in that a 
> process is zombified until reaped by wait() and friends.
The forcible termination implementation sends a kill signal and relies 
on the OS to finish the job.
Perhaps the semantics need to be clearer that the method does not ensure 
the
process has been cleaned up. The isAlive can be used to verify.

>
> Also I have a much higher level of concern about destroyProcessTree(), 
> which I don't think has any place in this API.  Control of any process 
> belongs solely with their parent (or PID 1), in my opinion.
That is the preferable situation as raised in earlier threads.
However, in practice, if the parent dies, it is not always the case that 
PID 1
reaps them and they hang around.

>
> Those concerns aside, what about making the allChildren() and 
> allProcesses() methods lazy in some way?
Either using the old Enumeration pattern or perhaps some kind of Queue 
that returned
instances until it could not find any new unique processes.
They might be an issue with termination if processes were being created
faster than the application was processing them.
A bit pathological case perhaps but the application would not be aware
it was not keeping up and might never finish.

The snapshot of processes from the OS is pretty clean in a single native 
call.

With the snapshot approach the application could re-do the snapshot and
know there were new processes.

Thanks, Roger






From roger.riggs at oracle.com  Thu Jun 26 14:23:53 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 26 Jun 2014 10:23:53 -0400
Subject: Process trees and termination
In-Reply-To: <53ABDFED.3070103@gmail.com>
References: <53AB44B8.2080601@oracle.com> <53AB47C6.30305@redhat.com>
	<53ABDFED.3070103@gmail.com>
Message-ID: <53AC2CF9.8080300@oracle.com>

Hi Peter,

Thanks for the comments...

On 6/26/2014 4:55 AM, Peter Levart wrote:
> On 06/26/2014 12:05 AM, David M. Lloyd wrote:
>> On 06/25/2014 04:52 PM, roger riggs wrote:
>>> Hi,
>>>
>>> The next step for JEP 102, Process API Updates is to provide an API to
>>> enumerate the hierarchy of processes and to be able to terminate a
>>> process tree.
>>>
>>> This draft javadoc update [1] 
>>> includes:
>>>   - ProcessHandle class to provide handles to processes, their 
>>> children,
>>>      parent, process id and liveness
>>>   - Process extends ProcessHandle and inherits the new behaviors
>>>   - Method destroyProcessTree() terminates a process tree
>>>
>>> Additional functions related to termination and information about 
>>> processes
>>> will be added in a later update.
>>>
>>> Comments appreciated, Roger
>>
>> I still have a not-great feeling about the lack of atomicity inherent 
>> in these operations.  At least when you're dealing with direct child 
>> processes (on UNIX-likes), there is some measure of control, in that 
>> a process is zombified until reaped by wait() and friends.
>>
>> Also I have a much higher level of concern about 
>> destroyProcessTree(), which I don't think has any place in this API.  
>> Control of any process belongs solely with their parent (or PID 1), 
>> in my opinion.
>>
>> Those concerns aside, what about making the allChildren() and 
>> allProcesses() methods lazy in some way?
>>
> Hi Roger, David,
>
> - Will there be a guarantee that ProcessHandle objects returned from 
> factory methods: |current()| 
> , 
> |of(long)| 
> , 
> |children()| 
> , 
> |allChildren()| 
> , 
> |getParent()| 
>  
> and |allProcesses()| 
>  
> representing those processes that were started by ProcessBuilder API 
> are actually the same Process objects that were returned from the 
> ProcessBuilder API? The Process object can be viewed as a proxy of an 
> OS process so as long as we have a reference to it, we can obtain it's 
> exit status even though it has already been waited for (reaped) and we 
> can reliably terminate it, because Process object is tracking the 
> state of OS process and only forwards the termination request if it 
> knows the OS process is still alive or zombified and so minimizes the 
> probability to kill wrong process that just reused the same pid.
The initial design does not have them returning Process instances.
Process instances are capabilities and their reference accessibility is 
currently controlled
by the code that created the Process.  If ProcessHandle gave out those 
Process instances
it would break existing encapsulation.

>
> The following expression: ProcessHandle.current().children() would 
> therefore return just canonicalized Process objects (unless some 
> native code embedded in the JVM process started sub-processes too).
>
> If returning canonicalized Process objects from factory methods is not 
> desirable (some part of the program could mess with Input/Output 
> streams of Process-es it did not have access to before), then perhaps 
> ProcessHandle representing a process created by ProcessBuilder API 
> would just have an internal private reference to the Process object to 
> which it would forward method invocations...
yes, that would break encapsulation; not desirable and potential 
security issue.

And yes, the implementation can maintain the association and delegate 
the behavior.

It does not/should not make any difference in practice.
Regardless of whether the TERM or KILL signal is delivered by an external
process or via the ProcessHandle API, the Process mechanics should be 
the same.
An application using the Process should see the same behavior, cleanup
and termination, in either case.
>
>
> - There is an inconsistency in the javadoc for 
> ProcessHandle.destroyForcibly():
>
> public abstractProcessHandle    destroyForcibly()
> Kills the process. The process represented by this |ProcessHandle| 
> object is forcibly terminated. If the process is not alive no action 
> is taken.
>
> Note: The process may not terminate immediately. i.e. |isAlive()| may 
> return true for a brief period after |destroyForcibly()| is called. 
> This method may be chained to |waitFor()| if needed.
>
>
> ...the method has a co-variant return type and there's no waitFor() 
> method on the ProcessHandle. Why not? If ProcessHandle is a (or 
> delegates to) Process then it could use it's waitFor(), if it is just 
> a "foreign" ProcessHandle it could be implemented as a poll-ing wait 
> for the isAlive() to return false...
>
I plan to address waitFor of ProcessHandle a bit later due to the 
complexities
previously discussed for non-Process processes and when I can spend more 
time
on the implementations and alternatives.
Also requested are either Future style returns or lambda enabled onExit 
behavior.

>
> - Will there not be any destroyGracefully() method (which would be a 
> no-op on platforms not supporting graceful termination)?
An alternative is to add a method to report whether destroy is graceful 
or not.
Either way an application needs to be aware of whether it worked or not so
it can take some alternate action.

>
>
> - Depending on the OS facilities used to obtain process information 
> (/proc/ ?) there might be some other attributes already 
> available. The name of a process would be nice to have.
yep, also on the list and it builds naturally on top of ProcessHandle
when the relationship between ProcessHandle and Process is settled.

Thanks, Roger

>
>
> Regards, Peter
>



From roger.riggs at oracle.com  Thu Jun 26 14:33:23 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 26 Jun 2014 10:33:23 -0400
Subject: Process trees and termination
In-Reply-To: 
References: <53AB44B8.2080601@oracle.com>
	
Message-ID: <53AC2F33.50701@oracle.com>

Hi Paul,

Whether an interface or class, it is desirable that Process have the new
capabilities of iterating over children and destroying the tree and other
possible additions retrieving information about the process like the 
process name,
start time, etc.  If Process had a ProcessHandle then the operations would
less usable such as p.getProcessHandle().allChildren() or similar.

 From a security point of view, it is useful to know that ProcessHandle 
is concrete
and not some arbitrary object hiding behind the interface.

Roger

On 6/26/2014 9:43 AM, Paul Benedict wrote:
> I have a question on the way this is modeled. By introducing a 
> superclass, Process becomes a type of ProcessHandle. That doesn't seem 
> right to me. I expect a Process to have a handle (not be one). Also I 
> think these operations may make more sense as an interface.
>
>
> Cheers,
> Paul
>
>
> On Wed, Jun 25, 2014 at 4:52 PM, roger riggs  > wrote:
>
>     Hi,
>
>     The next step for JEP 102, Process API Updates is to provide an API to
>     enumerate the hierarchy of processes and to be able to terminate a
>     process tree.
>
>     This draft javadoc update [1]
>     includes:
>      - ProcessHandle class to provide handles to processes, their
>     children,
>         parent, process id and liveness
>      - Process extends ProcessHandle and inherits the new behaviors
>      - Method destroyProcessTree() terminates a process tree
>
>     Additional functions related to termination and information about
>     processes
>     will be added in a later update.
>
>     Comments appreciated, Roger
>
>     [1] http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>     
>
>



From chris.hegarty at oracle.com  Thu Jun 26 15:07:52 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 26 Jun 2014 16:07:52 +0100
Subject: Character, Byte, Short valueOf instead of new instance
In-Reply-To: 
References: 
Message-ID: 

Otavio,

I scanner the patches and they mainly look fine to me. Just a minor issue, as per the Long thread.

diff -r d02b062bc827 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
--- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java	Fri Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java	Sat Jun 14 13:33:29 2014 -0300
@@ -379,7 +379,7 @@
         // used for substring comparisons (where proto has "*" wildcards
         private boolean substringMatch(String proto, String value) {
             // simple case 1: "*" means attribute presence is being tested
-            if(proto.equals(new Character(WILDCARD_TOKEN).toString())) {
+            if(proto.equals(Character.valueOf(WILDCARD_TOKEN).toString())) {    // << Character.toString(WILDCARD_TOKEN)
                 if(debug) {System.out.println("simple presence assertion");}
                 return true;
             }

-Chris.

On 14 Jun 2014, at 17:38, Ot?vio Gon?alves de Santana  wrote:

> Reason: The Character, Byte, Short classes have cache and using it, will
> save memory and will faster than using create new instance.
> 
> webrev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/byte_short_character_value_of.zip
> 
> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> 
> -- 
> 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 neil.toda at oracle.com  Thu Jun 26 15:12:47 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 26 Jun 2014 08:12:47 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AB1D68.6000204@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
Message-ID: <53AC386F.3090509@oracle.com>


Zhengyu

Earlier creation of the environmental variable.

http://cr.openjdk.java.net/~ntoda/8042469/webrev-07/

The new webrev [07] places the new code in the function SetJvmEnvironment()

===
. JLI_Launch()
   . InitLauncher()
   . CreateExecutionEnvironment()
     . CheckJvmType()
   . SetJvmEnvironment()
   . LoadJavaVM()
   ...
   . ParseArguments()
===

Kumar and I settled on this organization last night, moving the code
out of ParseArguments() into its own function.

All previous review comments for the launcher and test are included in this
revision.

Thanks

-neil


On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
> Hi Neil,
>
> I tried out this patch with my hotspot, it does not work.
>
> The reason is that, the environment variable is setup too late, it has 
> to be set before it launches JavaVM (before calling LoadJavaVM()) method.
>
> Thanks,
>
> -Zhengyu
>
> On 6/25/2014 1:58 PM, Neil Toda wrote:
>> Sorry.  One more webrev .. 06
>>
>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>
>> Kumar's nit was correct and in fact index was old and should have 
>> been removed
>> allowing .contains member to be used instead of .indexOf.  So cleaned 
>> up a bit more
>> as can be seen below.  Other of Kumar's nits done.
>>
>> Thanks Kumar.
>>
>> webrev-06
>>   102             // get the PID from the env var we set for the JVM
>>   103             String envVarPid = null;
>>   104             for (String line : tr.testOutput) {
>>   105                 if (line.contains(envVarPidString)) {
>>   106                     int sindex = envVarPidString.length();
>>   107                     envVarPid = line.substring(sindex);
>>   108                     break;
>>   109                 }
>>   110             }
>>   111             // did we find envVarPid?
>>   112             if (envVarPid == null) {
>>   113                 System.out.println(tr);
>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   115             }
>>
>>
>> webrev-05
>>   102             // get the PID from the env var we set for the JVM
>>   103             haveLauncherPid = false;
>>   104             String envVarPid = null;
>>   105             for (String line : tr.testOutput) {
>>   106                 int index;
>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>   108                     int sindex = envVarPidString.length();
>>   109                     envVarPid = line.substring(sindex);
>>   110                     haveLauncherPid = true;
>>   111                     break;
>>   112                 }
>>   113             }
>>   114             // did we find envVarPid?
>>   115             if (!haveLauncherPid) {
>>   116                 System.out.println(tr);
>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>   118             }
>>
>>
>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>
>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>> Explained below.
>>>
>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>
>>> 105 : DONE
>>> 146: DONE
>>> 168: DONE
>>>
>>> 106: Your suggestion was the way I had originally coded it for 
>>> Linux.  However
>>>          on Windows/Cygwin, the code will not compile  There is some 
>>> interaction
>>>          with the doExec() preceeding it and the fact that it is a 
>>> varlist.  This coding
>>>          was the simplest workaround.
>>>
>>> Thanks for the nits Kumar.
>>>
>>>
>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>> Neil,
>>>>
>>>> Some nits:
>>>>
>>>> TestSpecialArgs.java:
>>>>
>>>> extra space
>>>> 105 for ( String line : tr.testOutput) {
>>>>
>>>>
>>>>
>>>> This is very C'ish, I suggest.
>>>>  -106                 int index;
>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>> >= 0) {
>>>>
>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>  +107                 if (index >= 0) {
>>>>
>>>>
>>>> Needs space
>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>
>>>> Needs space
>>>>
>>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> "+NMT_Option_Value)) {
>>>> +168             if (!tr.contains("NativeMemoryTracking: got value 
>>>> " + NMT_Option_Value)) {
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>
>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>
>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>
>>>>> Changes are:
>>>>>
>>>>>   1) java.c
>>>>>         a) add free(envName) line 1063
>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 
>>>>> 1056
>>>>>
>>>>> Thanks
>>>>>
>>>>> -neil
>>>>>
>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>> Neil,
>>>>>>
>>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>>> that one.
>>>>>> Are you going to post another iteration ?
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>
>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>> I'll use the JLI wrapper.
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>
>>>>>>>> -Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>
>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>> are non-null.
>>>>>>>>>
>>>>>>>>> -neil
>>>>>>>>>
>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>> Neil,
>>>>>>>>>>
>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>
>>>>>>>>>> java.c:
>>>>>>>>>>   Did not check return values of malloc(), I wonder if source 
>>>>>>>>>> code analyzers will complain.
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>
>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>
>>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> -neil
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>



From claes.redestad at oracle.com  Thu Jun 26 16:53:27 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 26 Jun 2014 18:53:27 +0200
Subject: RFR [9] 8041972: Add improved parse/format methods for
	Long/Integer
In-Reply-To: <39373F79-DC28-4A51-B617-680C6C508538@oracle.com>
References: <539CCE6D.6040207@oracle.com>	<539D8821.3070808@univ-mlv.fr>	<539D91A0.9050901@oracle.com>	<539E1CB4.2050502@oracle.com>	<539F4A6A.5020002@oracle.com>	<539F4FCE.9080903@oracle.com>	<53A04EE7.6090309@oracle.com>	<53A06224.1040600@oracle.com>
	<53A32043.7070008@oracle.com>
	<39373F79-DC28-4A51-B617-680C6C508538@oracle.com>
Message-ID: <53AC5007.30603@oracle.com>

On 06/25/2014 06:43 PM, Paul Sandoz wrote:
> On Jun 19, 2014, at 7:39 PM, Claes Redestad  wrote:
>> Hi,
>>
>> an updated webrev with reworked, public methods is available here:
>> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
>>
>> Reviews are yet again appreciated!
>>
> I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.)

Agreed. Using s.getClass() was necessitated to retain performance using 
default compiler (-XX:+TieredCompilation) in the microbenchmarks I've 
been using, and going back to testing with C1 (via means of 
-XX:TieredStartAtLevel=1-3), it's apparent that the patch can cause a 
regression with the client compiler that I hadn't checked.It even looks 
like C2 alone (-XX:-TieredCompilation) suffers slightly.

Changing to Objects.requireNonNull doesn't seem to make things better, 
though. Rather the regression seem to be due to C1 (and in some ways 
even C2) not dealing very well with the increased degrees of freedoms in 
the new methods, so I'm currently considering splitting apart the 
implementations to keep the old implementations of parseX(String[, int]) 
untouched while duplicating some code to build the new methods. Ugly, 
but I guess it's anecessary evil here.

> Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException.

Consider Integer.parseInt(s.substring(1)) and Integer.parseInt(s, 10, 
1): the first would throw NullPointerException currently if s == null, 
while the latter instead would start throwing NumberFormatException. I 
think we should favor throwing a NPE here. I'd argue that the risk that 
someone changes to any of the range-based alternatives when they aren't 
replacing a call to substring or similar are slim to none.

>
> You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ).

Fair points. I could argue String.substring(int, int), 
StringBuilder.append(CharSequence, int, int)etc are wrong, but I guess 
that might be a losing battle. :-)

>
> Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case.

The requireNonEmpty throws NumberFormatException to keep compatibility 
with the old methods, so it wouldn't make much sense to add that to 
String. If I split the parseX(String... and parseX(CharSequence... 
implementations as I intend to, this method will be redundant though.

>
> In Integer.java#643 you can combine the if statements like you have done for the equivalent method on Long.

Will do, thanks!

/Claes
>
> Hth,
> Paul.



From zhengyu.gu at oracle.com  Thu Jun 26 17:57:32 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 26 Jun 2014 13:57:32 -0400
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AB33C2.5050005@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
	<53AB33C2.5050005@oracle.com>
Message-ID: <53AC5F0C.5060305@oracle.com>

Hi Neil,

There is still an issue. Apparently, you can NOT free the buffer for the 
environment variable.

678                 char * pbuf = (char*)JLI_MemAlloc(pbuflen);
  679                 JLI_Snprintf(pbuf, pbuflen, "%s%d=%s", NMT_Env_Name, JLI_GetPid(), value);
  680                 retval = JLI_PutEnv(pbuf);
  681                 if (JLI_IsTraceLauncher()) {
  682                     char* envName;
  683                     char* envBuf;
  684
  685                     // ensures that malloc successful
  686                     envName = (char*)JLI_MemAlloc(pbuflen);
  687                     JLI_Snprintf(envName, pbuflen, "%s%d", NMT_Env_Name, JLI_GetPid());
  688
  689                     printf("TRACER_MARKER: NativeMemoryTracking: env var is %s\n",envName);
  690                     printf("TRACER_MARKER: NativeMemoryTracking: putenv arg %s\n",pbuf);
  691                     envBuf = getenv(envName);
  692                     printf("TRACER_MARKER: NativeMemoryTracking: got value %s\n",envBuf);
  693                     free(envName);
  694                 }
  695
  696                 free(pbuf);    <<<<=== can not free this buffer
  697             }


You can experiment it move #696 to #681, you will see the test to fail.

Linux putenv document says:

*putenv*is very widely available, but it might or might not copy its 
argument, risking memory leaks.


Thanks,

-Zhengyu


On 6/25/2014 4:40 PM, Neil Toda wrote:
>
> Okay, Very glad you checked.  It really does need to go as early as 
> your prototype suggested.
> I'll get right on it.
>
> -neil
>
> On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
>> Hi Neil,
>>
>> I tried out this patch with my hotspot, it does not work.
>>
>> The reason is that, the environment variable is setup too late, it 
>> has to be set before it launches JavaVM (before calling LoadJavaVM()) 
>> method.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>> On 6/25/2014 1:58 PM, Neil Toda wrote:
>>> Sorry.  One more webrev .. 06
>>>
>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>>
>>> Kumar's nit was correct and in fact index was old and should have 
>>> been removed
>>> allowing .contains member to be used instead of .indexOf.  So 
>>> cleaned up a bit more
>>> as can be seen below.  Other of Kumar's nits done.
>>>
>>> Thanks Kumar.
>>>
>>> webrev-06
>>>   102             // get the PID from the env var we set for the JVM
>>>   103             String envVarPid = null;
>>>   104             for (String line : tr.testOutput) {
>>>   105                 if (line.contains(envVarPidString)) {
>>>   106                     int sindex = envVarPidString.length();
>>>   107                     envVarPid = line.substring(sindex);
>>>   108                     break;
>>>   109                 }
>>>   110             }
>>>   111             // did we find envVarPid?
>>>   112             if (envVarPid == null) {
>>>   113                 System.out.println(tr);
>>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>   115             }
>>>
>>>
>>> webrev-05
>>>   102             // get the PID from the env var we set for the JVM
>>>   103             haveLauncherPid = false;
>>>   104             String envVarPid = null;
>>>   105             for (String line : tr.testOutput) {
>>>   106                 int index;
>>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>>   108                     int sindex = envVarPidString.length();
>>>   109                     envVarPid = line.substring(sindex);
>>>   110                     haveLauncherPid = true;
>>>   111                     break;
>>>   112                 }
>>>   113             }
>>>   114             // did we find envVarPid?
>>>   115             if (!haveLauncherPid) {
>>>   116                 System.out.println(tr);
>>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>   118             }
>>>
>>>
>>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>>
>>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>>> Explained below.
>>>>
>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>>
>>>> 105 : DONE
>>>> 146: DONE
>>>> 168: DONE
>>>>
>>>> 106: Your suggestion was the way I had originally coded it for 
>>>> Linux.  However
>>>>          on Windows/Cygwin, the code will not compile  There is 
>>>> some interaction
>>>>          with the doExec() preceeding it and the fact that it is a 
>>>> varlist.  This coding
>>>>          was the simplest workaround.
>>>>
>>>> Thanks for the nits Kumar.
>>>>
>>>>
>>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>>> Neil,
>>>>>
>>>>> Some nits:
>>>>>
>>>>> TestSpecialArgs.java:
>>>>>
>>>>> extra space
>>>>> 105 for ( String line : tr.testOutput) {
>>>>>
>>>>>
>>>>>
>>>>> This is very C'ish, I suggest.
>>>>>  -106                 int index;
>>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>>> >= 0) {
>>>>>
>>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>>  +107                 if (index >= 0) {
>>>>>
>>>>>
>>>>> Needs space
>>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>>
>>>>> Needs space
>>>>>
>>>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>>>> "+NMT_Option_Value)) {
>>>>> +168             if (!tr.contains("NativeMemoryTracking: got value 
>>>>> " + NMT_Option_Value)) {
>>>>>
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>>
>>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>>
>>>>>> Changes are:
>>>>>>
>>>>>>   1) java.c
>>>>>>         a) add free(envName) line 1063
>>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 
>>>>>> and 1056
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>>> Neil,
>>>>>>>
>>>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>>>> that one.
>>>>>>> Are you going to post another iteration ?
>>>>>>>
>>>>>>> Kumar
>>>>>>>
>>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>>
>>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>>> I'll use the JLI wrapper.
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>>
>>>>>>>>> -Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>>
>>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>>> are non-null.
>>>>>>>>>>
>>>>>>>>>> -neil
>>>>>>>>>>
>>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>>> Neil,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>>
>>>>>>>>>>> java.c:
>>>>>>>>>>>   Did not check return values of malloc(), I wonder if 
>>>>>>>>>>> source code analyzers will complain.
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> -neil
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>



From neil.toda at oracle.com  Thu Jun 26 19:58:05 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 26 Jun 2014 12:58:05 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AC5F0C.5060305@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
	<53AB33C2.5050005@oracle.com> <53AC5F0C.5060305@oracle.com>
Message-ID: <53AC7B4D.1040902@oracle.com>


You are right.  I found this upon looking:

https://www.securecoding.cert.org/confluence/display/seccode/POS34-C.+Do+not+call+putenv()+with+a+pointer+to+an+automatic+variable+as+the+argument

We moved to malloc since the launcher doesn't know about the value being 
passed
with the native memory flag.  We can put some limits on value, but that 
means
the launcher making a few more decisions.  We'll think on this a bit.

What are the possible values for

-XX:NativeMemoryTracking

For the future, are there any other possibilities?

Thanks

-neil

On 6/26/2014 10:57 AM, Zhengyu Gu wrote:
> Hi Neil,
>
> There is still an issue. Apparently, you can NOT free the buffer for 
> the environment variable.
>
> 678                 char * pbuf = (char*)JLI_MemAlloc(pbuflen);
>   679                 JLI_Snprintf(pbuf, pbuflen, "%s%d=%s", NMT_Env_Name, JLI_GetPid(), value);
>   680                 retval = JLI_PutEnv(pbuf);
>   681                 if (JLI_IsTraceLauncher()) {
>   682                     char* envName;
>   683                     char* envBuf;
>   684
>   685                     // ensures that malloc successful
>   686                     envName = (char*)JLI_MemAlloc(pbuflen);
>   687                     JLI_Snprintf(envName, pbuflen, "%s%d", NMT_Env_Name, JLI_GetPid());
>   688
>   689                     printf("TRACER_MARKER: NativeMemoryTracking: env var is %s\n",envName);
>   690                     printf("TRACER_MARKER: NativeMemoryTracking: putenv arg %s\n",pbuf);
>   691                     envBuf = getenv(envName);
>   692                     printf("TRACER_MARKER: NativeMemoryTracking: got value %s\n",envBuf);
>   693                     free(envName);
>   694                 }
>   695
>   696                 free(pbuf);    <<<<=== can not free this buffer
>   697             }
>
> You can experiment it move #696 to #681, you will see the test to fail.
>
> Linux putenv document says:
>
> *putenv*is very widely available, but it might or might not copy its 
> argument, risking memory leaks.
>
>
> Thanks,
>
> -Zhengyu
>
>
> On 6/25/2014 4:40 PM, Neil Toda wrote:
>>
>> Okay, Very glad you checked.  It really does need to go as early as 
>> your prototype suggested.
>> I'll get right on it.
>>
>> -neil
>>
>> On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
>>> Hi Neil,
>>>
>>> I tried out this patch with my hotspot, it does not work.
>>>
>>> The reason is that, the environment variable is setup too late, it 
>>> has to be set before it launches JavaVM (before calling 
>>> LoadJavaVM()) method.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>> On 6/25/2014 1:58 PM, Neil Toda wrote:
>>>> Sorry.  One more webrev .. 06
>>>>
>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>>>
>>>> Kumar's nit was correct and in fact index was old and should have 
>>>> been removed
>>>> allowing .contains member to be used instead of .indexOf. So 
>>>> cleaned up a bit more
>>>> as can be seen below.  Other of Kumar's nits done.
>>>>
>>>> Thanks Kumar.
>>>>
>>>> webrev-06
>>>>   102             // get the PID from the env var we set for the JVM
>>>>   103             String envVarPid = null;
>>>>   104             for (String line : tr.testOutput) {
>>>>   105                 if (line.contains(envVarPidString)) {
>>>>   106                     int sindex = envVarPidString.length();
>>>>   107                     envVarPid = line.substring(sindex);
>>>>   108                     break;
>>>>   109                 }
>>>>   110             }
>>>>   111             // did we find envVarPid?
>>>>   112             if (envVarPid == null) {
>>>>   113                 System.out.println(tr);
>>>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>>   115             }
>>>>
>>>>
>>>> webrev-05
>>>>   102             // get the PID from the env var we set for the JVM
>>>>   103             haveLauncherPid = false;
>>>>   104             String envVarPid = null;
>>>>   105             for (String line : tr.testOutput) {
>>>>   106                 int index;
>>>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>>>   108                     int sindex = envVarPidString.length();
>>>>   109                     envVarPid = line.substring(sindex);
>>>>   110                     haveLauncherPid = true;
>>>>   111                     break;
>>>>   112                 }
>>>>   113             }
>>>>   114             // did we find envVarPid?
>>>>   115             if (!haveLauncherPid) {
>>>>   116                 System.out.println(tr);
>>>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>>   118             }
>>>>
>>>>
>>>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>>>
>>>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>>>> Explained below.
>>>>>
>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>>>
>>>>> 105 : DONE
>>>>> 146: DONE
>>>>> 168: DONE
>>>>>
>>>>> 106: Your suggestion was the way I had originally coded it for 
>>>>> Linux.  However
>>>>>          on Windows/Cygwin, the code will not compile There is 
>>>>> some interaction
>>>>>          with the doExec() preceeding it and the fact that it is a 
>>>>> varlist.  This coding
>>>>>          was the simplest workaround.
>>>>>
>>>>> Thanks for the nits Kumar.
>>>>>
>>>>>
>>>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>>>> Neil,
>>>>>>
>>>>>> Some nits:
>>>>>>
>>>>>> TestSpecialArgs.java:
>>>>>>
>>>>>> extra space
>>>>>> 105 for ( String line : tr.testOutput) {
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is very C'ish, I suggest.
>>>>>>  -106                 int index;
>>>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>>>> >= 0) {
>>>>>>
>>>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>>>  +107                 if (index >= 0) {
>>>>>>
>>>>>>
>>>>>> Needs space
>>>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>>>
>>>>>> Needs space
>>>>>>
>>>>>> -168             if (!tr.contains("NativeMemoryTracking: got 
>>>>>> value "+NMT_Option_Value)) {
>>>>>> +168             if (!tr.contains("NativeMemoryTracking: got 
>>>>>> value " + NMT_Option_Value)) {
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>>
>>>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>>>
>>>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>>>
>>>>>>> Changes are:
>>>>>>>
>>>>>>>   1) java.c
>>>>>>>         a) add free(envName) line 1063
>>>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 
>>>>>>> and 1056
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>>>> Neil,
>>>>>>>>
>>>>>>>> Generally looks good, yes JLI_* functions must be used, I 
>>>>>>>> missed that one.
>>>>>>>> Are you going to post another iteration ?
>>>>>>>>
>>>>>>>> Kumar
>>>>>>>>
>>>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>>>
>>>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>>>> I'll use the JLI wrapper.
>>>>>>>>>
>>>>>>>>> -neil
>>>>>>>>>
>>>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>>>
>>>>>>>>>> -Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>>>
>>>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>>>> are non-null.
>>>>>>>>>>>
>>>>>>>>>>> -neil
>>>>>>>>>>>
>>>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> Neil,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> java.c:
>>>>>>>>>>>>   Did not check return values of malloc(), I wonder if 
>>>>>>>>>>>> source code analyzers will complain.
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Webrev  : 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>>>> bug         : 
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -neil
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From zhengyu.gu at oracle.com  Thu Jun 26 20:09:56 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 26 Jun 2014 16:09:56 -0400
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AC7B4D.1040902@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
	<53AB33C2.5050005@oracle.com> <53AC5F0C.5060305@oracle.com>
	<53AC7B4D.1040902@oracle.com>
Message-ID: <53AC7E14.4040206@oracle.com>

The possible values are: off, summary and detail

Thanks,

-Zhengyu

On 6/26/2014 3:58 PM, Neil Toda wrote:
>
> You are right.  I found this upon looking:
>
> https://www.securecoding.cert.org/confluence/display/seccode/POS34-C.+Do+not+call+putenv()+with+a+pointer+to+an+automatic+variable+as+the+argument
>
> We moved to malloc since the launcher doesn't know about the value 
> being passed
> with the native memory flag.  We can put some limits on value, but 
> that means
> the launcher making a few more decisions.  We'll think on this a bit.
>
> What are the possible values for
> -XX:NativeMemoryTracking
> For the future, are there any other possibilities?
>
> Thanks
>
> -neil
>
> On 6/26/2014 10:57 AM, Zhengyu Gu wrote:
>> Hi Neil,
>>
>> There is still an issue. Apparently, you can NOT free the buffer for 
>> the environment variable.
>>
>> 678                 char * pbuf = (char*)JLI_MemAlloc(pbuflen);
>>   679                 JLI_Snprintf(pbuf, pbuflen, "%s%d=%s", NMT_Env_Name, JLI_GetPid(), value);
>>   680                 retval = JLI_PutEnv(pbuf);
>>   681                 if (JLI_IsTraceLauncher()) {
>>   682                     char* envName;
>>   683                     char* envBuf;
>>   684
>>   685                     // ensures that malloc successful
>>   686                     envName = (char*)JLI_MemAlloc(pbuflen);
>>   687                     JLI_Snprintf(envName, pbuflen, "%s%d", NMT_Env_Name, JLI_GetPid());
>>   688
>>   689                     printf("TRACER_MARKER: NativeMemoryTracking: env var is %s\n",envName);
>>   690                     printf("TRACER_MARKER: NativeMemoryTracking: putenv arg %s\n",pbuf);
>>   691                     envBuf = getenv(envName);
>>   692                     printf("TRACER_MARKER: NativeMemoryTracking: got value %s\n",envBuf);
>>   693                     free(envName);
>>   694                 }
>>   695
>>   696                 free(pbuf);    <<<<=== can not free this buffer
>>   697             }
>>
>> You can experiment it move #696 to #681, you will see the test to fail.
>>
>> Linux putenv document says:
>>
>> *putenv*is very widely available, but it might or might not copy its 
>> argument, risking memory leaks.
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 6/25/2014 4:40 PM, Neil Toda wrote:
>>>
>>> Okay, Very glad you checked.  It really does need to go as early as 
>>> your prototype suggested.
>>> I'll get right on it.
>>>
>>> -neil
>>>
>>> On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
>>>> Hi Neil,
>>>>
>>>> I tried out this patch with my hotspot, it does not work.
>>>>
>>>> The reason is that, the environment variable is setup too late, it 
>>>> has to be set before it launches JavaVM (before calling 
>>>> LoadJavaVM()) method.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>> On 6/25/2014 1:58 PM, Neil Toda wrote:
>>>>> Sorry.  One more webrev .. 06
>>>>>
>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>>>>
>>>>> Kumar's nit was correct and in fact index was old and should have 
>>>>> been removed
>>>>> allowing .contains member to be used instead of .indexOf. So 
>>>>> cleaned up a bit more
>>>>> as can be seen below.  Other of Kumar's nits done.
>>>>>
>>>>> Thanks Kumar.
>>>>>
>>>>> webrev-06
>>>>>   102             // get the PID from the env var we set for the JVM
>>>>>   103             String envVarPid = null;
>>>>>   104             for (String line : tr.testOutput) {
>>>>>   105                 if (line.contains(envVarPidString)) {
>>>>>   106                     int sindex = envVarPidString.length();
>>>>>   107                     envVarPid = line.substring(sindex);
>>>>>   108                     break;
>>>>>   109                 }
>>>>>   110             }
>>>>>   111             // did we find envVarPid?
>>>>>   112             if (envVarPid == null) {
>>>>>   113                 System.out.println(tr);
>>>>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>>>   115             }
>>>>>
>>>>>
>>>>> webrev-05
>>>>>   102             // get the PID from the env var we set for the JVM
>>>>>   103             haveLauncherPid = false;
>>>>>   104             String envVarPid = null;
>>>>>   105             for (String line : tr.testOutput) {
>>>>>   106                 int index;
>>>>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>>>>   108                     int sindex = envVarPidString.length();
>>>>>   109                     envVarPid = line.substring(sindex);
>>>>>   110                     haveLauncherPid = true;
>>>>>   111                     break;
>>>>>   112                 }
>>>>>   113             }
>>>>>   114             // did we find envVarPid?
>>>>>   115             if (!haveLauncherPid) {
>>>>>   116                 System.out.println(tr);
>>>>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>>>   118             }
>>>>>
>>>>>
>>>>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>>>>
>>>>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>>>>> Explained below.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>>>>
>>>>>> 105 : DONE
>>>>>> 146: DONE
>>>>>> 168: DONE
>>>>>>
>>>>>> 106: Your suggestion was the way I had originally coded it for 
>>>>>> Linux.  However
>>>>>>          on Windows/Cygwin, the code will not compile There is 
>>>>>> some interaction
>>>>>>          with the doExec() preceeding it and the fact that it is 
>>>>>> a varlist.  This coding
>>>>>>          was the simplest workaround.
>>>>>>
>>>>>> Thanks for the nits Kumar.
>>>>>>
>>>>>>
>>>>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>>>>> Neil,
>>>>>>>
>>>>>>> Some nits:
>>>>>>>
>>>>>>> TestSpecialArgs.java:
>>>>>>>
>>>>>>> extra space
>>>>>>> 105 for ( String line : tr.testOutput) {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is very C'ish, I suggest.
>>>>>>>  -106                 int index;
>>>>>>>  -107                 if ((index = 
>>>>>>> line.indexOf(envVarPidString)) >= 0) {
>>>>>>>
>>>>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>>>>  +107                 if (index >= 0) {
>>>>>>>
>>>>>>>
>>>>>>> Needs space
>>>>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>>>>
>>>>>>> Needs space
>>>>>>>
>>>>>>> -168             if (!tr.contains("NativeMemoryTracking: got 
>>>>>>> value "+NMT_Option_Value)) {
>>>>>>> +168             if (!tr.contains("NativeMemoryTracking: got 
>>>>>>> value " + NMT_Option_Value)) {
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Kumar
>>>>>>>
>>>>>>>
>>>>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>>>>
>>>>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>>>>
>>>>>>>> Changes are:
>>>>>>>>
>>>>>>>>   1) java.c
>>>>>>>>         a) add free(envName) line 1063
>>>>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 
>>>>>>>> and 1056
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>>>>> Neil,
>>>>>>>>>
>>>>>>>>> Generally looks good, yes JLI_* functions must be used, I 
>>>>>>>>> missed that one.
>>>>>>>>> Are you going to post another iteration ?
>>>>>>>>>
>>>>>>>>> Kumar
>>>>>>>>>
>>>>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>>>>> I'll use the JLI wrapper.
>>>>>>>>>>
>>>>>>>>>> -neil
>>>>>>>>>>
>>>>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>>>>
>>>>>>>>>>> -Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure 
>>>>>>>>>>>> these are non-null.
>>>>>>>>>>>>
>>>>>>>>>>>> -neil
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> Neil,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> java.c:
>>>>>>>>>>>>>   Did not check return values of malloc(), I wonder if 
>>>>>>>>>>>>> source code analyzers will complain.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Webrev  : 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>>>>> bug         : 
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -neil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From stuart.marks at oracle.com  Thu Jun 26 21:40:24 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 26 Jun 2014 14:40:24 -0700
Subject: Process trees and termination
In-Reply-To: <53AC2CF9.8080300@oracle.com>
References: <53AB44B8.2080601@oracle.com>
	<53AB47C6.30305@redhat.com>	<53ABDFED.3070103@gmail.com>
	<53AC2CF9.8080300@oracle.com>
Message-ID: <53AC9348.4090900@oracle.com>

On 6/26/14 7:23 AM, roger riggs wrote:
> On 6/26/2014 4:55 AM, Peter Levart wrote:
>> - Will there be a guarantee that ProcessHandle objects returned from factory
>> methods: [...]
>> representing those processes that were started by ProcessBuilder API are
>> actually the same Process objects that were returned from the ProcessBuilder
>> API?

> The initial design does not have them returning Process instances.
> Process instances are capabilities and their reference accessibility is
> currently controlled
> by the code that created the Process.  If ProcessHandle gave out those Process
> instances
> it would break existing encapsulation.

Hi Roger,

This is an interesting point about the undesirability of leaking Process 
instances. I initially thought the relationship between ProcessHandle and 
Process objects would be unspecified, and possibly left to the implementation. 
But based on your comments, it sounds like the PH factories are **prohibited** 
from returning any instances of Process. Thus we'd have:

     Process proc = new ProcessBuilder(...).start();
     ProcessHandle ph = ProcessHandle.of(proc.getPid());
     assert !(ph instanceof Process);

It seems like it would be good idea to add this restriction to the specification.

s'marks


From dl at cs.oswego.edu  Thu Jun 26 23:10:22 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 26 Jun 2014 19:10:22 -0400
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53AB09E5.9070303@gmail.com>
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>			<53A98525.9080908@gmail.com>		<53A9EF29.7030208@gmail.com>
	<53AB09E5.9070303@gmail.com>
Message-ID: <53ACA85E.2030407@cs.oswego.edu>


Peter: Thanks very much for attacking the shocking impact/complexity
of getting a few seed bits.

On 06/25/2014 01:41 PM, Peter Levart wrote:
>
> Peeking around in the sun.security.provider package, I found there already is a
> minimal internal infrastructure for obtaining random seed. It's encapsulated in
> package-private abstract class sun.security.provider.SeedGenerator with 4
> implementations. It turns out that, besides Java-only fall-back implementation
> called ThreadedSeedGenerator and generic URLSeedGenerator, there are also two
> implementations of NativeSeedGenerator (one for UNIX-es which is just an
> extension of URLSeedGenerator and the other for Windows which uses MS
> CryptoAPI). I made a few tweaks that allow this sub-infrastructure to be used
> directly in ThreadLocalRandom and SplittableRandom:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/
>

This seems to be the best idea yet, assuming that people are OK
with the changes to sun.security.provider.SeedGenerator and
NativeSeedGenerator.java

-Doug





From bradford.wetmore at oracle.com  Thu Jun 26 23:35:03 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 26 Jun 2014 16:35:03 -0700
Subject: ThreadLocalRandom clinit troubles
In-Reply-To: <53ACA85E.2030407@cs.oswego.edu>
References: 	<53A29DC5.1030605@oracle.com>		<53A3FA72.3060706@gmail.com>	<53A418F2.3080201@gmail.com>	<53A43055.5070803@oracle.com>	<53A43EF3.8000206@gmail.com>	<53A44C3A.6000607@oracle.com>			<53A98525.9080908@gmail.com>		<53A9EF29.7030208@gmail.com>	<53AB09E5.9070303@gmail.com>
	<53ACA85E.2030407@cs.oswego.edu>
Message-ID: <53ACAE27.3050903@oracle.com>



On 6/26/2014 4:10 PM, Doug Lea wrote:
> This seems to be the best idea yet, assuming that people are OK
> with the changes to sun.security.provider.SeedGenerator and
> NativeSeedGenerator.java

I've been meaning to review this thread, but have been chasing several 
urgent escalations.

Brad


From mike.duigou at oracle.com  Thu Jun 26 23:58:50 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 26 Jun 2014 16:58:50 -0700
Subject: RFR: 8048207 : (xs) Collections.checkedQueue offer() calls add() on
	wrapped queue
Message-ID: <85C38407-0452-461B-9D0D-80981651F342@oracle.com>

Hello all;

This changeset corrects an issue with the Collections.checkedQueue() utility method added in Java 8. The wrapper implementation incorrectly calls add() on the wrapped queue rather than offer().

I improved the existing unit test to include this condition (and converted it to TestNG). I also converted a few uses of Collections.CheckedCollection.typeCheck to use the returned properly typed result where previously the callers had been using it as a standalone check.

jbsbug: https://bugs.openjdk.java.net/browse/JDK-8048207
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8048207/0/webrev/

Mike

From huizhe.wang at oracle.com  Fri Jun 27 05:39:40 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 26 Jun 2014 22:39:40 -0700
Subject: JDK9 project: XML/JAXP Approachability / Ease of Use
In-Reply-To: <9645C61E-B815-45CB-A7A4-49B10948B43D@saxonica.com>
References: <9645C61E-B815-45CB-A7A4-49B10948B43D@saxonica.com>
Message-ID: <53AD039C.5000302@oracle.com>

Thanks Michael! And, welcome to core-libs-dev! :-)

On 6/26/2014 4:02 AM, Michael Kay wrote:
> Here are some quick thoughts about the state of XML support in the JDK:
>
> 1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one has been fixing the bugs. It needs to be replaced with a more recent version of Apache Xerces if that hasn't already been done.

Yes, as Alan pointed out, we do have a project going on at the moment. 
The goal is to upgrade to the current version of Xerces, 2.11.0.  Also, 
we made updates during JDK 7 development, bringing in all of the 
blockers, critical fixes and half of the major fixes along the way.

>
> 2. DOM. From a usability perspective DOM is awful. There are much better alternatives available, for example JDOM2 or XOM. The only reason anyone uses DOM rather than these alternatives is either (a) because they aren't aware of the alternatives, or (b) because of some kind of perception that DOM is "more standard". If we want to address the usability of XML processing in the JDK then an alternative/replacement for DOM would seem to be a high priority. If someone wants a summary of the badness of DOM then I'll address that in a separate thread.

I agree that DOM is not particularly user/developer friendly. I don't 
have data to support an estimate on how popular DOM is, but since it's 
been a "standard", and we value compatibility so much, the first goal in 
the proposal is to allow users to quickly get to such objects and 
continue using their existing code to process them.

When we get into more low level then, what I would propose is for us to 
take a step back from the existing technologies/standards such as 
DOM/SAX/StAX and think like a developer would. For example, as a 
developer, all I want maybe is to search an xml file and find a piece of 
information, I don't necessarily need to know whether it's DOM or SAX, 
just as I don't need to know what technology is behind Google.

>
> 3. JAXP factory mechanism. While the goal of allowing multiple implementations of core interfaces such as DOM, XPath, and XSLT is laudable, the current mechanism has many failings. It's hideously expensive because of the classpath search; it's fragile because the APIs are so weakly defined that the implemntations aren't 100% interoperable (for example you have no way of knowing whether the XPath factory will give you an XPath 1.0 or 2.0 processor, and no way of finding out which you have got); so in practice we see lots of problems where applications get a processor that doesn't work as the applications expects, just because it happens to be lying around on the classpath.

Agree. It's an important mechanism to give users freedom of choice of 
impls they prefer, but has room to improve. In the case of XPath, should 
we start a separate thread to discuss how we can improve it?

>
> 4. XQJ. The XQJ spec never found its way into the JDK, so there is no out-of-the-box XQuery support. The licensing terms for XQJ are also unsatisfactory (the license doesn't allow modification, which purists say means it's not a true open source license).

True, it's in the DB line of products. I'm not familiar with the 
licensing terms for the spec.

>
> 5. General lack of integration across the whole XML scene, e.g, separate and potentially incompatible factories for different services;

We can explore more on this.  The example in the proposal is a possible 
case for parser & xpath integration.

> a lack of clarity as to whether the XPath API is supposed to handle object models other than DOM, etc;

The spec required impl to support the default object model and made it 
free for impls to introduce others.

> weak typing of interfaces such as setParameter() in order to accomodate variation, at the cost of interoperability.

StAX did better in this regard, with a list of specified properties. In 
case of setParameter(), it almost seemed to me that the author wanted to 
give impls room to specify their own parameters.

>
> 6. Failure to keep up to date with the W3C specs; if you want support for recent versions of XSLT or XPath then you need to go to third-party products. Even at the DOM level, namespaces are a bolt-on optional extra rather than an intrinsic capability.

We can discuss this in a separate thread as well.

>
> 7. Inconsistent policy on concrete classes versus interfaces.

Could you provide a few examples?

>
> Is this project attempting to address the fundamental problems, or only to paper over the cracks?

The goal of the project is to improve usability, making it more 
approachable: easy tasks should be easy to do. Not mean to completely 
redesign all the features, but focus on common use cases to provide 
better APIs to handle them.

-Joe

>
>
>> We're planning on a jaxp project to address usability issues in the JAXP
>> API. One of the complaints about the JAXP API is the number of lines of
>> code that are needed to implement a simple task. Tasks that should take
>> one or two lines often take ten or twelve lines instead.
>
> Michael Kay
> Saxonica
> mike at saxonica.com
> +44 (0118) 946 5893
>
>
>



From kasperni at gmail.com  Fri Jun 27 07:06:13 2014
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 27 Jun 2014 09:06:13 +0200
Subject: Streams and Spliterator characteristics confusion
Message-ID: 

Hi,

I'm trying to understand how the Spliterator.characteristics are maintained
across stream operations and I'm a bit confused. Maybe someone here can
clear it up for me

s.sorted().spliterator() -> Spliterator.SORTED = true
But if I use specify a comparator the stream is not sorted
s.sorted((a,b) -> 1).spliterator() -> Spliterator.SORTED = false

s.distinct().spliterator() -> Spliterator.DISTINCT = true
but limiting the number of distinct elements makes the stream non distinct
s.distinct().limit(10).spliterator() -> Spliterator.DISTINCT = false
On the other hand something like Spliterator.SORTED is maintained when I
invoke limit
s.sorted().limit(10).spliterator() -> Spliterator.SORTED = true


A flag such as Spliterator.NONNULL is also cleared in situations where it
should not be.
In my opinion an operation such as filter(predicate) should not flip the
flag.

Finally, are there any relationship between Spliterator.SORTED and
Spliterator.ORDERED.
I would think that a stream cannot be sorted without it also being ordered?
but s.sorted().unordered().spliterator returns ORDERED=false and SORTED=true

Cheers
  Kasper


From paul.sandoz at oracle.com  Fri Jun 27 08:54:18 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Jun 2014 10:54:18 +0200
Subject: RFR [9] 8041972: Add improved parse/format methods for
	Long/Integer
In-Reply-To: <53AC5007.30603@oracle.com>
References: <539CCE6D.6040207@oracle.com>	<539D8821.3070808@univ-mlv.fr>	<539D91A0.9050901@oracle.com>	<539E1CB4.2050502@oracle.com>	<539F4A6A.5020002@oracle.com>	<539F4FCE.9080903@oracle.com>	<53A04EE7.6090309@oracle.com>	<53A06224.1040600@oracle.com>
	<53A32043.7070008@oracle.com>
	<39373F79-DC28-4A51-B617-680C6C508538@oracle.com>
	<53AC5007.30603@oracle.com>
Message-ID: <167AB3E2-253B-41B5-B8DF-B6C7C7F7C16B@oracle.com>


On Jun 26, 2014, at 6:53 PM, Claes Redestad  wrote:

> On 06/25/2014 06:43 PM, Paul Sandoz wrote:
>> On Jun 19, 2014, at 7:39 PM, Claes Redestad  wrote:
>>> Hi,
>>> 
>>> an updated webrev with reworked, public methods is available here:
>>> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
>>> 
>>> Reviews are yet again appreciated!
>>> 
>> I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.)
> 
> Agreed. Using s.getClass() was necessitated to retain performance using default compiler (-XX:+TieredCompilation) in the microbenchmarks I've been using, and going back to testing with C1 (via means of -XX:TieredStartAtLevel=1-3), it's apparent that the patch can cause a regression with the client compiler that I hadn't checked.It even looks like C2 alone (-XX:-TieredCompilation) suffers slightly.
> 
> Changing to Objects.requireNonNull doesn't seem to make things better, though. Rather the regression seem to be due to C1 (and in some ways even C2) not dealing very well with the increased degrees of freedoms in the new methods, so I'm currently considering splitting apart the implementations to keep the old implementations of parseX(String[, int]) untouched while duplicating some code to build the new methods. Ugly, but I guess it's anecessary evil here.
> 

Ok.  Perhaps it might be possible to place the specifics of constraint checking in public methods, but they defer to a general private method that can assume it's arguments are safe (or such arguments are checked by other method calls e.g. CS.charAt)


>> Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException.
> 
> Consider Integer.parseInt(s.substring(1)) and Integer.parseInt(s, 10, 1): the first would throw NullPointerException currently if s == null, while the latter instead would start throwing NumberFormatException. I think we should favor throwing a NPE here. I'd argue that the risk that someone changes to any of the range-based alternatives when they aren't replacing a call to substring or similar are slim to none.
> 

A good point.


>> 
>> You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ).
> 
> Fair points. I could argue String.substring(int, int), StringBuilder.append(CharSequence, int, int)etc are wrong, but I guess that might be a losing battle. :-)
> 

Right, if we were starting again it might be different but i think consistency is important.


>> 
>> Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case.
> 
> The requireNonEmpty throws NumberFormatException to keep compatibility with the old methods, so it wouldn't make much sense to add that to String.

Doh! what was i thinking. If it stays perhaps place it as a package private method on Number.


> If I split the parseX(String... and parseX(CharSequence... implementations as I intend to, this method will be redundant though.
> 

Ok.

Paul.


From paul.sandoz at oracle.com  Fri Jun 27 09:43:16 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Jun 2014 11:43:16 +0200
Subject: Streams and Spliterator characteristics confusion
In-Reply-To: 
References: 
Message-ID: 

On Jun 27, 2014, at 9:06 AM, Kasper Nielsen  wrote:
> Hi,
> 
> I'm trying to understand how the Spliterator.characteristics are maintained
> across stream operations and I'm a bit confused. Maybe someone here can
> clear it up for me
> 

Internally in the stream pipeline we keep track of certain characteristics for optimization purposes and those are conveniently used to determine the characteristics of the Spliterator, so there are some idiosyncrasies poking through.


> s.sorted().spliterator() -> Spliterator.SORTED = true
> But if I use specify a comparator the stream is not sorted
> s.sorted((a,b) -> 1).spliterator() -> Spliterator.SORTED = false
> 

Right, there is an optimization internally that ensures if the upstream stream is already sorted than the sort operation becomes a nop e.g.

  s.sorted().sorted();

This optimization cannot apply when a comparator is passed in since we don't know if two comparators are identical in their behaviour e.g:

  s.sorted((a, b) -> a.compareTo(b)).sorted(Compatators.naturalOrder()).sorted()


> s.distinct().spliterator() -> Spliterator.DISTINCT = true
> but limiting the number of distinct elements makes the stream non distinct
> s.distinct().limit(10).spliterator() -> Spliterator.DISTINCT = false

I don't observe that (see program below).


> On the other hand something like Spliterator.SORTED is maintained when I
> invoke limit
> s.sorted().limit(10).spliterator() -> Spliterator.SORTED = true
> 
> 
> A flag such as Spliterator.NONNULL is also cleared in situations where it
> should not be.

That is because it is not tracked in the pipeline as there is no gain optimisation-wise (if it was it would be cleared for map/flatMap operations and preserved for other ops like filter as you say below).

It's not that difficult to support this and should add no measurable performance cost, we deliberately left space in the bit fields, however since spliterator() is an escape-hatch for doing stuff that cannot be done by other operations i think the value of supporting NONULL is marginal.


> In my opinion an operation such as filter(predicate) should not flip the
> flag.
> 
> Finally, are there any relationship between Spliterator.SORTED and
> Spliterator.ORDERED.
> I would think that a stream cannot be sorted without it also being ordered?
> but s.sorted().unordered().spliterator returns ORDERED=false and SORTED=true
> 


Strictly speaking this spliterator is not conforming as per the specification of Spltierator.ORDERED.

The reason is for the following example the last sorted is still a nop:

  s.sorted().unordered().sorted()

I think in this case we can post-fix the flags to re-set ORDERED, if it was cleared, and if SORTED is still set.

Paul.

import java.util.Arrays;
import java.util.List;
import java.util.Spliterator;

public class Test {

    public static void main(String[] args) {
        List l = Arrays.asList(1, 2, 3, 4);

        x("l.stream().distinct()",
          l.stream().distinct().spliterator());
        x("l.stream().distinct().limit(10)",
          l.stream().distinct().limit(10).spliterator());

        x("l.stream().sorted()",
          l.stream().sorted().spliterator());
        x("l.stream().sorted().limit(10)",
          l.stream().sorted().limit(10).spliterator());

        x("l.stream().unordered()",
          l.stream().sorted().unordered().spliterator());
    }

    static void x(String sd, Spliterator s) {
        int cs = s.characteristics();

        StringBuilder sb = new StringBuilder(sd);
        sb.append(": ");
        x(sb, cs, Spliterator.SORTED, "SORTED");
        sb.append(", ");
        x(sb, cs, Spliterator.DISTINCT, "DISTINCT");
        sb.append(", ");
        x(sb, cs, Spliterator.ORDERED, "ORDERED");
        System.out.println(sb);
    }

    static void x(StringBuilder sb, int cs, int ct, String s) {
        if ((cs & ct) == 0) {
            sb.append("~");
        }
        sb.append(s);
    }
}



From paul.sandoz at oracle.com  Fri Jun 27 09:49:50 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Jun 2014 11:49:50 +0200
Subject: RFR: 8048207 : (xs) Collections.checkedQueue offer() calls add()
	on wrapped queue
In-Reply-To: <85C38407-0452-461B-9D0D-80981651F342@oracle.com>
References: <85C38407-0452-461B-9D0D-80981651F342@oracle.com>
Message-ID: 


On Jun 27, 2014, at 1:58 AM, Mike Duigou  wrote:

> Hello all;
> 
> This changeset corrects an issue with the Collections.checkedQueue() utility method added in Java 8. The wrapper implementation incorrectly calls add() on the wrapped queue rather than offer().
> 
> I improved the existing unit test to include this condition (and converted it to TestNG). I also converted a few uses of Collections.CheckedCollection.typeCheck to use the returned properly typed result where previously the callers had been using it as a standalone check.
> 
> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8048207
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8048207/0/webrev/
> 

+1

Paul.


From pavel.rappo at oracle.com  Fri Jun 27 10:00:52 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 27 Jun 2014 11:00:52 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
Message-ID: 

I created an issue to track the progress and also made 2 webrevs. One for the original patch and one for the changes that have been suggested earlier in this thread by Paul and Andrej. Here we go:

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

http://cr.openjdk.java.net/~prappo/8048267/webrev.00
http://cr.openjdk.java.net/~prappo/8048267/webrev.01
 
-Pavel

On 26 Jun 2014, at 10:58, Chris Hegarty  wrote:

> Otavio,
> 
> I skimmed over the patches and they look ok to me. I think they would be suitable for inclusion in jdk9/dev.
> 
> -Chris.
> 
> P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who may be able to help get his in.
> 
> On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana  wrote:
> 
>> Reason: The Long class has cache and using it, will save memory and will
>> faster than using create new instance of Long.
>> 
>> webrev:
>> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
>> 
>> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
>> -- 
>> 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 andrej.golovnin at gmail.com  Fri Jun 27 10:36:19 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 27 Jun 2014 12:36:19 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
Message-ID: 

Hi Pavel,

the both web revs looks identical to me. Here is what I have found so far
in the webrev.01:

in src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java:

@@ -108,11 +108,11 @@
      * @param primaryGroup true if the specified GID represents the
      *                  primary group to which this user belongs.
      *
      */
     public SolarisNumericGroupPrincipal(long name, boolean primaryGroup) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
         this.primaryGroup = primaryGroup;
     }

It is better to use Long.toString(long):

+        this.name = Long.toString(name);

This also applies to:

src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java


@@ -94,11 +94,11 @@
      *
      * @param name the user identification number (UID) for this user
      *                  represented as a long.
      */
     public SolarisNumericUserPrincipal(long name) {
-        this.name = (new Long(name)).toString();
+        this.name = Long.valueOf(name).toString();
     }


In src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:

@@ -542,11 +542,11 @@
                     RequiredModelMBean.class.getName(),
                         mth,"currencyTimeLimit: " + expTime);
             }

             // convert seconds to milliseconds for time comparison
-            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
+            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;

Please use Long.parseLong(String), e.g.:

+            currencyPeriod = Long.parseLong(expTime) * 1000;

And here please use Long.parseLong8String) too:

@@ -578,11 +578,11 @@
                 }

                 if (tStamp == null)
                     tStamp = "0";

-                long lastTime = (new Long(tStamp)).longValue();
+                long lastTime = (Long.valueOf(tStamp)).longValue();

e.g.:

+                long lastTime = Long.parseLong(tStamp);


In src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java

@@ -201,11 +201,11 @@
             return false;
         }
     }

     public int hashCode() {
-        return new Long(pName).hashCode();
+        return Long.valueOf(pName).hashCode();
     }

The method Long.hashCode(long) (added in JDK 8) should be used to calculate
the hash for a long value, e.g.:

+        return Long.hashCode(pName);

Best regards,
Andrej Golovnin




On Fri, Jun 27, 2014 at 12:00 PM, Pavel Rappo 
wrote:

> I created an issue to track the progress and also made 2 webrevs. One for
> the original patch and one for the changes that have been suggested earlier
> in this thread by Paul and Andrej. Here we go:
>
> https://bugs.openjdk.java.net/browse/JDK-8048267
>
> http://cr.openjdk.java.net/~prappo/8048267/webrev.00
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01
>
> -Pavel
>
> On 26 Jun 2014, at 10:58, Chris Hegarty  wrote:
>
> > Otavio,
> >
> > I skimmed over the patches and they look ok to me. I think they would be
> suitable for inclusion in jdk9/dev.
> >
> > -Chris.
> >
> > P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who
> may be able to help get his in.
> >
> > On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana <
> otaviojava at java.net> wrote:
> >
> >> Reason: The Long class has cache and using it, will save memory and will
> >> faster than using create new instance of Long.
> >>
> >> webrev:
> >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
> >>
> >> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> >> --
> >> 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 pavel.rappo at oracle.com  Fri Jun 27 10:52:45 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 27 Jun 2014 11:52:45 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
	
Message-ID: 

Hi Andrej,

They are not identical. Maybe it's just hard to spot it as it's not an incremental webrev. Have a look at

(line 583):

http://cr.openjdk.java.net/~prappo/8048267/webrev.00/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java.sdiff.html

(line 90):

http://cr.openjdk.java.net/~prappo/8048267/webrev.00/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java.sdiff.html

Though I've missed one you suggested in RequiredModelMBean.java:547
Anyway, I'll try to incorporate everything you've spotted so far.

Thanks,
-Pavel

On 27 Jun 2014, at 11:36, Andrej Golovnin  wrote:

> Hi Pavel,
> 
> the both web revs looks identical to me. Here is what I have found so far in the webrev.01:
> 
> in src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java:
> 
> @@ -108,11 +108,11 @@
>       * @param primaryGroup true if the specified GID represents the
>       *                  primary group to which this user belongs.
>       *
>       */
>      public SolarisNumericGroupPrincipal(long name, boolean primaryGroup) {
> -        this.name = (new Long(name)).toString();
> +        this.name = Long.valueOf(name).toString();
>          this.primaryGroup = primaryGroup;
>      }
> 
> It is better to use Long.toString(long):
> 
> +        this.name = Long.toString(name);
> 
> This also applies to:
> 
> src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
> src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
> src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java
> 
> 
> @@ -94,11 +94,11 @@
>       *
>       * @param name the user identification number (UID) for this user
>       *                  represented as a long.
>       */
>      public SolarisNumericUserPrincipal(long name) {
> -        this.name = (new Long(name)).toString();
> +        this.name = Long.valueOf(name).toString();
>      }
> 
> 
> In src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:
> 
> @@ -542,11 +542,11 @@
>                      RequiredModelMBean.class.getName(),
>                          mth,"currencyTimeLimit: " + expTime);
>              }
>  
>              // convert seconds to milliseconds for time comparison
> -            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
> +            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
> 
> Please use Long.parseLong(String), e.g.:
> 
> +            currencyPeriod = Long.parseLong(expTime) * 1000;
> 
> And here please use Long.parseLong8String) too:
> 
> @@ -578,11 +578,11 @@
>                  }
>  
>                  if (tStamp == null)
>                      tStamp = "0";
>  
> -                long lastTime = (new Long(tStamp)).longValue();
> +                long lastTime = (Long.valueOf(tStamp)).longValue();
> 
> e.g.:
> 
> +                long lastTime = Long.parseLong(tStamp);
> 
> 
> In src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
> 
> @@ -201,11 +201,11 @@
>              return false;
>          }
>      }
>  
>      public int hashCode() {
> -        return new Long(pName).hashCode();
> +        return Long.valueOf(pName).hashCode();
>      }
> 
> The method Long.hashCode(long) (added in JDK 8) should be used to calculate the hash for a long value, e.g.:
> 
> +        return Long.hashCode(pName);
> 
> Best regards,
> Andrej Golovnin
> 
> 
> 
> 
> On Fri, Jun 27, 2014 at 12:00 PM, Pavel Rappo  wrote:
> I created an issue to track the progress and also made 2 webrevs. One for the original patch and one for the changes that have been suggested earlier in this thread by Paul and Andrej. Here we go:
> 
> https://bugs.openjdk.java.net/browse/JDK-8048267
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.00
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01
> 
> -Pavel
> 
> On 26 Jun 2014, at 10:58, Chris Hegarty  wrote:
> 
> > Otavio,
> >
> > I skimmed over the patches and they look ok to me. I think they would be suitable for inclusion in jdk9/dev.
> >
> > -Chris.
> >
> > P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who may be able to help get his in.
> >
> > On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana  wrote:
> >
> >> Reason: The Long class has cache and using it, will save memory and will
> >> faster than using create new instance of Long.
> >>
> >> webrev:
> >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
> >>
> >> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
> >> --
> >> 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.coffey at oracle.com  Fri Jun 27 12:35:40 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Fri, 27 Jun 2014 13:35:40 +0100
Subject: RFR : 7095856: OutputStreamHook doesn't handle null values
Message-ID: <53AD651C.2050304@oracle.com>

Looking for a review around this CORBA issue.

bug report : https://bugs.openjdk.java.net/browse/JDK-7095856
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/

Null values cause issue when processed by an IIOPOutputStream and I 
can't see a reason why they wouldn't be allowed. Note that the glassfish 
code already employs a HashMap to hold such values. I've run CORBA SQE 
tests, unit tests and relevant TCK tests. No issues seen.

regards,
Sean.


From kumar.x.srinivasan at oracle.com  Fri Jun 27 12:50:38 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 27 Jun 2014 05:50:38 -0700
Subject: Ready for Review : 8042469 : Launcher changes for native memory
	tracking scalability enhancement
In-Reply-To: <53AC386F.3090509@oracle.com>
References: <53A38068.6010200@oracle.com>
	<53A42284.4020707@oracle.com>	<53A46656.3010105@oracle.com>
	<53A4BDEE.8040305@oracle.com>	<53A4C34C.4010004@oracle.com>
	<53A4C799.900@oracle.com>	<53A86350.4020802@oracle.com>
	<53A970E5.8060908@oracle.com> <53A9ED90.6060905@oracle.com>
	<53AB0DD6.2060305@oracle.com> <53AB1D68.6000204@oracle.com>
	<53AC386F.3090509@oracle.com>
Message-ID: <53AD689E.4080200@oracle.com>

Looks fine.

Kumar

On 6/26/2014 8:12 AM, Neil Toda wrote:
>
> Zhengyu
>
> Earlier creation of the environmental variable.
>
> http://cr.openjdk.java.net/~ntoda/8042469/webrev-07/
>
> The new webrev [07] places the new code in the function 
> SetJvmEnvironment()
>
> ===
> . JLI_Launch()
>   . InitLauncher()
>   . CreateExecutionEnvironment()
>     . CheckJvmType()
>   . SetJvmEnvironment()
>   . LoadJavaVM()
>   ...
>   . ParseArguments()
> ===
>
> Kumar and I settled on this organization last night, moving the code
> out of ParseArguments() into its own function.
>
> All previous review comments for the launcher and test are included in 
> this
> revision.
>
> Thanks
>
> -neil
>
>
> On 6/25/2014 12:05 PM, Zhengyu Gu wrote:
>> Hi Neil,
>>
>> I tried out this patch with my hotspot, it does not work.
>>
>> The reason is that, the environment variable is setup too late, it 
>> has to be set before it launches JavaVM (before calling LoadJavaVM()) 
>> method.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>> On 6/25/2014 1:58 PM, Neil Toda wrote:
>>> Sorry.  One more webrev .. 06
>>>
>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-06/
>>>
>>> Kumar's nit was correct and in fact index was old and should have 
>>> been removed
>>> allowing .contains member to be used instead of .indexOf.  So 
>>> cleaned up a bit more
>>> as can be seen below.  Other of Kumar's nits done.
>>>
>>> Thanks Kumar.
>>>
>>> webrev-06
>>>   102             // get the PID from the env var we set for the JVM
>>>   103             String envVarPid = null;
>>>   104             for (String line : tr.testOutput) {
>>>   105                 if (line.contains(envVarPidString)) {
>>>   106                     int sindex = envVarPidString.length();
>>>   107                     envVarPid = line.substring(sindex);
>>>   108                     break;
>>>   109                 }
>>>   110             }
>>>   111             // did we find envVarPid?
>>>   112             if (envVarPid == null) {
>>>   113                 System.out.println(tr);
>>>   114                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>   115             }
>>>
>>>
>>> webrev-05
>>>   102             // get the PID from the env var we set for the JVM
>>>   103             haveLauncherPid = false;
>>>   104             String envVarPid = null;
>>>   105             for (String line : tr.testOutput) {
>>>   106                 int index;
>>>   107                 if ((index = line.indexOf(envVarPidString)) >= 0) {
>>>   108                     int sindex = envVarPidString.length();
>>>   109                     envVarPid = line.substring(sindex);
>>>   110                     haveLauncherPid = true;
>>>   111                     break;
>>>   112                 }
>>>   113             }
>>>   114             // did we find envVarPid?
>>>   115             if (!haveLauncherPid) {
>>>   116                 System.out.println(tr);
>>>   117                 throw new RuntimeException("Error: failed to find env Var Pid in tracking info");
>>>   118             }
>>>
>>>
>>> On 6/24/2014 2:28 PM, Neil Toda wrote:
>>>>
>>>> New webrev-05 with Kumar's comments except for the "C'ish" style. 
>>>> Explained below.
>>>>
>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/
>>>>
>>>> 105 : DONE
>>>> 146: DONE
>>>> 168: DONE
>>>>
>>>> 106: Your suggestion was the way I had originally coded it for 
>>>> Linux.  However
>>>>          on Windows/Cygwin, the code will not compile  There is 
>>>> some interaction
>>>>          with the doExec() preceeding it and the fact that it is a 
>>>> varlist.  This coding
>>>>          was the simplest workaround.
>>>>
>>>> Thanks for the nits Kumar.
>>>>
>>>>
>>>> On 6/24/2014 5:36 AM, Kumar Srinivasan wrote:
>>>>> Neil,
>>>>>
>>>>> Some nits:
>>>>>
>>>>> TestSpecialArgs.java:
>>>>>
>>>>> extra space
>>>>> 105 for ( String line : tr.testOutput) {
>>>>>
>>>>>
>>>>>
>>>>> This is very C'ish, I suggest.
>>>>>  -106                 int index;
>>>>>  -107                 if ((index = line.indexOf(envVarPidString)) 
>>>>> >= 0) {
>>>>>
>>>>>  +106                 int index = line.indexOf(envVarPidString);
>>>>>  +107                 if (index >= 0) {
>>>>>
>>>>>
>>>>> Needs space
>>>>> -146 launcherPid = line.substring(sindex,tindex);
>>>>> +146 launcherPid = line.substring(sindex, tindex);
>>>>>
>>>>> Needs space
>>>>>
>>>>> -168             if (!tr.contains("NativeMemoryTracking: got value 
>>>>> "+NMT_Option_Value)) {
>>>>> +168             if (!tr.contains("NativeMemoryTracking: got value 
>>>>> " + NMT_Option_Value)) {
>>>>>
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>> On 6/23/2014 10:26 AM, Neil Toda wrote:
>>>>>>
>>>>>> I've spun a new webrev based on the comments for webrev-03:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
>>>>>>
>>>>>> Changes are:
>>>>>>
>>>>>>   1) java.c
>>>>>>         a) add free(envName) line 1063
>>>>>>         b) change from malloc() to JLI_MemAlloc() @ lines 1048 
>>>>>> and 1056
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>> On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
>>>>>>> Neil,
>>>>>>>
>>>>>>> Generally looks good, yes JLI_* functions must be used, I missed 
>>>>>>> that one.
>>>>>>> Are you going to post another iteration ?
>>>>>>>
>>>>>>> Kumar
>>>>>>>
>>>>>>> On 6/20/2014 4:27 PM, Neil Toda wrote:
>>>>>>>>
>>>>>>>> Thanks Joe.  It would have checked for NULL for me.
>>>>>>>> I'll use the JLI wrapper.
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>> On 6/20/2014 4:04 PM, Joe Darcy wrote:
>>>>>>>>> Memory allocation in the launcher should use one of the 
>>>>>>>>> JLI_MemAlloc wrappers, if possible.
>>>>>>>>>
>>>>>>>>> -Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/20/2014 09:50 AM, Neil Toda wrote:
>>>>>>>>>>
>>>>>>>>>> They should complain.  Thanks Zhengyu.  I'll make sure these 
>>>>>>>>>> are non-null.
>>>>>>>>>>
>>>>>>>>>> -neil
>>>>>>>>>>
>>>>>>>>>> On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
>>>>>>>>>>> Neil,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for quick implementation.
>>>>>>>>>>>
>>>>>>>>>>> java.c:
>>>>>>>>>>>   Did not check return values of malloc(), I wonder if 
>>>>>>>>>>> source code analyzers will complain.
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>> On 6/19/2014 8:29 PM, Neil Toda wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Launcher support for modified Native Memory Tracking 
>>>>>>>>>>>> mechanism in JVM in JDK9.
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev  : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
>>>>>>>>>>>> bug         : https://bugs.openjdk.java.net/browse/JDK-8042469
>>>>>>>>>>>> CCC         : http://ccc.us.oracle.com/8042469
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> -neil
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>



From pavel.rappo at oracle.com  Fri Jun 27 15:03:48 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 27 Jun 2014 16:03:48 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
	
	
Message-ID: <7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>

I've just created a webrev with all the changes we've discussed so far. Plus some more I've spotted while looking into the code. Please note, this webrev is not incremental. It grabs all the changes between the original patch and the latest discussed:

http://cr.openjdk.java.net/~prappo/8048267/webrev.02

Andrej, you can verify that all your changes are included as well as Paul's. As a workaround for this particular review thread you can download changeset files from consecutive webrevs and just diff them:

http://cr.openjdk.java.net/~prappo/8048267/webrev.$(i)/jdk.changeset
http://cr.openjdk.java.net/~prappo/8048267/webrev.$(i+1)/jdk.changeset

In addition to these I also found some more. It turns out such simple changes can lead to infinite recursion calls. Compare these:

(line 622):

http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java.sdiff.html

(lines 384, 508):

http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/java/awt/image/renderable/ParameterBlock.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/java/awt/image/renderable/ParameterBlock.java.sdiff.html

Also, I removed one useless creation of a Long object here:

(line 191):

http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html

I wonder if we should leave a cast to int here:

(line 383):

http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html

Well it's probably nothing to worry about, but strictly speaking this changes the behaviour. Before the change, long was truncated to fit int. And now it's not.

P.S. Andrej, it looks like you don't have an 'Author' status. Well, that's a pity. We could mention you in the 'Reviewed-by' line. Your contributions are really good.

-Pavel

On 27 Jun 2014, at 11:52, Pavel Rappo  wrote:

> Hi Andrej,
> 
> They are not identical. Maybe it's just hard to spot it as it's not an incremental webrev. Have a look at
> 
> (line 583):
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.00/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java.sdiff.html
> 
> (line 90):
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.00/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java.sdiff.html
> 
> Though I've missed one you suggested in RequiredModelMBean.java:547
> Anyway, I'll try to incorporate everything you've spotted so far.
> 
> Thanks,
> -Pavel
> 
> On 27 Jun 2014, at 11:36, Andrej Golovnin  wrote:
> 
>> Hi Pavel,
>> 
>> the both web revs looks identical to me. Here is what I have found so far in the webrev.01:
>> 
>> in src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java:
>> 
>> @@ -108,11 +108,11 @@
>>      * @param primaryGroup true if the specified GID represents the
>>      *                  primary group to which this user belongs.
>>      *
>>      */
>>     public SolarisNumericGroupPrincipal(long name, boolean primaryGroup) {
>> -        this.name = (new Long(name)).toString();
>> +        this.name = Long.valueOf(name).toString();
>>         this.primaryGroup = primaryGroup;
>>     }
>> 
>> It is better to use Long.toString(long):
>> 
>> +        this.name = Long.toString(name);
>> 
>> This also applies to:
>> 
>> src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
>> src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
>> src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java
>> 
>> 
>> @@ -94,11 +94,11 @@
>>      *
>>      * @param name the user identification number (UID) for this user
>>      *                  represented as a long.
>>      */
>>     public SolarisNumericUserPrincipal(long name) {
>> -        this.name = (new Long(name)).toString();
>> +        this.name = Long.valueOf(name).toString();
>>     }
>> 
>> 
>> In src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:
>> 
>> @@ -542,11 +542,11 @@
>>                     RequiredModelMBean.class.getName(),
>>                         mth,"currencyTimeLimit: " + expTime);
>>             }
>> 
>>             // convert seconds to milliseconds for time comparison
>> -            currencyPeriod = ((new Long(expTime)).longValue()) * 1000;
>> +            currencyPeriod = ((Long.valueOf(expTime)).longValue()) * 1000;
>> 
>> Please use Long.parseLong(String), e.g.:
>> 
>> +            currencyPeriod = Long.parseLong(expTime) * 1000;
>> 
>> And here please use Long.parseLong8String) too:
>> 
>> @@ -578,11 +578,11 @@
>>                 }
>> 
>>                 if (tStamp == null)
>>                     tStamp = "0";
>> 
>> -                long lastTime = (new Long(tStamp)).longValue();
>> +                long lastTime = (Long.valueOf(tStamp)).longValue();
>> 
>> e.g.:
>> 
>> +                long lastTime = Long.parseLong(tStamp);
>> 
>> 
>> In src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
>> 
>> @@ -201,11 +201,11 @@
>>             return false;
>>         }
>>     }
>> 
>>     public int hashCode() {
>> -        return new Long(pName).hashCode();
>> +        return Long.valueOf(pName).hashCode();
>>     }
>> 
>> The method Long.hashCode(long) (added in JDK 8) should be used to calculate the hash for a long value, e.g.:
>> 
>> +        return Long.hashCode(pName);
>> 
>> Best regards,
>> Andrej Golovnin
>> 
>> 
>> 
>> 
>> On Fri, Jun 27, 2014 at 12:00 PM, Pavel Rappo  wrote:
>> I created an issue to track the progress and also made 2 webrevs. One for the original patch and one for the changes that have been suggested earlier in this thread by Paul and Andrej. Here we go:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8048267
>> 
>> http://cr.openjdk.java.net/~prappo/8048267/webrev.00
>> http://cr.openjdk.java.net/~prappo/8048267/webrev.01
>> 
>> -Pavel
>> 
>> On 26 Jun 2014, at 10:58, Chris Hegarty  wrote:
>> 
>>> Otavio,
>>> 
>>> I skimmed over the patches and they look ok to me. I think they would be suitable for inclusion in jdk9/dev.
>>> 
>>> -Chris.
>>> 
>>> P.S. I do not currently have time to sponsor this, but I cc?ed Pavel who may be able to help get his in.
>>> 
>>> On 14 Jun 2014, at 14:46, Ot?vio Gon?alves de Santana  wrote:
>>> 
>>>> Reason: The Long class has cache and using it, will save memory and will
>>>> faster than using create new instance of Long.
>>>> 
>>>> webrev:
>>>> https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip
>>>> 
>>>> similar: https://bugs.openjdk.java.net/browse/JDK-8044461
>>>> --
>>>> 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 david.dehaven at oracle.com  Fri Jun 27 16:31:52 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 27 Jun 2014 09:31:52 -0700
Subject: [9] Request for Review: 8048337: Examine if
	macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed
Message-ID: <6D33A187-0998-4904-8A69-69E75D94A296@oracle.com>


As the subject says, so examined and determined that it can indeed be removed.

The Java source was being built and included in rt.jar, but it would not run because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing the two native methods) was not being built so it would have died with an UnsatisfiedLinkError. The Xcode project is not referenced anywhere in any makefile I looked at.

Since it's not used anywhere (and appears to never have been used at all?), it should be purged from the jdk source.

JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8048337

Webrev:
http://cr.openjdk.java.net/~ddehaven/8048337/jdk.0/

-DrD-



From david.dehaven at oracle.com  Fri Jun 27 16:31:52 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 27 Jun 2014 09:31:52 -0700
Subject: [9] Request for Review: 8048337: Examine if
	macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed
Message-ID: <6D33A187-0998-4904-8A69-69E75D94A296@oracle.com>


As the subject says, so examined and determined that it can indeed be removed.

The Java source was being built and included in rt.jar, but it would not run because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing the two native methods) was not being built so it would have died with an UnsatisfiedLinkError. The Xcode project is not referenced anywhere in any makefile I looked at.

Since it's not used anywhere (and appears to never have been used at all?), it should be purged from the jdk source.

JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8048337

Webrev:
http://cr.openjdk.java.net/~ddehaven/8048337/jdk.0/

-DrD-



From mandy.chung at oracle.com  Fri Jun 27 17:30:54 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Jun 2014 10:30:54 -0700
Subject: [9] Request for Review: 8048337: Examine if
	macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed
In-Reply-To: <6D33A187-0998-4904-8A69-69E75D94A296@oracle.com>
References: <6D33A187-0998-4904-8A69-69E75D94A296@oracle.com>
Message-ID: <53ADAA4E.2070002@oracle.com>

Hi Dave,

On 6/27/2014 9:31 AM, David DeHaven wrote:
> As the subject says, so examined and determined that it can indeed be removed.

Good to see unused code be removed from the repo!

>
> The Java source was being built and included in rt.jar, but it would not run because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing the two native methods) was not being built so it would have died with an UnsatisfiedLinkError. The Xcode project is not referenced anywhere in any makefile I looked at.

I found JavaAppLauncher.o in $BUILD_OUTPUTDIR/jdk/libosx directory
(see the symbols below).  On the other hand, appLauncherErrors.properties
is needed by JavaAppLauncher but not included in the JDK image.
MissingResourceException would be thrown and such exception
should have been noticed if JavaAppLauncher is used.

As you suggest in another thread, Java packager is a better option.

> Since it's not used anywhere (and appears to never have been used at all?), it should be purged from the jdk source.
>
> JBS issue:
> https://bugs.openjdk.java.net/browse/JDK-8048337
>
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/8048337/jdk.0/

Looks good.

Mandy

$ nm $OUTPUTDIR/jdk/objs/libosx/JavaAppLauncher.o | grep launcher

0000000000000000 T _Java_apple_launcher_JavaAppLauncher_nativeConvertAndRelease
0000000000004bb8 S _Java_apple_launcher_JavaAppLauncher_nativeConvertAndRelease.eh
00000000000000c6 T _Java_apple_launcher_JavaAppLauncher_nativeInvokeNonPublic
0000000000004bf8 S _Java_apple_launcher_JavaAppLauncher_nativeInvokeNonPublic.eh



From david.dehaven at oracle.com  Fri Jun 27 17:38:53 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 27 Jun 2014 10:38:53 -0700
Subject: [9] Request for Review: 8048337: Examine if
	macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed
In-Reply-To: <53ADAA4E.2070002@oracle.com>
References: <6D33A187-0998-4904-8A69-69E75D94A296@oracle.com>
	<53ADAA4E.2070002@oracle.com>
Message-ID: <8F857678-E9B1-4F36-A3A3-7BB0DFDEF81F@oracle.com>


>> The Java source was being built and included in rt.jar, but it would not run because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing the two native methods) was not being built so it would have died with an UnsatisfiedLinkError. The Xcode project is not referenced anywhere in any makefile I looked at.
> 
> I found JavaAppLauncher.o in $BUILD_OUTPUTDIR/jdk/libosx directory
> (see the symbols below).

Ah, ok. It wasn't explicitly listed in the makefiles so I made an assumption. In any case, removing it causes no build or runtime failures that I can tell.

-DrD-



From Lance.Andersen at oracle.com  Fri Jun 27 17:40:49 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Fri, 27 Jun 2014 13:40:49 -0400
Subject: RFR : 7095856: OutputStreamHook doesn't handle null values
In-Reply-To: <53AD651C.2050304@oracle.com>
References: <53AD651C.2050304@oracle.com>
Message-ID: 

looks fine Sean

On Jun 27, 2014, at 8:35 AM, Se?n Coffey  wrote:

> Looking for a review around this CORBA issue.
> 
> bug report : https://bugs.openjdk.java.net/browse/JDK-7095856
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/
> 
> Null values cause issue when processed by an IIOPOutputStream and I can't see a reason why they wouldn't be allowed. Note that the glassfish code already employs a HashMap to hold such values. I've run CORBA SQE tests, unit tests and relevant TCK tests. No issues seen.
> 
> regards,
> Sean.




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 claes.redestad at oracle.com  Fri Jun 27 19:02:59 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 27 Jun 2014 21:02:59 +0200
Subject: RFR [9] 8041972: Add improved parse/format methods for
	Long/Integer
In-Reply-To: <167AB3E2-253B-41B5-B8DF-B6C7C7F7C16B@oracle.com>
References: <539CCE6D.6040207@oracle.com>	<539D8821.3070808@univ-mlv.fr>	<539D91A0.9050901@oracle.com>	<539E1CB4.2050502@oracle.com>	<539F4A6A.5020002@oracle.com>	<539F4FCE.9080903@oracle.com>	<53A04EE7.6090309@oracle.com>	<53A06224.1040600@oracle.com>	<53A32043.7070008@oracle.com>	<39373F79-DC28-4A51-B617-680C6C508538@oracle.com>	<53AC5007.30603@oracle.com>
	<167AB3E2-253B-41B5-B8DF-B6C7C7F7C16B@oracle.com>
Message-ID: <53ADBFE3.50702@oracle.com>

Hi,

  updated webrev:http://cr.openjdk.java.net/~redestad/8041972/webrev.11

  Changes:
  - Remove use of IllegalArgumentException in favor of 
IndexOutOfBoundsException/NumberFormatException, making the new methods 
behave in line with how String.substring wouldat some edge cases: 
"100".substring(3)equals "", thus Integer.parseInt("100", 10, 3) now 
throw NumberFormatException, while Integer.parseInt("100", 10, 
4)/"100".substring(4) will throw IOOB.
  - For performance reasons the old and new methodshave been split 
apart. This introduces some code duplication, but removes the need to 
add special checks in some places.
  - Added more tests

/Claes

On 06/27/2014 10:54 AM, Paul Sandoz wrote:
> On Jun 26, 2014, at 6:53 PM, Claes Redestad  wrote:
>
>> On 06/25/2014 06:43 PM, Paul Sandoz wrote:
>>> On Jun 19, 2014, at 7:39 PM, Claes Redestad  wrote:
>>>> Hi,
>>>>
>>>> an updated webrev with reworked, public methods is available here:
>>>> http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
>>>>
>>>> Reviews are yet again appreciated!
>>>>
>>> I think "if (s == null)" or "Objects.requireNonNull(s)" is preferable to s.getClass(). (I am informed by those more knowledgeable than i that the latter also has poorer performance in the client compiler.)
>> Agreed. Using s.getClass() was necessitated to retain performance using default compiler (-XX:+TieredCompilation) in the microbenchmarks I've been using, and going back to testing with C1 (via means of -XX:TieredStartAtLevel=1-3), it's apparent that the patch can cause a regression with the client compiler that I hadn't checked.It even looks like C2 alone (-XX:-TieredCompilation) suffers slightly.
>>
>> Changing to Objects.requireNonNull doesn't seem to make things better, though. Rather the regression seem to be due to C1 (and in some ways even C2) not dealing very well with the increased degrees of freedoms in the new methods, so I'm currently considering splitting apart the implementations to keep the old implementations of parseX(String[, int]) untouched while duplicating some code to build the new methods. Ugly, but I guess it's anecessary evil here.
>>
> Ok.  Perhaps it might be possible to place the specifics of constraint checking in public methods, but they defer to a general private method that can assume it's arguments are safe (or such arguments are checked by other method calls e.g. CS.charAt)
>
>
>>> Related to the above, it might be preferable to retain the existing semantics of throwing NumberFormatException on a null string value, since someone might switch between parseInt(String ) and parseInt(String, int, int, int) and the null will then slip through the catch of NumberFormatException.
>> Consider Integer.parseInt(s.substring(1)) and Integer.parseInt(s, 10, 1): the first would throw NullPointerException currently if s == null, while the latter instead would start throwing NumberFormatException. I think we should favor throwing a NPE here. I'd argue that the risk that someone changes to any of the range-based alternatives when they aren't replacing a call to substring or similar are slim to none.
>>
> A good point.
>
>
>>> You could just use IndexOutOfBoundsException for the case of beginIndex < 0 and beginIndex >= endIndex and endIndex > s.length(), as is similarly the case for String.substring. Again, like previously, switching between parseInt(String, int, int) parseInt(String, int, int, int) requires no additional catching. You might want to add a comment in the code that some IndexOutOfBoundsException exceptions are implicit via calls to s.charAt (i did a double take before realizing :-) ).
>> Fair points. I could argue String.substring(int, int), StringBuilder.append(CharSequence, int, int)etc are wrong, but I guess that might be a losing battle. :-)
>>
> Right, if we were starting again it might be different but i think consistency is important.
>
>
>>> Integer.requireNonEmpty could be a static package private method on String (or perhaps even static public, it seems useful), plus i would not bother with the static import in this case.
>> The requireNonEmpty throws NumberFormatException to keep compatibility with the old methods, so it wouldn't make much sense to add that to String.
> Doh! what was i thinking. If it stays perhaps place it as a package private method on Number.
>
>
>> If I split the parseX(String... and parseX(CharSequence... implementations as I intend to, this method will be redundant though.
>>
> Ok.
>
> Paul.



From coleen.phillimore at oracle.com  Fri Jun 27 19:24:04 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 27 Jun 2014 15:24:04 -0400
Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class
Message-ID: <53ADC4D4.4030403@oracle.com>

Summary: Add field in java.lang.Class for componentType to simplify oop 
processing and intrinsics in JVM

This is part of ongoing work to clean up oop pointers in the metadata 
and simplify the interface between the JDK j.l.C and the JVM.  There's a 
performance benefit at the end of all of this if we can remove all oop 
pointers from metadata.   mirror in Klass is the only one left after 
this full change.

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

There are a couple steps to this change because Hotspot testing is done 
with promoted JDKs.  The first step is this webrev:

http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/

When the JDK is promoted, the code to remove 
ArrayKlass::_component_mirror will be changed under a new bug id.

http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full

Finally, a compatibility request and licensee notification will occur to 
remove the function JVM_GetComponentType.

Performance testing was done that shows no difference in performance.  
The isArray() call is a compiler intrinsic which is now called instead 
of getComponentType, which was recognized as a compiler intrinsic.

JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8 
tests were performed on both the change requested (1st one) and the full 
change.

hotspot NSK tests were run on the hotspot-only change with a promoted JDK.

Please send your comments.

Thanks,
Coleen


From andrej.golovnin at gmail.com  Fri Jun 27 20:16:27 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 27 Jun 2014 22:16:27 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: <7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
Message-ID: <846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>

Hi Pavel,

I'm not sure what the style guide for the source code says, but
there is a space between the cast operator and the field name in
src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java (line 881):

     @Override
     public Long getSnmpOutGenErrs() {
-        return new Long(snmpOutGenErrs);
+        return (long) snmpOutGenErrs;

     }

In all other changes there is no space after the cast operator.


> Also, I removed one useless creation of a Long object here:
> 
> (line 191):
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html

And I have found one more :-) in KerberosTime.java:

252     public int getSeconds() {
253         Long temp_long = kerberosTime / 1000L;
254         return temp_long.intValue();
255     }

This can be changed to:

252     public int getSeconds() {
253         long temp_long = kerberosTime / 1000L;
254         return (int) temp_long;
255     }


> 
> I wonder if we should leave a cast to int here:
> 
> (line 383):
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> 
> Well it's probably nothing to worry about, but strictly speaking this changes the behaviour. Before the change, long was truncated to fit int. And now it's not.

I would not change the behavior now. I think it is better to file a new issue and change
it in a separate commit. Having this change in a separate commit may simplify tracking
this change back in case it would cause some problems (I don't believe it).
And in the new issue you may provide better description for this change.

And a minor comment for JvmMemoryImpl.java:
Maybe it is better to use Long0 in the line 387. So the code of the method 
JvmMemoryImpl.getJvmMemoryPendingFinalCount() will look similar to the code
of other methods in the JvmMemoryImpl class. They all use the Long0 constant
to return 0L.

In sun/management/snmp/jvminstr/JvmThreadingImpl.java in the line 313:

312     public Long getJvmThreadPeakCount() throws SnmpStatusException {
313         return  (long)getThreadMXBean().getPeakThreadCount();
314     }

There is one space too much between "return" and the cast operator. The additional space
was in the original version too, but maybe we can clean up here the code a little bit.

> 
> P.S. Andrej, it looks like you don't have an 'Author' status. Well, that's a pity. We could mention you in the 'Reviewed-by' line. Your contributions are really good.

Thanks! But I don't really care about it as long as I can help to improve the overall code quality.

Best regards,
Andrej Golovnin



From henry.jen at oracle.com  Fri Jun 27 21:45:33 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 27 Jun 2014 14:45:33 -0700
Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx specific
	code
Message-ID: <53ADE5FD.20305@oracle.com>

Hi,

Please review a webrev for fixing rawtypes and unchecked lint warning 
for macosx specific java code, this webrev is depending on 
JDK-8043548[1] where some of the override methods are defined,

Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to be 
removed from JDK-8048337, the webrev omits that file.

The webrev can be found at,
http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/


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

Cheers,
Henry


From joe.darcy at oracle.com  Fri Jun 27 22:00:11 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 27 Jun 2014 15:00:11 -0700
Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx
	specific code
In-Reply-To: <53ADE5FD.20305@oracle.com>
References: <53ADE5FD.20305@oracle.com>
Message-ID: <53ADE96B.8070904@oracle.com>

Hi Henry,

Your changes look good to me (I assume there was an issue using 
wildcards in AquaComboBoxButton.java).

Thanks,

-Joe

On 06/27/2014 02:45 PM, Henry Jen wrote:
> Hi,
>
> Please review a webrev for fixing rawtypes and unchecked lint warning 
> for macosx specific java code, this webrev is depending on 
> JDK-8043548[1] where some of the override methods are defined,
>
> Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to 
> be removed from JDK-8048337, the webrev omits that file.
>
> The webrev can be found at,
> http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8043548
>
> Cheers,
> Henry



From otaviojava at java.net  Fri Jun 27 23:09:07 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Fri, 27 Jun 2014 20:09:07 -0300
Subject: Long valueOf instead of new Long
In-Reply-To: <846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
	<846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
Message-ID: 

I found more two unnecessary valueOf.
About Andrej, is it not possible add two people in "Contributed-by:" tag?

diff -r d02b062bc827
src/share/classes/com/sun/tools/example/debug/tty/Commands.java
--- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Fri
Jun 13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Fri
Jun 27 20:06:28 2014 -0300
@@ -935,7 +935,7 @@
             try {
                 methodInfo = loc.sourceName() +
                     MessageOutput.format("line number",
-                                         new Object [] {new
Long(lineNumber)});
+                                         new Object [] {lineNumber});
             } catch (AbsentInformationException e) {
                 methodInfo = MessageOutput.format("unknown");
             }
@@ -946,7 +946,7 @@

meth.declaringType().name(),
                                                  meth.name(),
                                                  methodInfo,
-                                                 new Long(pc)});
+                                                 pc});
         } else {
             MessageOutput.println("stack frame dump",
                                   new Object [] {new Integer(frameNumber +
1),


On Fri, Jun 27, 2014 at 5:16 PM, Andrej Golovnin 
wrote:

> Hi Pavel,
>
> I'm not sure what the style guide for the source code says, but
> there is a space between the cast operator and the field name in
> src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java (line
> 881):
>
>      @Override
>      public Long getSnmpOutGenErrs() {
> -        return new Long(snmpOutGenErrs);
> +        return (long) snmpOutGenErrs;
>
>      }
>
> In all other changes there is no space after the cast operator.
>
>
> > Also, I removed one useless creation of a Long object here:
> >
> > (line 191):
> >
> >
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
> >
> http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
>
> And I have found one more :-) in KerberosTime.java:
>
> 252     public int getSeconds() {
> 253         Long temp_long = kerberosTime / 1000L;
> 254         return temp_long.intValue();
> 255     }
>
> This can be changed to:
>
> 252     public int getSeconds() {
> 253         long temp_long = kerberosTime / 1000L;
> 254         return (int) temp_long;
> 255     }
>
>
> >
> > I wonder if we should leave a cast to int here:
> >
> > (line 383):
> >
> >
> http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> >
> http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> >
> > Well it's probably nothing to worry about, but strictly speaking this
> changes the behaviour. Before the change, long was truncated to fit int.
> And now it's not.
>
> I would not change the behavior now. I think it is better to file a new
> issue and change
> it in a separate commit. Having this change in a separate commit may
> simplify tracking
> this change back in case it would cause some problems (I don't believe it).
> And in the new issue you may provide better description for this change.
>
> And a minor comment for JvmMemoryImpl.java:
> Maybe it is better to use Long0 in the line 387. So the code of the method
> JvmMemoryImpl.getJvmMemoryPendingFinalCount() will look similar to the code
> of other methods in the JvmMemoryImpl class. They all use the Long0
> constant
> to return 0L.
>
> In sun/management/snmp/jvminstr/JvmThreadingImpl.java in the line 313:
>
> 312     public Long getJvmThreadPeakCount() throws SnmpStatusException {
> 313         return  (long)getThreadMXBean().getPeakThreadCount();
> 314     }
>
> There is one space too much between "return" and the cast operator. The
> additional space
> was in the original version too, but maybe we can clean up here the code a
> little bit.
>
> >
> > P.S. Andrej, it looks like you don't have an 'Author' status. Well,
> that's a pity. We could mention you in the 'Reviewed-by' line. Your
> contributions are really good.
>
> Thanks! But I don't really care about it as long as I can help to improve
> the overall code quality.
>
> Best regards,
> Andrej Golovnin
>
>


-- 
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 henry.jen at oracle.com  Sat Jun 28 05:57:52 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 27 Jun 2014 22:57:52 -0700
Subject: RFR: 8044862: Fix raw and unchecked lint warnings in macosx
	specific code
In-Reply-To: <53ADE96B.8070904@oracle.com>
References: <53ADE5FD.20305@oracle.com> <53ADE96B.8070904@oracle.com>
Message-ID: 

?
On June 27, 2014 at 3:00:13 PM, Joe Darcy (joe.darcy at oracle.com(mailto:joe.darcy at oracle.com)) wrote:
> Hi Henry,
>  
> Your changes look good to me (I assume there was an issue using
> wildcards in AquaComboBoxButton.java).
>  

Cannot make it to work. The problematic code is in line 169,  

?169 ? ? ? ? final ListCellRenderer renderer = comboBox.getRenderer();
?170?
?171 ? ? ? ? // fake it out! not renderPressed
?172 ? ? ? ? final Component c = renderer.getListCellRendererComponent(list, comboBox.getSelectedItem(), -1, false, false);


The above code involve following two APIs,
ListCellRenderer?JComboBox::getRenderer();  
Component ListCellRenderer::getListCellRendererComponent(JList?list, E value, int index, boolean isSelected, boolean cellHasFocus);

Feels like ? extends Object should work, but javac still complains,

?/Users/henryjen/ws/9dev/jdk/src/macosx/classes/com/apple/laf/AquaComboBoxButton.java:169: error: incompatible types: ListCellRenderer cannot be converted to ListCellRender ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  
? ? ? ? ?final ListCellRenderer renderer = comboBox.getRenderer();
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ ? ? ? ? ? ?
? ?where CAP#1,CAP#2 are fresh type-variables: ? ? ? ? ? ? ?
? ? ?CAP#1 extends Object super: CAP#2 from capture of ? super CAP#2 ? ? ? ? ? ? ??
? ? ?CAP#2 extends Object from capture of ? extends Object

Cheers,
Henry

> Thanks,
>  
> -Joe
>  
> On 06/27/2014 02:45 PM, Henry Jen wrote:
> > Hi,
> >
> > Please review a webrev for fixing rawtypes and unchecked lint warning
> > for macosx specific java code, this webrev is depending on
> > JDK-8043548[1] where some of the override methods are defined,
> >
> > Also as the src/macosx/classes/apple/launcher/JavaAppLauncher.java to
> > be removed from JDK-8048337, the webrev omits that file.
> >
> > The webrev can be found at,
> > http://cr.openjdk.java.net/~henryjen/jdk9/8044862/0/webrev/
> >
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8043548
> >
> > Cheers,
> > Henry
>  



From kasperni at gmail.com  Sat Jun 28 15:40:13 2014
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sat, 28 Jun 2014 17:40:13 +0200
Subject: Streams and Spliterator characteristics confusion
In-Reply-To: 
References: 
	
Message-ID: 

Thanks,

followup questions inlined.

On Fri, Jun 27, 2014 at 11:43 AM, Paul Sandoz 
wrote:

> Internally in the stream pipeline we keep track of certain characteristics
> for optimization purposes and those are conveniently used to determine the
> characteristics of the Spliterator, so there are some idiosyncrasies poking
> through.
>
>
> > s.sorted().spliterator() -> Spliterator.SORTED = true
> > But if I use specify a comparator the stream is not sorted
> > s.sorted((a,b) -> 1).spliterator() -> Spliterator.SORTED = false
> >
>
> Right, there is an optimization internally that ensures if the upstream
> stream is already sorted than the sort operation becomes a nop e.g.
>
>   s.sorted().sorted();
>
> This optimization cannot apply when a comparator is passed in since we
> don't know if two comparators are identical in their behaviour e.g:
>
>   s.sorted((a, b) ->
> a.compareTo(b)).sorted(Compatators.naturalOrder()).sorted()
>
>
What initially made me wonder was the javadoc of
Spliterator#getComparator()
which list "If this Spliterator's source is SORTED by a Comparator returns
that Comparator."

So I assumed s.sorted((a,b) -> 1).spliterator().getComparator() would
return said comparator.

It just feels a bit inconsistent compared to, for example, new
TreeMap(comparator).keyset().spliterator()
which returns Spliterator.SORTED = true and a comparator.


>
> > s.distinct().spliterator() -> Spliterator.DISTINCT = true
> > but limiting the number of distinct elements makes the stream non
> distinct
> > s.distinct().limit(10).spliterator() -> Spliterator.DISTINCT = false
>
> I don't observe that (see program below).

Right, that was an error on my part.

But still, I think some there are some cases where the flag should be
maintained.
For example, I think following the following program should print 4 'true'
values but it only prints 1.
Especially the second one puzzles me, invoking distinct() makes it
non-distinct?

static IntStream s() {
  return StreamSupport.intStream(Spliterators.spliterator(new int[] { 12,
34 }, Spliterator.DISTINCT), false);
}

public static void main(String[] args) {

 System.out.println(s().spliterator().hasCharacteristics(Spliterator.DISTINCT));

 System.out.println(s().distinct().spliterator().hasCharacteristics(Spliterator.DISTINCT));

 System.out.println(s().boxed().spliterator().hasCharacteristics(Spliterator.DISTINCT));

 System.out.println(s().asDoubleStream().spliterator().hasCharacteristics(Spliterator.DISTINCT));
}



>
> > On the other hand something like Spliterator.SORTED is maintained when I
> > invoke limit
> > s.sorted().limit(10).spliterator() -> Spliterator.SORTED = true
> >
> >
> > A flag such as Spliterator.NONNULL is also cleared in situations where it
> > should not be.
>
> That is because it is not tracked in the pipeline as there is no gain
> optimisation-wise (if it was it would be cleared for map/flatMap operations
> and preserved for other ops like filter as you say below).
>
 It's not that difficult to support this and should add no measurable
> performance cost, we deliberately left space in the bit fields, however
> since spliterator() is an escape-hatch for doing stuff that cannot be done
> by other operations i think the value of supporting NONULL is marginal.
>
>
I am trying to implement the stream interfaces and I want to make sure that
my implementation have similar behaviour as the default implementation in
java.util.stream. The interoperability between streams and
Spliterator.characteristics is the only thing I'm having serious issues
with. I feel the current state is more a result of how streams are
implemented at the moment then as part of a public API.

I think something like a table with non-terminal stream operations as rows
and characteristics as columns. Where each cell was either: "cleared",
"set" or "maintained" would make sense.

Cheers
  Kasper


From henry.jen at oracle.com  Mon Jun 30 01:30:08 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Sun, 29 Jun 2014 18:30:08 -0700
Subject: RFR: 8047722: @since tag cleanup in corba
In-Reply-To: <53A4A789.6040609@oracle.com>
References: <53A4A789.6040609@oracle.com>
Message-ID: <53B0BDA0.9070004@oracle.com>

Ping.

Cheers,
Henry

On 06/20/2014 02:28 PM, Henry Jen wrote:
> Hi,
>
> Please review a trivial webrev for jdk9/corba that do the same @since
> tag normalization as in jdk9/jdk.
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/
>
> Cheers,
> Henry


From henry.jen at oracle.com  Mon Jun 30 01:30:19 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Sun, 29 Jun 2014 18:30:19 -0700
Subject: RFR: 8047724: @since tag cleanup in jaxws
In-Reply-To: <53A4AA6D.9060204@oracle.com>
References: <53A4AA6D.9060204@oracle.com>
Message-ID: <53B0BDAB.2070402@oracle.com>

Ping.

Cheers,
Henry

On 06/20/2014 02:41 PM, Henry Jen wrote:
> Hi,
>
> Please review a trivial webrev for jdk9/jaxws that do the same @since
> tag normalization as in jdk9/jdk.
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8047724/0/webrev/
>
> I am not sure if there is another mailing list thatis more appropriate
> for this, if so, please direct me to the right ml. Thanks.
>
> Cheers,
> Henry


From david.holmes at oracle.com  Mon Jun 30 05:55:59 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jun 2014 15:55:59 +1000
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53ADC4D4.4030403@oracle.com>
References: <53ADC4D4.4030403@oracle.com>
Message-ID: <53B0FBEF.5030607@oracle.com>

Hi Coleen,

Your webrev links are to internal locations.

David

On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
> Summary: Add field in java.lang.Class for componentType to simplify oop
> processing and intrinsics in JVM
>
> This is part of ongoing work to clean up oop pointers in the metadata
> and simplify the interface between the JDK j.l.C and the JVM.  There's a
> performance benefit at the end of all of this if we can remove all oop
> pointers from metadata.   mirror in Klass is the only one left after
> this full change.
>
> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>
> There are a couple steps to this change because Hotspot testing is done
> with promoted JDKs.  The first step is this webrev:
>
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>
> When the JDK is promoted, the code to remove
> ArrayKlass::_component_mirror will be changed under a new bug id.
>
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>
> Finally, a compatibility request and licensee notification will occur to
> remove the function JVM_GetComponentType.
>
> Performance testing was done that shows no difference in performance.
> The isArray() call is a compiler intrinsic which is now called instead
> of getComponentType, which was recognized as a compiler intrinsic.
>
> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
> tests were performed on both the change requested (1st one) and the full
> change.
>
> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>
> Please send your comments.
>
> Thanks,
> Coleen


From Alan.Bateman at oracle.com  Mon Jun 30 07:14:19 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jun 2014 08:14:19 +0100
Subject: RFR: 8047724: @since tag cleanup in jaxws
In-Reply-To: <53B0BDAB.2070402@oracle.com>
References: <53A4AA6D.9060204@oracle.com> <53B0BDAB.2070402@oracle.com>
Message-ID: <53B10E4B.7070607@oracle.com>

On 30/06/2014 02:30, Henry Jen wrote:
> Ping.
>
> Cheers,
> Henry
Henry - the code in the jaxws repository is maintained upstream. If you 
change it in the jaxws repository then the changes will likely get 
overridden at the next sync-up. I'd suggest working with Miroslav 
(cc'ed) to get the changes pushed upstream first.

-Alan.


From Alan.Bateman at oracle.com  Mon Jun 30 07:18:54 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jun 2014 08:18:54 +0100
Subject: RFR: 8047722: @since tag cleanup in corba
In-Reply-To: <53B0BDA0.9070004@oracle.com>
References: <53A4A789.6040609@oracle.com> <53B0BDA0.9070004@oracle.com>
Message-ID: <53B10F5E.3010005@oracle.com>

On 30/06/2014 02:30, Henry Jen wrote:
> Ping.
>
> :
>
> On 06/20/2014 02:28 PM, Henry Jen wrote:
>> Hi,
>>
>> Please review a trivial webrev for jdk9/corba that do the same @since
>> tag normalization as in jdk9/jdk.
>>
>> http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/
There are bunch of @since JDK 1.0 and JDK 1.1.6 that you are changing to 
1.0 and 1.1.6. AFAIK, CORBA was added in 1.2 and I wonder if we should 
fix this as part of this change.

-Alan


From andrej.golovnin at gmail.com  Mon Jun 30 07:41:35 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Mon, 30 Jun 2014 09:41:35 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
	<846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
	
Message-ID: 

Hi Ot?vio,

About Andrej, is it not possible add two people in "Contributed-by:" tag?
>

Thanks! But it's not needed. It's your contribution. I just help to review
the changes.

Best regards,
Andrej Golovnin


From paul.sandoz at oracle.com  Mon Jun 30 09:34:41 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Jun 2014 11:34:41 +0200
Subject: Streams and Spliterator characteristics confusion
In-Reply-To: 
References: 
	
	
Message-ID: <6DEE514D-CDA4-4585-B507-D5E23CAB0E0E@oracle.com>

On Jun 28, 2014, at 5:40 PM, Kasper Nielsen  wrote:

> 
> > s.distinct().spliterator() -> Spliterator.DISTINCT = true
> > but limiting the number of distinct elements makes the stream non distinct
> > s.distinct().limit(10).spliterator() -> Spliterator.DISTINCT = false
> 
> I don't observe that (see program below).
> Right, that was an error on my part.
> 
> But still, I think some there are some cases where the flag should be maintained.
> For example, I think following the following program should print 4 'true' values but it only prints 1.
> Especially the second one puzzles me, invoking distinct() makes it non-distinct?
> 
> static IntStream s() {
>   return StreamSupport.intStream(Spliterators.spliterator(new int[] { 12, 34 }, Spliterator.DISTINCT), false);
> }
> 
> public static void main(String[] args) {
>    System.out.println(s().spliterator().hasCharacteristics(Spliterator.DISTINCT));
>    System.out.println(s().distinct().spliterator().hasCharacteristics(Spliterator.DISTINCT));
>    System.out.println(s().boxed().spliterator().hasCharacteristics(Spliterator.DISTINCT));
>    System.out.println(s().asDoubleStream().spliterator().hasCharacteristics(Spliterator.DISTINCT));
> }
> 

The second is a good example as to why this is an implementation detail, here is the implementation (some may want to close their eyes!):

    public final IntStream distinct() {
        // While functional and quick to implement, this approach is not very efficient.
        // An efficient version requires an int-specific map/set implementation.
        return boxed().distinct().mapToInt(i -> i);
    }

We could work out how to inject back in distinct but since the spliterator is intended as an escape hatch i did not think it worth the effort.

Note if the latter source was a a long stream it would not be able to inject DISTINCT because not all long values can be represented precisely as double values.
 

>  
> I am trying to implement the stream interfaces and I want to make sure that my implementation have similar behaviour as the default implementation in java.util.stream. The interoperability between streams and Spliterator.characteristics is the only thing I'm having serious issues with. I feel the current state is more a result of how streams are implemented at the moment then as part of a public API.
> 
> I think something like a table with non-terminal stream operations as rows and characteristics as columns. Where each cell was either: "cleared", "set" or "maintained" would make sense.
> 

We deliberately did not specify this aspect, the implementation could change and we don't want to unduly constrain it based on an escape-hatch (it's not the common case). Implementations can decide to what extent the quality is of that escape-hatch spliterator. For your implementation you are free to provide better quality escape-hatch spliterators.

I think we should clarify the documentation on BaseStream.spliterator() to say something like:

  The characteristics of the returned spliterator need not correlate with characteristics of the stream source
  and those inferred from intermediate operations proceeding this terminal operation.

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

I have also logged the following issues :

  Spliterator.NONNULL
  https://bugs.openjdk.java.net/browse/JDK-8048690

  ~ORDERED & SORTED
  https://bugs.openjdk.java.net/browse/JDK-8048691

Thanks,
Paul.


From pavel.rappo at oracle.com  Mon Jun 30 10:11:25 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 30 Jun 2014 11:11:25 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
	<846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
	
Message-ID: <552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com>

I've updated the webrev. It includes all the changes we've discussed so far plus these:

http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/macosx/classes/sun/font/CStrike.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/solaris/classes/java/util/prefs/FileSystemPreferences.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java.sdiff.html

Andrej, about the 0L -> Long0 change. I think it's not necessary since this case is *maybe* different from others. There's even a comment on it:

        // Should never happen... but stay safe all the same.
        //
        else return 0L;

Anyway at a runtime 0L and Long0 will be the same object. So don't worry about that.

I think we're almost ready to go.

Thanks,
-Pavel

On 28 Jun 2014, at 00:09, Ot?vio Gon?alves de Santana  wrote:

> I found more two unnecessary valueOf.
> About Andrej, is it not possible add two people in "Contributed-by:" tag?
> 
> diff -r d02b062bc827 src/share/classes/com/sun/tools/example/debug/tty/Commands.java
> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java	Fri Jun 13 11:21:30 2014 -0700
> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java	Fri Jun 27 20:06:28 2014 -0300
> @@ -935,7 +935,7 @@
>              try {
>                  methodInfo = loc.sourceName() +
>                      MessageOutput.format("line number",
> -                                         new Object [] {new Long(lineNumber)});
> +                                         new Object [] {lineNumber});
>              } catch (AbsentInformationException e) {
>                  methodInfo = MessageOutput.format("unknown");
>              }
> @@ -946,7 +946,7 @@
>                                                   meth.declaringType().name(),
>                                                   meth.name(),
>                                                   methodInfo,
> -                                                 new Long(pc)});
> +                                                 pc});
>          } else {
>              MessageOutput.println("stack frame dump",
>                                    new Object [] {new Integer(frameNumber + 1),
> 
> 
> On Fri, Jun 27, 2014 at 5:16 PM, Andrej Golovnin  wrote:
> Hi Pavel,
> 
> I'm not sure what the style guide for the source code says, but
> there is a space between the cast operator and the field name in
> src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java (line 881):
> 
>      @Override
>      public Long getSnmpOutGenErrs() {
> -        return new Long(snmpOutGenErrs);
> +        return (long) snmpOutGenErrs;
> 
>      }
> 
> In all other changes there is no space after the cast operator.
> 
> 
> > Also, I removed one useless creation of a Long object here:
> >
> > (line 191):
> >
> > http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
> > http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
> 
> And I have found one more :-) in KerberosTime.java:
> 
> 252     public int getSeconds() {
> 253         Long temp_long = kerberosTime / 1000L;
> 254         return temp_long.intValue();
> 255     }
> 
> This can be changed to:
> 
> 252     public int getSeconds() {
> 253         long temp_long = kerberosTime / 1000L;
> 254         return (int) temp_long;
> 255     }
> 
> 
> >
> > I wonder if we should leave a cast to int here:
> >
> > (line 383):
> >
> > http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> > http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
> >
> > Well it's probably nothing to worry about, but strictly speaking this changes the behaviour. Before the change, long was truncated to fit int. And now it's not.
> 
> I would not change the behavior now. I think it is better to file a new issue and change
> it in a separate commit. Having this change in a separate commit may simplify tracking
> this change back in case it would cause some problems (I don't believe it).
> And in the new issue you may provide better description for this change.
> 
> And a minor comment for JvmMemoryImpl.java:
> Maybe it is better to use Long0 in the line 387. So the code of the method
> JvmMemoryImpl.getJvmMemoryPendingFinalCount() will look similar to the code
> of other methods in the JvmMemoryImpl class. They all use the Long0 constant
> to return 0L.
> 
> In sun/management/snmp/jvminstr/JvmThreadingImpl.java in the line 313:
> 
> 312     public Long getJvmThreadPeakCount() throws SnmpStatusException {
> 313         return  (long)getThreadMXBean().getPeakThreadCount();
> 314     }
> 
> There is one space too much between "return" and the cast operator. The additional space
> was in the original version too, but maybe we can clean up here the code a little bit.
> 
> >
> > P.S. Andrej, it looks like you don't have an 'Author' status. Well, that's a pity. We could mention you in the 'Reviewed-by' line. Your contributions are really good.
> 
> Thanks! But I don't really care about it as long as I can help to improve the overall code quality.
> 
> Best regards,
> Andrej Golovnin
> 
> 
> 
> 
> -- 
> 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 andrej.golovnin at gmail.com  Mon Jun 30 10:31:08 2014
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Mon, 30 Jun 2014 12:31:08 +0200
Subject: Long valueOf instead of new Long
In-Reply-To: <552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com>
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
	<846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
	
	<552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com>
Message-ID: 

Hi Pavel,

http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java.sdiff.html
>
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java.sdiff.html
>
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java.sdiff.html
>
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java.sdiff.html


Please don't change the UnsafeXXXFieldAccessorImpl classes.
This classes should be changed as a part of the fix of the issue 5043030.
The patch for this issue has been already submitted, see here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027311.html

When Joel is back, he will continue to work on it.

Otherwise it looks good to me.

Best regards,
Andrej Golovnin


From pavel.rappo at oracle.com  Mon Jun 30 12:04:13 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 30 Jun 2014 13:04:13 +0100
Subject: Long valueOf instead of new Long
In-Reply-To: 
References: 
	
	
	
	
	<7A0B9548-639A-4726-9C3B-5B3CC1F35B96@oracle.com>
	<846BB379-4FCA-4D76-8E54-714A4E7D6D4D@gmail.com>
	
	<552050AC-8FB3-42F5-BA34-D39B136EFE2F@oracle.com>
	
Message-ID: <03AA424B-4B0B-4A10-8994-022767F3CB0D@oracle.com>

If a test run finishes fine, I'll push this version (no Unsafe*LongFieldFieldAccessorImpl.java files included):

http://cr.openjdk.java.net/~prappo/8048267/webrev.04/

-Pavel

On 30 Jun 2014, at 11:31, Andrej Golovnin  wrote:

> Hi Pavel,
> 
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java.sdiff.html
> http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java.sdiff.html
> 
> Please don't change the UnsafeXXXFieldAccessorImpl classes.
> This classes should be changed as a part of the fix of the issue 5043030.
> The patch for this issue has been already submitted, see here:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027311.html
> 
> When Joel is back, he will continue to work on it.
> 
> Otherwise it looks good to me.
> 
> Best regards,
> Andrej Golovnin



From coleen.phillimore at oracle.com  Mon Jun 30 12:42:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 08:42:56 -0400
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53B0FBEF.5030607@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
Message-ID: <53B15B50.6070405@oracle.com>


On 6/30/14, 1:55 AM, David Holmes wrote:
> Hi Coleen,
>
> Your webrev links are to internal locations.

Sorry, I cut/pasted the wrong links.  They are:

http://cr.openjdk.java.net/~coleenp/8047737_jdk/
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/

and the full version

http://cr.openjdk.java.net/~coleenp/8047737_hotspot/

Thank you for pointing this out David.

Coleen

>
> David
>
> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>> Summary: Add field in java.lang.Class for componentType to simplify oop
>> processing and intrinsics in JVM
>>
>> This is part of ongoing work to clean up oop pointers in the metadata
>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>> performance benefit at the end of all of this if we can remove all oop
>> pointers from metadata.   mirror in Klass is the only one left after
>> this full change.
>>
>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>
>> There are a couple steps to this change because Hotspot testing is done
>> with promoted JDKs.  The first step is this webrev:
>>
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>
>> When the JDK is promoted, the code to remove
>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>
>> Finally, a compatibility request and licensee notification will occur to
>> remove the function JVM_GetComponentType.
>>
>> Performance testing was done that shows no difference in performance.
>> The isArray() call is a compiler intrinsic which is now called instead
>> of getComponentType, which was recognized as a compiler intrinsic.
>>
>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>> tests were performed on both the change requested (1st one) and the full
>> change.
>>
>> hotspot NSK tests were run on the hotspot-only change with a promoted 
>> JDK.
>>
>> Please send your comments.
>>
>> Thanks,
>> Coleen



From frederic.parain at oracle.com  Mon Jun 30 14:27:11 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 30 Jun 2014 16:27:11 +0200
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53B15B50.6070405@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
	<53B15B50.6070405@oracle.com>
Message-ID: <53B173BF.2060604@oracle.com>



On 30/06/2014 14:42, Coleen Phillimore wrote:
>
> On 6/30/14, 1:55 AM, David Holmes wrote:
>> Hi Coleen,
>>
>> Your webrev links are to internal locations.
>
> Sorry, I cut/pasted the wrong links.  They are:
>
> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/

First step looks good.

> and the full version
>
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/

The correct link to the full version seems to be:
http://cr.openjdk.java.net/~coleenp/8047737_hotspot_full/

I haven't reviewed the full version yet.

Fred

> Thank you for pointing this out David.
>
> Coleen
>
>>
>> David
>>
>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>> processing and intrinsics in JVM
>>>
>>> This is part of ongoing work to clean up oop pointers in the metadata
>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>> performance benefit at the end of all of this if we can remove all oop
>>> pointers from metadata.   mirror in Klass is the only one left after
>>> this full change.
>>>
>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>
>>> There are a couple steps to this change because Hotspot testing is done
>>> with promoted JDKs.  The first step is this webrev:
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>
>>> When the JDK is promoted, the code to remove
>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>
>>> Finally, a compatibility request and licensee notification will occur to
>>> remove the function JVM_GetComponentType.
>>>
>>> Performance testing was done that shows no difference in performance.
>>> The isArray() call is a compiler intrinsic which is now called instead
>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>
>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>> tests were performed on both the change requested (1st one) and the full
>>> change.
>>>
>>> hotspot NSK tests were run on the hotspot-only change with a promoted
>>> JDK.
>>>
>>> Please send your comments.
>>>
>>> Thanks,
>>> Coleen
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From coleen.phillimore at oracle.com  Mon Jun 30 14:30:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 10:30:56 -0400
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53B173BF.2060604@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
	<53B15B50.6070405@oracle.com> <53B173BF.2060604@oracle.com>
Message-ID: <53B174A0.1050409@oracle.com>


Thank you, Fred, and thanks for correcting the link below.
Coleen

On 6/30/14, 10:27 AM, Frederic Parain wrote:
>
>
> On 30/06/2014 14:42, Coleen Phillimore wrote:
>>
>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> Your webrev links are to internal locations.
>>
>> Sorry, I cut/pasted the wrong links.  They are:
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> First step looks good.
>
>> and the full version
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> The correct link to the full version seems to be:
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot_full/
>
> I haven't reviewed the full version yet.
>
> Fred
>
>> Thank you for pointing this out David.
>>
>> Coleen
>>
>>>
>>> David
>>>
>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>> Summary: Add field in java.lang.Class for componentType to simplify 
>>>> oop
>>>> processing and intrinsics in JVM
>>>>
>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>> and simplify the interface between the JDK j.l.C and the JVM. 
>>>> There's a
>>>> performance benefit at the end of all of this if we can remove all oop
>>>> pointers from metadata.   mirror in Klass is the only one left after
>>>> this full change.
>>>>
>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>
>>>> There are a couple steps to this change because Hotspot testing is 
>>>> done
>>>> with promoted JDKs.  The first step is this webrev:
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>
>>>> When the JDK is promoted, the code to remove
>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>
>>>> Finally, a compatibility request and licensee notification will 
>>>> occur to
>>>> remove the function JVM_GetComponentType.
>>>>
>>>> Performance testing was done that shows no difference in performance.
>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>
>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>> tests were performed on both the change requested (1st one) and the 
>>>> full
>>>> change.
>>>>
>>>> hotspot NSK tests were run on the hotspot-only change with a promoted
>>>> JDK.
>>>>
>>>> Please send your comments.
>>>>
>>>> Thanks,
>>>> Coleen
>>
>



From henry.jen at oracle.com  Mon Jun 30 15:17:05 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 30 Jun 2014 08:17:05 -0700
Subject: RFR: 8047722: @since tag cleanup in corba
In-Reply-To: <53B10F5E.3010005@oracle.com>
References: <53A4A789.6040609@oracle.com> <53B0BDA0.9070004@oracle.com>
	<53B10F5E.3010005@oracle.com>
Message-ID: <53B17F71.1040706@oracle.com>



On 06/30/2014 12:18 AM, Alan Bateman wrote:
> On 30/06/2014 02:30, Henry Jen wrote:
>> Ping.
>>
>> :
>>
>> On 06/20/2014 02:28 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a trivial webrev for jdk9/corba that do the same @since
>>> tag normalization as in jdk9/jdk.
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/
> There are bunch of @since JDK 1.0 and JDK 1.1.6 that you are changing to
> 1.0 and 1.1.6. AFAIK, CORBA was added in 1.2 and I wonder if we should
> fix this as part of this change.
>

Thanks for review. You are correct that CORBA was added in 1.2.

My understadning to those 1.0 to 1.1.6 versions are for override 
methods, I guess the author is putting down the version of the origin.

There are several cases where @since can be ambiguous without a common 
guideline,

- An method was private or package access only made public, should 
@since denote the API availablity or the implementation?

- APIs from classed was extracted into a super class or interface in a 
later version, what should be the @since?

- Implementation of interface methods

- Override methods

Guess they are actually all the same question, does @since mean API 
availability or implementation?

For prior, interface/override methods should not carry it's own since, 
for later, it should have @since as the owner class.

Cheers,
Henry


From miroslav.kos at oracle.com  Mon Jun 30 16:22:57 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Mon, 30 Jun 2014 18:22:57 +0200
Subject: RFR: 8044656: Update JAX-WS RI integration to latest version
Message-ID: <53B18EE1.1080502@oracle.com>

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/
more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8044656

Could I ask for a review/approval?

Thanks
Miran


From huizhe.wang at oracle.com  Mon Jun 30 19:17:55 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Jun 2014 12:17:55 -0700
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
Message-ID: <53B1B7E3.2000505@oracle.com>

Hi,

This is a quick fix for a broken link in org.w3c.dom package. Also 
included is removal of unnecessary (and bad) link to jaxp api in a 
catalog class. Please review.

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

Thanks,
Joe


From Lance.Andersen at oracle.com  Mon Jun 30 19:20:32 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 30 Jun 2014 15:20:32 -0400
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <53B1B7E3.2000505@oracle.com>
References: <53B1B7E3.2000505@oracle.com>
Message-ID: <77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>

Looks OK Joe,  noticed the @since changed as well?

Best
Lance
On Jun 30, 2014, at 3:17 PM, huizhe wang  wrote:

> Hi,
> 
> This is a quick fix for a broken link in org.w3c.dom package. Also included is removal of unnecessary (and bad) link to jaxp api in a catalog class. Please review.
> 
> http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/
> 
> Thanks,
> Joe




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 huizhe.wang at oracle.com  Mon Jun 30 19:22:54 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Jun 2014 12:22:54 -0700
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>
References: <53B1B7E3.2000505@oracle.com>
	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>
Message-ID: <53B1B90E.7050208@oracle.com>


On 6/30/2014 12:20 PM, Lance Andersen wrote:
> Looks OK Joe,  noticed the @since changed as well?

Thanks for review.

Yes. The support for DOM L3 was since JDK 1.5. Previously this package 
file mentioned only DOM L2.

-Joe

>
> Best
> Lance
> On Jun 30, 2014, at 3:17 PM, huizhe wang  > wrote:
>
>> Hi,
>>
>> This is a quick fix for a broken link in org.w3c.dom package. Also 
>> included is removal of unnecessary (and bad) link to jaxp api in a 
>> catalog class. Please review.
>>
>> http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/ 
>> 
>>
>> Thanks,
>> Joe
>
>
>
> 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 Jun 30 19:26:33 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 30 Jun 2014 15:26:33 -0400
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <53B1B90E.7050208@oracle.com>
References: <53B1B7E3.2000505@oracle.com>
	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>
	<53B1B90E.7050208@oracle.com>
Message-ID: <31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>


On Jun 30, 2014, at 3:22 PM, huizhe wang  wrote:

> 
> On 6/30/2014 12:20 PM, Lance Andersen wrote:
>> Looks OK Joe,  noticed the @since changed as well?
> 
> Thanks for review. 
> 
> Yes. The support for DOM L3 was since JDK 1.5. Previously this package file mentioned only DOM L2.

OK, thank you.  Just seemed strange that the overall version was changed as I suspect L3 is compatible with L2.  I might have just indicated that L3 was added in 1.5 as the support was initially in 1.4 I believe.  I have no strong preference though
> 
> -Joe
> 
>> 
>> Best
>> Lance
>> On Jun 30, 2014, at 3:17 PM, huizhe wang  wrote:
>> 
>>> Hi,
>>> 
>>> This is a quick fix for a broken link in org.w3c.dom package. Also included is removal of unnecessary (and bad) link to jaxp api in a catalog class. Please review.
>>> 
>>> http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/
>>> 
>>> Thanks,
>>> Joe
>> 
>> 
>> 
>> 
>> 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 henry.jen at oracle.com  Mon Jun 30 19:35:46 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 30 Jun 2014 12:35:46 -0700
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>
References: <53B1B7E3.2000505@oracle.com>	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>	<53B1B90E.7050208@oracle.com>
	<31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>
Message-ID: <53B1BC12.20003@oracle.com>

On 06/30/2014 12:26 PM, Lance Andersen wrote:
>
> On Jun 30, 2014, at 3:22 PM, huizhe wang 
> wrote:
>
>>
>> On 6/30/2014 12:20 PM, Lance Andersen wrote:
>>> Looks OK Joe,  noticed the @since changed as well?
>>
>> Thanks for review.
>>
>> Yes. The support for DOM L3 was since JDK 1.5. Previously this
>> package file mentioned only DOM L2.
>
> OK, thank you.  Just seemed strange that the overall version was
> changed as I suspect L3 is compatible with L2.  I might have just
> indicated that L3 was added in 1.5 as the support was initially in
> 1.4 I believe.  I have no strong preference though

I agree with Lance here, the package itself is included in JDK since 1.4.

In case classes under this package is not properly labeled with @since 
tag, they will be considered has the same @since as package.html, then 
that would be really misleading.

Cheers,
Henry


From christian.thalinger at oracle.com  Mon Jun 30 19:50:47 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 30 Jun 2014 12:50:47 -0700
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53B15B50.6070405@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
	<53B15B50.6070405@oracle.com>
Message-ID: 

     private Class(ClassLoader loader) {
         // Initialize final field for classLoader.  The initialization value of non-null
         // prevents future JIT optimizations from assuming this final field is null.
         classLoader = loader;
+        componentType = null;
     }

Are we worried about the same optimization?

+  compute_optional_offset(_component_mirror_offset,
+                 klass_oop, vmSymbols::componentType_name(),
+                 vmSymbols::class_signature());

Is there a followup cleanup to make it non-optional?  Or, are you waiting for JPRT to be able to push hotspot and jdk changes together?

On Jun 30, 2014, at 5:42 AM, Coleen Phillimore  wrote:

> 
> On 6/30/14, 1:55 AM, David Holmes wrote:
>> Hi Coleen,
>> 
>> Your webrev links are to internal locations.
> 
> Sorry, I cut/pasted the wrong links.  They are:
> 
> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
> 
> and the full version
> 
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
> 
> Thank you for pointing this out David.
> 
> Coleen
> 
>> 
>> David
>> 
>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>> processing and intrinsics in JVM
>>> 
>>> This is part of ongoing work to clean up oop pointers in the metadata
>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>> performance benefit at the end of all of this if we can remove all oop
>>> pointers from metadata.   mirror in Klass is the only one left after
>>> this full change.
>>> 
>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>> 
>>> There are a couple steps to this change because Hotspot testing is done
>>> with promoted JDKs.  The first step is this webrev:
>>> 
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>> 
>>> When the JDK is promoted, the code to remove
>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>> 
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>> 
>>> Finally, a compatibility request and licensee notification will occur to
>>> remove the function JVM_GetComponentType.
>>> 
>>> Performance testing was done that shows no difference in performance.
>>> The isArray() call is a compiler intrinsic which is now called instead
>>> of getComponentType, which was recognized as a compiler intrinsic.
>>> 
>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>> tests were performed on both the change requested (1st one) and the full
>>> change.
>>> 
>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>>> 
>>> Please send your comments.
>>> 
>>> Thanks,
>>> Coleen
> 



From coleen.phillimore at oracle.com  Mon Jun 30 20:06:39 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 16:06:39 -0400
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: 
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
	<53B15B50.6070405@oracle.com>
	
Message-ID: <53B1C34F.5060901@oracle.com>


On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>       private Class(ClassLoader loader) {
>           // Initialize final field for classLoader.  The initialization value of non-null
>           // prevents future JIT optimizations from assuming this final field is null.
>           classLoader = loader;
> +        componentType = null;
>       }
>
> Are we worried about the same optimization?

I don't know if I was justified in worrying about the optimization in 
the first place.   Since getComponentType() is conditional, I wasn't 
worried.

But it should be consistent.  Maybe I should revert the classLoader 
constructor change, now that I fixed all the tests not to care. What do 
people think?
>
> +  compute_optional_offset(_component_mirror_offset,
> +                 klass_oop, vmSymbols::componentType_name(),
> +                 vmSymbols::class_signature());
>
> Is there a followup cleanup to make it non-optional?  Or, are you 
> waiting for JPRT to be able to push hotspot and jdk changes together?

Yes, please look at the _full webrev.  That has the non-optional changes 
in it and the follow on changes to remove getComponentType as an 
intrinsic in C2 (will file new RFE).  I really would like a compiler 
person to comment on it.

Thanks so much,
Coleen

>
> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore 
> > 
> wrote:
>
>>
>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> Your webrev links are to internal locations.
>>
>> Sorry, I cut/pasted the wrong links.  They are:
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/ 
>> 
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>
>> and the full version
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>
>> Thank you for pointing this out David.
>>
>> Coleen
>>
>>>
>>> David
>>>
>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>>> processing and intrinsics in JVM
>>>>
>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>>> performance benefit at the end of all of this if we can remove all oop
>>>> pointers from metadata.   mirror in Klass is the only one left after
>>>> this full change.
>>>>
>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>
>>>> There are a couple steps to this change because Hotspot testing is done
>>>> with promoted JDKs.  The first step is this webrev:
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>
>>>> When the JDK is promoted, the code to remove
>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>
>>>> Finally, a compatibility request and licensee notification will 
>>>> occur to
>>>> remove the function JVM_GetComponentType.
>>>>
>>>> Performance testing was done that shows no difference in performance.
>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>
>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>> tests were performed on both the change requested (1st one) and the 
>>>> full
>>>> change.
>>>>
>>>> hotspot NSK tests were run on the hotspot-only change with a 
>>>> promoted JDK.
>>>>
>>>> Please send your comments.
>>>>
>>>> Thanks,
>>>> Coleen
>>
>



From huizhe.wang at oracle.com  Mon Jun 30 20:07:14 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Jun 2014 13:07:14 -0700
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <53B1BC12.20003@oracle.com>
References: <53B1B7E3.2000505@oracle.com>	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>	<53B1B90E.7050208@oracle.com>
	<31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>
	<53B1BC12.20003@oracle.com>
Message-ID: <53B1C372.6000804@oracle.com>

That makes sense. I changed @since back to 1.4 and added L2 in the 
description:

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

Thanks,
Joe

On 6/30/2014 12:35 PM, Henry Jen wrote:
> On 06/30/2014 12:26 PM, Lance Andersen wrote:
>>
>> On Jun 30, 2014, at 3:22 PM, huizhe wang 
>> wrote:
>>
>>>
>>> On 6/30/2014 12:20 PM, Lance Andersen wrote:
>>>> Looks OK Joe,  noticed the @since changed as well?
>>>
>>> Thanks for review.
>>>
>>> Yes. The support for DOM L3 was since JDK 1.5. Previously this
>>> package file mentioned only DOM L2.
>>
>> OK, thank you.  Just seemed strange that the overall version was
>> changed as I suspect L3 is compatible with L2.  I might have just
>> indicated that L3 was added in 1.5 as the support was initially in
>> 1.4 I believe.  I have no strong preference though
>
> I agree with Lance here, the package itself is included in JDK since 1.4.
>
> In case classes under this package is not properly labeled with @since 
> tag, they will be considered has the same @since as package.html, then 
> that would be really misleading.
>
> Cheers,
> Henry



From lance.andersen at oracle.com  Mon Jun 30 20:16:41 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Mon, 30 Jun 2014 16:16:41 -0400
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <53B1C372.6000804@oracle.com>
References: <53B1B7E3.2000505@oracle.com>
	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>
	<53B1B90E.7050208@oracle.com>
	<31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>
	<53B1BC12.20003@oracle.com> <53B1C372.6000804@oracle.com>
Message-ID: <313850A9-D4BE-4540-9484-A16FB0771F30@oracle.com>

Hi joe,

Should be a comma at the end of line 8 before the and on line 9 

Looks ok otherwise 

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 Jun 30, 2014, at 4:07 PM, huizhe wang  wrote:

> That makes sense. I changed @since back to 1.4 and added L2 in the description:
> 
> http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/
> 
> Thanks,
> Joe
> 
> On 6/30/2014 12:35 PM, Henry Jen wrote:
>> On 06/30/2014 12:26 PM, Lance Andersen wrote:
>>> 
>>> On Jun 30, 2014, at 3:22 PM, huizhe wang 
>>> wrote:
>>> 
>>>> 
>>>> On 6/30/2014 12:20 PM, Lance Andersen wrote:
>>>>> Looks OK Joe,  noticed the @since changed as well?
>>>> 
>>>> Thanks for review.
>>>> 
>>>> Yes. The support for DOM L3 was since JDK 1.5. Previously this
>>>> package file mentioned only DOM L2.
>>> 
>>> OK, thank you.  Just seemed strange that the overall version was
>>> changed as I suspect L3 is compatible with L2.  I might have just
>>> indicated that L3 was added in 1.5 as the support was initially in
>>> 1.4 I believe.  I have no strong preference though
>> 
>> I agree with Lance here, the package itself is included in JDK since 1.4.
>> 
>> In case classes under this package is not properly labeled with @since tag, they will be considered has the same @since as package.html, then that would be really misleading.
>> 
>> Cheers,
>> Henry
> 


From huizhe.wang at oracle.com  Mon Jun 30 21:12:57 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Jun 2014 14:12:57 -0700
Subject: RFR: 8037948: Improve documentation for org.w3c.dom package
In-Reply-To: <313850A9-D4BE-4540-9484-A16FB0771F30@oracle.com>
References: <53B1B7E3.2000505@oracle.com>
	<77DA9D01-1BDE-410F-8901-87E2E9637C93@oracle.com>
	<53B1B90E.7050208@oracle.com>
	<31E97FCF-051C-4997-9CCD-9A0D34212240@oracle.com>
	<53B1BC12.20003@oracle.com> <53B1C372.6000804@oracle.com>
	<313850A9-D4BE-4540-9484-A16FB0771F30@oracle.com>
Message-ID: <53B1D2D9.10104@oracle.com>


On 6/30/2014 1:16 PM, Lance @ Oracle wrote:
> Hi joe,
>
> Should be a comma at the end of line 8 before the and on line 9

comma added.

>
> Looks ok otherwise

I committed the change. Thanks again Lance and Henry!

-Joe

>
> 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 Jun 30, 2014, at 4:07 PM, huizhe wang  > wrote:
>
>> That makes sense. I changed @since back to 1.4 and added L2 in the 
>> description:
>>
>> http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/ 
>> 
>>
>> Thanks,
>> Joe
>>
>> On 6/30/2014 12:35 PM, Henry Jen wrote:
>>> On 06/30/2014 12:26 PM, Lance Andersen wrote:
>>>>
>>>> On Jun 30, 2014, at 3:22 PM, huizhe wang >>> >
>>>> wrote:
>>>>
>>>>>
>>>>> On 6/30/2014 12:20 PM, Lance Andersen wrote:
>>>>>> Looks OK Joe,  noticed the @since changed as well?
>>>>>
>>>>> Thanks for review.
>>>>>
>>>>> Yes. The support for DOM L3 was since JDK 1.5. Previously this
>>>>> package file mentioned only DOM L2.
>>>>
>>>> OK, thank you.  Just seemed strange that the overall version was
>>>> changed as I suspect L3 is compatible with L2.  I might have just
>>>> indicated that L3 was added in 1.5 as the support was initially in
>>>> 1.4 I believe.  I have no strong preference though
>>>
>>> I agree with Lance here, the package itself is included in JDK since 
>>> 1.4.
>>>
>>> In case classes under this package is not properly labeled with 
>>> @since tag, they will be considered has the same @since as 
>>> package.html, then that would be really misleading.
>>>
>>> Cheers,
>>> Henry
>>



From huizhe.wang at oracle.com  Mon Jun 30 21:32:49 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Jun 2014 14:32:49 -0700
Subject: RFR: 8023276: Java SE should include the full DOM API from JAXP
Message-ID: <53B1D781.2050302@oracle.com>

Hi,

Three packages are missing from the DOM API documentation in JAXP:
         org.w3c.dom.views
         org.w3c.dom.ranges
         org.w3c.dom.traversal

We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since 
we were too close to the deadline for JAXP 1.6 MR, we left the other two 
packages for JDK 9.  CCC has been approved for this addition. Please review.

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

Thanks,
Joe


From Lance.Andersen at oracle.com  Mon Jun 30 21:37:47 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 30 Jun 2014 17:37:47 -0400
Subject: RFR: 8023276: Java SE should include the full DOM API from JAXP
In-Reply-To: <53B1D781.2050302@oracle.com>
References: <53B1D781.2050302@oracle.com>
Message-ID: <93AACCFB-91BE-4F2B-8A77-51D7B5E82C57@oracle.com>

+1
On Jun 30, 2014, at 5:32 PM, huizhe wang  wrote:

> Hi,
> 
> Three packages are missing from the DOM API documentation in JAXP:
>        org.w3c.dom.views
>        org.w3c.dom.ranges
>        org.w3c.dom.traversal
> 
> We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since we were too close to the deadline for JAXP 1.6 MR, we left the other two packages for JDK 9.  CCC has been approved for this addition. Please review.
> 
> http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/
> 
> Thanks,
> Joe




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 christian.thalinger at oracle.com  Mon Jun 30 22:09:34 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 30 Jun 2014 15:09:34 -0700
Subject: RFR 8047737 Move array component mirror to instance of
	java/lang/Class
In-Reply-To: <53B1C34F.5060901@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
	<53B15B50.6070405@oracle.com>
	
	<53B1C34F.5060901@oracle.com>
Message-ID: 


On Jun 30, 2014, at 1:06 PM, Coleen Phillimore  wrote:

> 
> On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>>      private Class(ClassLoader loader) {
>>          // Initialize final field for classLoader.  The initialization value of non-null
>>          // prevents future JIT optimizations from assuming this final field is null.
>>          classLoader = loader;
>> +        componentType = null;
>>      }
>> 
>> Are we worried about the same optimization?
> 
> I don't know if I was justified in worrying about the optimization in the first place.   Since getComponentType() is conditional, I wasn't worried.
> 
> But it should be consistent.  Maybe I should revert the classLoader constructor change, now that I fixed all the tests not to care.   What do people think?
>> 
>> +  compute_optional_offset(_component_mirror_offset,
>> +                 klass_oop, vmSymbols::componentType_name(),
>> +                 vmSymbols::class_signature());
>> 
>> Is there a followup cleanup to make it non-optional?  Or, are you waiting for JPRT to be able to push hotspot and jdk changes together?
> 
> Yes, please look at the _full webrev.  That has the non-optional changes in it and the follow on changes to remove getComponentType as an intrinsic in C2 (will file new RFE).  I really would like a compiler person to comment on it.

Sorry, I missed that.  Yes, the compiler changes look good.

> 
> Thanks so much,
> Coleen
> 
>> 
>> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore  wrote:
>> 
>>> 
>>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>>> Hi Coleen,
>>>> 
>>>> Your webrev links are to internal locations.
>>> 
>>> Sorry, I cut/pasted the wrong links.  They are:
>>> 
>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>> 
>>> and the full version
>>> 
>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>> 
>>> Thank you for pointing this out David.
>>> 
>>> Coleen
>>> 
>>>> 
>>>> David
>>>> 
>>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>>>> processing and intrinsics in JVM
>>>>> 
>>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>>>> performance benefit at the end of all of this if we can remove all oop
>>>>> pointers from metadata.   mirror in Klass is the only one left after
>>>>> this full change.
>>>>> 
>>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>> 
>>>>> There are a couple steps to this change because Hotspot testing is done
>>>>> with promoted JDKs.  The first step is this webrev:
>>>>> 
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>> 
>>>>> When the JDK is promoted, the code to remove
>>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>> 
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>> 
>>>>> Finally, a compatibility request and licensee notification will occur to
>>>>> remove the function JVM_GetComponentType.
>>>>> 
>>>>> Performance testing was done that shows no difference in performance.
>>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>> 
>>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>>> tests were performed on both the change requested (1st one) and the full
>>>>> change.
>>>>> 
>>>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>>>>> 
>>>>> Please send your comments.
>>>>> 
>>>>> Thanks,
>>>>> Coleen
>>> 
>> 
> 



From mernst at cs.washington.edu  Mon Jun  2 02:40:03 2014
From: mernst at cs.washington.edu (Michael Ernst)
Date: Mon, 02 Jun 2014 02:40:03 -0000
Subject: Two questions about parameter nullness in the JDK
Message-ID: <20140601.193954.972774361397555808.mernst@cs.washington.edu>

I have a couple of questions about places that the JDK is under-specified 
with respect to nullness properties.

Many GitHub projects pass null as the implVendor argument to 
ClassLoader.definePackage:

   
https://github.com/search?p=2&q=definePackage+packageName+null&ref=searchresults&type=Code

However, the ClassLoader.definePackage documentation does not say whether 
null is permitted or forbidden as an argument.  Could you clarify and 
document this issue?

Another example is ClassFileTransformer.transform.  It seems safe to pass 
in a null protectionDomain to the current implementation:

   https://gist.github.com/trask/d47133aef3b662b6548b

However, the documentation does not explicitly state whether null is 
permitted or forbidden.  I'd like to get a ruling on this issue so that it 
can be documented as well.

Thanks very much for your help!

                     -Mike


From stanimir at riflexo.com  Thu Jun 19 06:32:05 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Thu, 19 Jun 2014 06:32:05 -0000
Subject: [concurrency-interest] ThreadLocalRandom clinit troubles
In-Reply-To: 
References: 
Message-ID: 

I wonder why just don't use the /dev/random if available on *nix -
implemented by sun.security.provider.NativePRNG or
sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
Both support SecureRandomSpi.engineGenerateSeed(int) that provides an
arbitrary amount of entropy.
Although the approach would cause some more classes to load, no arbitrary
providers should be initialized.

Stanimir



On Thu, Jun 19, 2014 at 7:25 AM, Martin Buchholz 
wrote:

> ThreadLocalRandom's clinit method creates an intermediate broken state of
> ThreadLocalRandom and then proceeds to run some networking code to get some
> more machine-specific entropy in initialSeed().  This will fail if the
> networking code ever recursively uses a (not yet functional)
> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
> be run,
>
> at
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
>  at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at java.net.InetAddress$3.run(InetAddress.java:923)
>  at java.net.InetAddress$3.run(InetAddress.java:918)
> at java.security.AccessController.doPrivileged(Native Method)
>  at java.net.InetAddress.createNSProvider(InetAddress.java:917)
> at java.net.InetAddress.(InetAddress.java:962)
>
> if the sun.net.spi.nameservice.provider system property is defined.
>
> The current strategy of ThreadLocalRandom relying on other java code for
> initialization seems risky.  Safer would be to have native code provide
> some entropy at program startup for use by ThreadLocalRandom.  I don't have
> a clean solution for this problem (other than to rip out initialSeed()).
>  Strictly more reliable would be to mix in the entropy from the system at
> the end of ThreadLocalRandom's clinit instead of the beginning, but the
> basic problem remains.
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


From stanimir at riflexo.com  Fri Jun 20 12:16:05 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Fri, 20 Jun 2014 12:16:05 -0000
Subject: [concurrency-interest] ThreadLocalRandom clinit troubles
In-Reply-To: <53A418F2.3080201@gmail.com>
References: 
	<53A29DC5.1030605@oracle.com>
	
	<53A3FA72.3060706@gmail.com> <53A418F2.3080201@gmail.com>
Message-ID: 

Hi Peter,
Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses
Thread.contextClassLoader to load the services. Depending how late the
NameServices is getting initialized, perhaps it can be used to circumvent
the loader available at clinit of InetAddress.

I am not sure it could be a real security concern (as the caller has to be
authorized to create custom classloaders), yet the behavior is not exactly
the same. Storing Thread.currentThread().getContextClassLoader() during
clinit in a WeakRefernce (and clearing on use) should be closest to the
original code.

Cheers,
Stanimir



On Fri, Jun 20, 2014 at 2:20 PM, Peter Levart 
wrote:

> On 06/20/2014 11:10 AM, Peter Levart wrote:
>
>> Perhaps a more lazy initialization of NetworkInterface class that does
>> not trigger initialization of NS providers could help. We just need to
>> invoke two methods on NetworkInterface:
>>
>> - static NetworkInterface.getNetworkInterfaces()
>> - instance NetworkInterface.getHardwareAddress()
>>
>> both of which could provide the result without the need of NS providers,
>> I think.
>>
>> This would solve the most general case of using TLR. The case that
>> doesn't involve SecureRandom's help which I think is rarely needed and not
>> default.
>>
>>
>> Regards, Peter
>>
>
> Hi,
>
> A patch that solves this is a patch to InetAddress. We can't suppress
> initialization of InetAddress as part of NetworkInterface initialization,
> but we can suppress initialization of NameService providers as part of
> InetAddress initialization by moving them into a nested class called
> NameServices:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.
> NameServices/webrev.01/
>
> This should solve Martin's issue, but the patch to TLR initialization
> could be applied nevertheless, since it might help overcome possible issues
> when using SecureRandom for TLR's seed.
>
> Regards, Peter
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


From digulla at hepe.com  Fri Jun 20 10:00:05 2014
From: digulla at hepe.com (Aaron Digulla)
Date: Fri, 20 Jun 2014 10:00:05 -0000
Subject: [9] request for review 8047353: Improve error message when a JAR
	with invalid signatures is loaded
In-Reply-To: <53A35AEC.9080708@oracle.com>
Message-ID: <26b8-53a40600-d-41ced200@248413781>

Am Donnerstag, 19. Juni 2014 23:49 CEST, Joe Darcy  schrieb: 
 
> I'd prefer to see the CheckJarSigError.sh as a Java program.

There original bug report contains a full self-contained test case in Java. Why was that split into several files?

I'm also a bit uneasy about the "just show the file name". I have thousands of JARs with the same name on my harddisk (several Maven repos, target folders, you name it). If you strip the path from the error message, then I have to somehow figure out the classpath which was used.

That might work when I run Java from the command line but when I use complex frameworks like OSGi or Maven which do all kinds of magic to determine which JARs they might want to load, then this doesn't help much.


At least add a command line option / system property which allows to see the full path.

Regards,
 
-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits." 
http://blog.pdark.de/