Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 7 Oct 2015, at 22:28, Alan Bateman wrote: > > > On 07/10/2015 20:57, Chris Hegarty wrote: >> : >> I updated Connection with a readFully that has the same >> semantics as IOUtils. >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >> > I agree with

Re: Spin Loop Hint support: Draft JEP proposal

On Oct 7, 2015, at 3:01 PM, John Rose > wrote: On Oct 5, 2015, at 2:41 AM, Andrew Haley > wrote: Hi Gil, On 04/10/15 17:22, Gil Tene wrote: Summary Add an API that would allow Java code to hint

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 7 Oct 2015, at 23:44, Stephen Colebourne wrote: > On 7 October 2015 at 23:24, Roger Riggs wrote: >> Please consider and comment: >> >> T nonNullOf(T obj, T defaultObj); >> T nonNullOf(T, obj, Supplier defaultSupplier); >> >> Details are

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Roger, using overloads here seems to be a bad idea, as a nice puzzler, what does the compiler do for these two lines of code Supplier supplier = Objects.nonNullOf(null, () -> null); Supplier supplier2 = Objects.nonNullOf(null, () -> ""); The other issue is that defaultSupplier should allow

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 8 Oct 2015, at 10:46, Chris Hegarty wrote: >> It reads at most “seqlen" bytes, so the array may be larger than necessary, >> which might be ok depending on whether one can trust "seqlen”. > > We do no trust ‘seqlen’. :-( > Good! >> The following pattern

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

Looks fine to me, though I have one question below. On 10/7/15 2:19 PM, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method

RFR: JDK-8046565: Platform Logger API and Service

Hi, Please find below the webrev for a first prototype of JEP 264 - Platform Logger API and Service. JEP: http://openjdk.java.net/jeps/264 https://bugs.openjdk.java.net/browse/JDK-8046565 specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html webrev:

Re: Spin Loop Hint support: Draft JEP proposal

On 10/08/2015 05:58 AM, Doug Lea wrote: On 10/06/2015 09:28 PM, Gil Tene wrote: As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods

Re: Spin Loop Hint support: Draft JEP proposal

On 10/06/2015 09:28 PM, Gil Tene wrote: As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods were placed in odd places just for the

Re: Spin Loop Hint support: Draft JEP proposal

I agree with David that it should be static though; it doesn't really make sense to be instance. sent from my phone On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" wrote: > Hi Doug, > > Brilliant thought, absolutely…. so obvious that it is completely hidden in > plain

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On Thu, Oct 8, 2015 at 1:01 PM, David M. Lloyd wrote: > > If the method is static, then the impact of a clashing name should be > fairly minimal. > > +1 on this, I do not see the benefit of an instance method either here. But good idea, Doug, for Thread class and the

Re: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()

Hi Brent, I wonder whether we should add a negative test case, in which lowercasing/uppercasing on the originals would differ but String.equalsIgnoreCase() returns true. Naoto On 10/7/15 4:30 PM, Brent Christian wrote: Hi, Please review my doc/spec change (no code) for 8138824. Bug:

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Remi, On 10/8/2015 4:49 AM, Remi Forax wrote: Hi Roger, using overloads here seems to be a bad idea, as a nice puzzler, what does the compiler do for these two lines of code Supplier supplier = Objects.nonNullOf(null, () -> null); Supplier supplier2 = Objects.nonNullOf(null, () -> "");

Re: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()

Sounds reasonable - I'll make the change. Thanks, Roger -Brent On 10/08/2015 08:26 AM, Roger Riggs wrote: Hi Brent, I'm not sure we have a best practice for referring to other classes but I think that the {@code } references to Collator could be {@link java.text.Collator} and the @See tags

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Ivan, It was there, for compile time, to confirm the type signature of the return value; the type checking on == isn't as strong as assignment. But it would not be needed more than once. Roger On 10/8/2015 12:13 PM, Ivan Gerasimov wrote: Hi Roger! In the test, why the 'result'

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

2015/10/8 7:56 -0700, d...@cs.oswego.edu: >>> ... >>> >>> class Thread { // >>> /** >>> * A hint to the platform that the current thread is momentarily >>> * unable to progress. ... add more guidance ... >>> */ >>> void spinYield(); > > should be: >public static

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

> On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote: > > 2015/10/8 7:56 -0700, d...@cs.oswego.edu: ... class Thread { // /** * A hint to the platform that the current thread is momentarily * unable to progress. ... add more guidance ... */

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 08.10.2015 19:33, Roger Riggs wrote: Hi Ivan, It was there, for compile time, to confirm the type signature of the return value; the type checking on == isn't as strong as assignment. Ah, Okay. Thanks for explanation! Sincerely yours, Ivan But it would not be needed more than once.

Re: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

Hi Sebastian, I am all for micro optimizations that do make sense, even if their impact might be low, but I disagree with deprecating the Boolean constructor. Using it, while not being the most efficient, is not a problem, and I would say in almost all application and workloads not an issue worth

Re: RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()

Sure, I'll write something. -B On 10/08/2015 08:57 AM, Naoto Sato wrote: Hi Brent, I wonder whether we should add a negative test case, in which lowercasing/uppercasing on the originals would differ but String.equalsIgnoreCase() returns true. Naoto On 10/7/15 4:30 PM, Brent Christian wrote:

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

So for you, method overloading is a mis-feature of the language because it inhibits readability. Though I might argue, that the magic type inference is the real culprit. In most coding cases, the types of the arguments are visible and/or via syntax and naming. Thanks, Roger On 10/8/2015

Re: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application

On 10/6/15 11:51 PM, Dawid Weiss wrote: A @Discouraged(String seeAlternative) annotation? This also applies to things like Vector or Hashtable (which arguably have a slightly different semantics from ArrayList or HashMap, but if somebody uses them it's very likely a mistake). Yes, something

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Remi, ok, the easy way out is to rename it/both of the methods. And the name comes back around for discussion so the two names have some synergy: T nonNullOrGet(T, Supplier) T nonNullOrElse(T, T); Updated Webrev:

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 12:34 PM, fo...@univ-mlv.fr wrote: > > Anyway, in this case the problem is not just overloading, it is the mix of > overloading and type inference as you said. Add type erasure to this cocktail, and it's perfect. My antennae go up when the erased types overlap. When they

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Please review a few improvements to the Cleaner nested classes and implementation. - The extensible reference classes have shorter names that focus on the cleanup behavior, PhantomCleanup, WeakCleanup, SoftCleanup and to update the javadoc - Added documentation for the Reference.get

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi John, Thanks for the insight, I hope it will help cut down on the thrashing. Isn't there a 4th form that throws missing? There was quite a bit of support for a version the never returned null and threw an exception if the replacement was null. Thanks, Roger On 10/8/2015 5:26 PM, John

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 8 Oct 2015, at 13:34, Sean Mullan wrote: > > Looks fine to me, though I have one question below. Thanks for looking at this Sean. > On 10/7/15 2:19 PM, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in

RFC: draft API for JEP 269 Convenience Collection Factories

://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.specdiff/overview-summary.html Most of the API is pretty straightforward, with fixed-arg and varargs "of()" factories for List, Set, ArrayList, a

Re: Spin Loop Hint support: Draft JEP proposal

On Oct 8, 2015, at 12:39 AM, Gil Tene wrote: > > On the one hand: > > I like the idea of (an optional?) boolean parameter as a means of hinting at > the thing that may terminate the spin. It's probably much more general than > identifying a specific field or address. And it can

Re: RFC: draft API for JEP 269 Convenience Collection Factories

e to focus on the API, and set > aside implementation issues and discussion for later. > > > JEP: > > http://openjdk.java.net/jeps/269 > > javadoc: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151008.mod/ > > specdiff: > > > http://

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 2:42 PM, Roger Riggs wrote: > > Thanks for the insight, I hope it will help cut down on the thrashing. > > Isn't there a 4th form that throws missing? There are four forms in Optional, but one of them returns "void" and is not relevant here, IMO.

Re: JEP 269: Convenience Factory Methods for Collections

On 10/7/15 2:30 AM, Stephen Colebourne wrote: Given what we know now vs when the collections library ws created, I think it would be a mistake to allow nulls. Developers that desperately want null in there have other mechanisms to achieve that, not just Optional. I too would argue against

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 10/8/15 2:10 PM, Roger Riggs wrote: I am curious as to Stuart's question about whether it is supposed to figure out the overloads and is a bug, or if it just too difficult to make the inference work. I talked this over (internal discussion) with Vicente Romero-Zaldivar, one of the compiler

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Roger, my point was that for me, all theses forms are ambiguous thus not readable. > De: "Roger Riggs" > À: "Remi Forax" > Cc: "core-libs-dev" > Envoyé: Jeudi 8 Octobre 2015 16:44:54 > Objet: Re: RFR 9: 8138963 :

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 10/8/15 7:44 AM, Roger Riggs wrote: On 10/8/2015 4:49 AM, Remi Forax wrote: Hi Roger, using overloads here seems to be a bad idea, as a nice puzzler, what does the compiler do for these two lines of code Supplier supplier = Objects.nonNullOf(null, () -> null); Supplier supplier2 =

Re: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

On 10/7/15 12:59 PM, Sebastian Sickelmann wrote: http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ jdk: The Boolean constructors are @Deprecated now so that we get compile-warnings for the uses. See also [0] and [1] [0]