Re: RFR(m): 8145468 deprecations for java.lang

- Mail original - > De: "Brian Goetz" > À: "Rémi Forax" > Cc: "Stuart Marks" , "core-libs-dev" > > Envoyé: Jeudi 14 Avril 2016 21:06:28 > Objet: Re: RFR(m): 8145468 deprecations for java.lang > > Sure, there is some inconvenience. But neither of these reasons seem to rise > to the lev

MethodNadles.lookup() for bootstrap class loader loaded classes

Hi Paul, On 04/14/2016 04:40 PM, Paul Sandoz wrote: Hi Peter, You found that annoying restriction :-) at this point i think this is mostly redundant. This is something i planned to update and limit the restriction to code within j.l.invoke and sun.invoke packages. sun.invoke is explicitly

Re: RFR(m): 8145468 deprecations for java.lang

Hi Heinz, i think we should go nuclear on this, deprecate the Integer constructor *and* remove the line in the spec that says that Integer.valueOf (and Byte, Short, Character, Long) uses a cache and admit that the Java spec should not have a premature optimization carved in it. About your examp

RFR(S): 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150956 Webrev: http://cr.openjdk.java.net/~mhaupt/8150956/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi David, The fact that the "main" thread is not tagged as being a JNI-attached thread seems accidental to me Should I file it to JBS? I think that we can fix as below: --- diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:3

Re: MethodNadles.lookup() for bootstrap class loader loaded classes

> On 15 Apr 2016, at 09:33, Peter Levart wrote: > > Hi Paul, > > On 04/14/2016 04:40 PM, Paul Sandoz wrote: >> Hi Peter, >> >> You found that annoying restriction :-) at this point i think this is mostly >> redundant. >> >> This is something i planned to update and limit the restriction to c

RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

Hi all, please review the following fix. It is an intermittent failure because of Teredo Tunneling Pseudo-Interface. Bug: https://bugs.openjdk.java.net/browse/JDK-8146758 Webrev: http://cr.openjdk.java.net/~xiaofeya/8146758/webrev.00/ Thanks, Felix

Re: RFR(S): 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void

> On 15 Apr 2016, at 10:34, Michael Haupt wrote: > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150956 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150956/webrev.00/ > +1 Paul.

Re: RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

> On 15 Apr 2016, at 11:29, Felix Yang wrote: > > Hi all, > please review the following fix. It is an intermittent failure because of > Teredo Tunneling Pseudo-Interface. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146758 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8146758/webrev.0

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

Hi Anthony, Sherman and all. Anthony, thank you for your comment! I and Yasumasa have recognized that the zipfs should be handled as Anthony said. However, we fear to make conflict of concept / implementation if we enhance the zipfs API now because it will be fixed in the near future. So I belie

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi Yasumasa, On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: Hi David, The fact that the "main" thread is not tagged as being a JNI-attached thread seems accidental to me Should I file it to JBS? I think it is a bug based on the comment here: JavaThread(bool is_attaching_via_jni = false);

Re: RFR(m): 8145468 deprecations for java.lang

Hi Stuart, Yes I am fine with the change. I can go back and do this after your push if you prefer, just let me know Best Lance > On Apr 14, 2016, at 7:13 PM, Stuart Marks wrote: > > > > On 4/14/16 8:30 AM, Paul Sandoz wrote: >> CachedRowSetImpl >> — >> >> 1966 return ((Float.v

Re: RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

On 15/04/16 10:29, Felix Yang wrote: Hi all, please review the following fix. It is an intermittent failure because of Teredo Tunneling Pseudo-Interface. Bug: https://bugs.openjdk.java.net/browse/JDK-8146758 Webrev: http://cr.openjdk.java.net/~xiaofeya/8146758/webrev.00/ Looks ok to me. -

Re: RFR(m): 8145468 deprecations for java.lang

FWIW. I would prefer to see these constructors removed and the JLS simplified at the earliest possible date. Not using these classes as the value types for primitives in Valhalla would be very confusing. Stephen On 15 April 2016 at 08:49, Remi Forax wrote: > Hi Heinz, > i think we should go nucl

Re: RFR(m): 8145468 deprecations for java.lang

I had a sidebar with Shipilev on this, and this is indeed still potentially an issue. Alexey's example was: set.contains(new Integer(i)) // 1 vs set.contains(Integer.valueOf(i)) // 2 EA is able to optimize away the allocation in line 1, but the additional complexity of dealin

Re: RFR: JDK-8147460: Clean-up jrtfs implementation

On 15/04/2016 00:44, Xueming Shen wrote: I did not realize that the PathOps.java does not include all the path tests we have in its nio version. I updated it with all of the "unix version" tests. It did trigger couple corner cases (the diff against yesterday's version in JrtPath.java attac

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi David, I think it is a bug based on the comment here: JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads I filed it to JBS as JDK-8154331. I will send review request to hotspot-runtime-dev. Though that will introduce a change in behaviour by itse

RFR: 8154304: NullpointerException at LdapReferralException.getReferralContext

I need to correct another issue related to JDK-8149450. If a getReferralContext call is made on a ReferralContext that doesn't contain any referrals (URI fields) then a null scenario is possible. There's a question mark around how compliant the LDAP BER response is but I'd like the JDK to handl

Re: RFR: 8154304: NullpointerException at LdapReferralException.getReferralContext

Looks nice to me. It would be nice to update the copyright date, too. Thanks, Xuelei On 4/15/2016 10:13 PM, Seán Coffey wrote: > I need to correct another issue related to JDK-8149450. If a > getReferralContext call is made on a ReferralContext that doesn't > contain any referrals (URI fields) t

Re: RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

Hi Chris, thanks for the review. Could you sponsor the change? Thanks, Felix On 2016/4/15 18:45, Chris Hegarty wrote: On 15/04/16 10:29, Felix Yang wrote: Hi all, please review the following fix. It is an intermittent failure because of Teredo Tunneling Pseudo-Interface. Bug: https://b

Re: JDK 9 RFR of JDK-4851642: Add fused mac to Java math library

Hi Joe, Dmitry, On Apr 14, 2016, at 10:00 PM, joe darcy wrote: > Thank you for the careful review. I second that. > Final webrev with minor adjustments at > > http://cr.openjdk.java.net/~darcy/4851642.2/ I think this looks good. Brian

Re: RFR(m): 8145468 deprecations for java.lang

Partial review. The changes to j.l.Thread* look good to me. -Chris. On 14 Apr 2016, at 02:50, Stuart Marks wrote: > Hi all, > > Please review this first round of deprecation changes for the java.lang > package. This changeset includes the following: > > - a set of APIs being newly deprecated

Re: RFR(m): 8145468 deprecations for java.lang

On 4/14/16 10:26 PM, Dr Heinz M. Kabutz wrote: Vladimir Ivanov wrote: I'd say it's a motivating example to improve EA implementation in C2, but not to avoid deprecation of public constructors in primitive type boxes. It shouldn't matter for C2 whether Integer.valueOf() or Integer:: is used. If

Re: RFR(m): 8145468 deprecations for java.lang

Hi Stephen, Remi, I would *love* to just get rid of the caches of integral boxed types and get rid of their constructors. Unfortunately people have been using the constructors for 20 years, but the valueOf(i) methods were added with autoboxing in Java 5, "only" 11.5 years ago. We did think a

Re: RFR(m): 8145468 deprecations for java.lang

On 4/15/16 3:38 AM, Lance Andersen wrote: Yes I am fine with the change. I can go back and do this after your push if you prefer, just let me know Thanks. I'm going to post an updated webrev with some other changes, so I'll just include the cleanups that Paul suggested. s'marks

RFR: 8151056: ASM enable original deprecated methods. (simple fix)

Hello, Please review this simple fix [1] to re-instate the original deprecated methods, as a background, there were commented out because of an internal dependency [2], and since has been fixed. Thanks Kumar [1] http://cr.openjdk.java.net/~ksrini/8151056/webrev.00/ [2] http://mail.openjdk.jav

Re: RFR: JDK-8152690: main thread does not have native thread name

On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: Hi David, I think it is a bug based on the comment here: JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads I filed it to JBS as JDK-8154331. I will send review request to hotspot-runtime-dev. Though t

JDK 9 RFR of 8154183:

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8154183 Patch: http://cr.openjdk.java.net/~bpb/8154183/webrev.00/ Summary: 1) Reinstate the ObjectInputStream part of the fix for https://bugs.openjdk.java.net/browse/JDK-4150728 which was inadvertently reverte

RFR(m): 8145468u1 deprecations for java.lang

Hi all, Here's a small update to the jdk repo webrev for this change. There are no changes to any API deprecations or other specification changes. The changes are confined to the warnings cleanup work. http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.1.jdk/ The files changed rel

JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

Re-posted with correct subject line. On Apr 15, 2016, at 3:35 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8154183 > Patch:http://cr.openjdk.java.net/~bpb/8154183/webrev.00/ > > Summary: > 1) Reinstate the

Re: RFR(m): 8145468 deprecations for java.lang

I don't think it's practical to ever remove the boxed primitive constructors. Even less so for String, because the String(String) constructor used to be an important optimization! On Thu, Apr 14, 2016 at 4:25 PM, Stuart Marks wrote: > On 4/14/16 10:10 AM, Martin Buchholz wrote: >> >> I've been te

Re: JDK 9 RFR of JDK-4851642: Add fused mac to Java math library

I think that the final webrev http://cr.openjdk.java.net/~darcy/4851642.2/ is good. Thanks. On Fri, Apr 15, 2016 at 8:00 AM, joe darcy wrote: > Hi Dmitry, > > On 4/14/2016 7:43 PM, Dmitry Nadezhin wrote: > > Hi Joe, > > It looks good except a guard expression in the line Math:1550 > (tmp == 0.0

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi David, That change in behaviour may be a problem, it could be considered a regression that setName stops setting the native thread main, even though we never really intended it to work in the first place. :( Such a change needs to go through CCC. I understood. Can I send CCC request? (I'