Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 30 Sep 2015, at 16:13, Remi Forax wrote: > > > > - Mail original - >> De: "Paul Benedict" >> À: "Peter Levart" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 30 Septembre 2015 16:06:18

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

HI Paul, It simplifies code that looks like this: followRedirects = builder.followRedirects == null ? Redirect.NEVER : builder.followRedirects; To: followRedirects = Objects.nonNullOrElse(builder.followRedirects, Redirect.NEVER); It makes the source code more concise by

RE: Spin Loop Hint support: Draft JEP proposal

Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? Somehow, it feels right (as in consistent), but also off at the same time (as in, why are these on Thread). I'd take consistent over bespoke-one-static-method-class, unless there was a concerted effort to consolidate other related

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

In the database world, the function is COALESCE. And it's not just two arguments but the first non-null argument of any items. I would go with firstNonNull(Object a, Object b) and then provide an overload for a vararg. Cheers, Paul On Tue, Oct 6, 2015 at 10:48 AM, Ivan Gerasimov

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

Hi Roger, This looks nice. Javadocs (in particular mine) will need some work though. I agree that clear() and clean() implementations are final so that subclasses can not interfere with (de)registration. Perhaps the same could be done to isEnqueued() and enqueue() so that subclasses would

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

On 06.10.2015 16:58, Roger Riggs wrote: Hi Ivan, Easy enough, but I have not surveyed the codebase to see if it would be used or is necessary. Most of the cases I've seen are simple if/then/else or ?: expressions. I found a few possible candidates with grep:

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

On 10/06/2015 05:14 PM, Peter Levart wrote: Hi Roger, This looks nice. Javadocs (in particular mine) will need some work though. I agree that clear() and clean() implementations are final so that subclasses can not interfere with (de)registration. Perhaps the same could be done to

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

What the existing code does would seem to be irrelevant. What is important is deciding what the correct semantics should be for a core method on Objects. If there a desperate need for the webrev semantics, how about two methods? firstNonNull(a, b) - result must not be null firstOrElse(a, b) -

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

On 10/06/2015 04:11 PM, Paul Benedict wrote: If the second value is allowed to be null, then I don't find this new method useful. What value do you see in it? It doesn't provide any extra functionality to a simple if-else/ternary test, right? I throw my lot in with Stephen that the return

Re: Spin Loop Hint support: Draft JEP proposal

> On Oct 6, 2015, at 7:54 AM, Rezaei, Mohammad A. > wrote: > > Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? That's probably a good place, especially since it doesn't add a new class. Will need feedback about the concerns of adding methods to existing

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

Hi Peter, Well spotted, the timeout is the easiest solution, and it will happen infrequently. The timeout can be quite long to avoid a 'polling' tax. Perhaps 60 seconds. Thanks, Roger On 10/6/2015 12:06 PM, Peter Levart wrote: Hi Roger (again, sorry)! I think I found a race in the

Re: JDK 9 RFR of JDK-8138823: Correct bug in port of fdlibm hypot to Java

Hi Joe, On Oct 2, 2015, at 7:26 PM, joe darcy wrote: > Please review the changes for > >JDK-8138823: Correct bug in port of fdlibm hypot to Java >http://cr.openjdk.java.net/~darcy/8138823.0/ > > The change to java/lang/FdLibm.java is to correct a problem

[9] [xxs] RFR 8138938: Clarify javadoc for java.util.Collections.copy()

Hello! It was suggested that the javadoc for the java.util.Collections.copy() method can be clarified. Currently it says that the dest list must be long enough, not specifying what it means to be long. The submitter claims that it may be treated that the capacity of the list must be large

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

Hi Peter, Thanks for the cleanup suggestions in your previous email. I do need to look at the javadoc again. On 10/6/2015 11:38 AM, Peter Levart wrote: On 10/06/2015 05:14 PM, Peter Levart wrote: Hi Roger, This looks nice. Javadocs (in particular mine) will need some work though. I

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 05/10/2015 22:16, Steve Drach wrote: None of the other attributes have this. Are you suggesting I do this? Yes, and I assume this will rename to @since 9 once the versioning JEP goes in. -Alan

Re: Spin Loop Hint support: Draft JEP proposal

On 10/04/2015 12:22 PM, Gil Tene wrote: I would like to circulate this draft JEP proposal for initial review and consensus building purposes. Some background: about two years ago, Dave Dice and I put together a pre-jep proposal for JVM support for recent CPU features covering: (1)

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

On 10/6/15 10:09 AM, Louis Wasserman wrote: On Tue, Oct 6, 2015 at 10:03 AM Stuart Marks > wrote: As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with a recommended replacement of MoreObjects.firstNonNull(). [1]

Re: [9] [xxs] RFR 8138938: Clarify javadoc for java.util.Collections.copy()

On 10/6/15 12:28 PM, Ivan Gerasimov wrote: It was suggested that the javadoc for the java.util.Collections.copy() method can be clarified. Currently it says that the dest list must be long enough, not specifying what it means to be long. The submitter claims that it may be treated that the

Re: Spin Loop Hint support: Draft JEP proposal

On 06/10/15 05:32, Gil Tene wrote: > I don't think of this as platform specific. And it's not much lower > level than e.g. some java.util.concurrent stuff (but probably > doesn't belong in that package because it's not really about > concurrency). I'm looking for a proper Java SE spec'ed way to

Re: Spin Loop Hint support: Draft JEP proposal

Hi Gil, Have you investigated the use of this spin loop hint in j.u.concurrent classes and other potential areas in the JDK? I think it would be useful to include some investigation to validate it’s use and then follow up with updates, perhaps separate to this JEP. > On 6 Oct 2015, at 06:32,

Re: Array equality, comparison and mismatch

> On 5 Oct 2015, at 17:35, Chris Hegarty wrote: > > Paul, > > On 22/09/15 17:30, Paul Sandoz wrote: >> Hi, >> >> Please review the following which adds methods to Arrays for performing >> equality, comparison and mismatch: >> >>

Re: Array equality, comparison and mismatch

On 6 Oct 2015, at 09:50, Paul Sandoz wrote: >> >> On 5 Oct 2015, at 17:35, Chris Hegarty wrote: >> >> Paul, >> >> On 22/09/15 17:30, Paul Sandoz wrote: >>> Hi, >>> >>> Please review the following which adds methods to Arrays for performing

Re: Spin Loop Hint support: Draft JEP proposal

On 10/6/2015 6:28 PM, Gil Tene wrote: On Oct 6, 2015, at 1:02 PM, Doug Lea wrote: On 10/04/2015 12:22 PM, Gil Tene wrote: I would like to circulate this draft JEP proposal for initial review and consensus building purposes. Some background: about two years ago, Dave

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

On 10/6/15 3:24 AM, Stephen Colebourne wrote: Moving to core-libs: On 3 October 2015 at 03:20, Stuart Marks wrote: An interesting exercise would be to add the @Deprecated annotation to the Boolean constructor and build the JDK and see how many warnings result. That

Re: JEP 269: Convenience Factory Methods for Collections

On 10/3/15 7:16 AM, fo...@univ-mlv.fr wrote: "Kevin Bourrillion" wrote: We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They do this for an actual reason: a negative result is meaningfully different from no result. This is addressed in our Optional

Re: Spin Loop Hint support: Draft JEP proposal

> On Oct 6, 2015, at 1:02 PM, Doug Lea wrote: > > On 10/04/2015 12:22 PM, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and >> consensus building purposes. >> > > Some background: about two years ago, Dave Dice and I put together

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

Null coalescing is a popular operator in several languages [1] and the usual semantics is nullOrElse and not firstNonNull. In languages like Kotlin or Swift, because there is a distinction between Object and Object?, it's not a big deal, you can not de-reference null by error, anyway. Also

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

Moving to core-libs: On 3 October 2015 at 03:20, Stuart Marks wrote: > An interesting exercise would be to add the @Deprecated annotation to the > Boolean constructor and build the JDK and see how many warnings result. That > might be a quick way to find the code that

Re: Spin Loop Hint support: Draft JEP proposal

Sent from Gil's iPhone > On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote: > >> On 06/10/15 05:32, Gil Tene wrote: >> >> I don't think of this as platform specific. And it's not much lower >> level than e.g. some java.util.concurrent stuff (but probably >> doesn't belong in

Re: Spin Loop Hint support: Draft JEP proposal

Although spin lock would also benefit from this, the spinning is also done when doing message hand off between threads. It's common in low latency space to monopolize the cpu(s) and spin wait for data to arrive; this is to avoid parking the thread in kernel when you know arrival rate is very

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

If the second value is allowed to be null, then I don't find this new method useful. What value do you see in it? It doesn't provide any extra functionality to a simple if-else/ternary test, right? I throw my lot in with Stephen that the return value must be non-null. Cheers, Paul On Tue, Oct

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

Java.lang.Objects contains a number of convenience methods to make it easier to handle references that are null. For example, toString(obj, nullDefault), A new method is proposed to return the reference or a default value if the reference is null. static T nonNull(T obj, T nullDefault);

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

Guava uses firstNonNull(a, b). It ensures that the result is never null, by checking that b is not null. I think the semantics of Guava's method is correct. I tend to think the method name isn't bad either. Calling it nonNull(Object,Object) clashes with the existing nonNull(Object) method. Those

Re: JEP 264: Platform Logging API and Service

On 10/05/2015 09:59 PM, Daniel Fuchs wrote: Thanks Roger! I have updated the specdiff online. http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html The only comment I haven't taken into account yet is this: > - the LoggerFinder constructor says "Only

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

Hi Ivan, Easy enough, but I have not surveyed the codebase to see if it would be used or is necessary. Most of the cases I've seen are simple if/then/else or ?: expressions. Using the Supplier for does have some extra overhead not readily observable in the code. There is precedent for such a

Re: JEP 264: Platform Logging API and Service

Hi, This case does not require a restriction. This is not really a case of a singleton object. I think the statement is a statement of fact. The behavior should be attributed to the LoggerFinder.getLoggerFinder method and not to the constructor of LoggerFinder. Roger On 10/6/2015 9:32 AM,

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

Hi Roger! I didn't notice the message, so first commented in the Jira. Would it make sense to also add a variant with the second argument of type Supplier, so that it can be lazily calculated only if needed? Something like: public static T nonNull(T obj, Supplier nullDefaultSupplier) {

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

It's quite possible for the second argument to be null. Is that your intention? I am not sure it makes sense, but it's not harmful either. I recommend you can either (1) explicitly document that's a possibility and this method could still return null or (2) prevent it by calling requireNonNull.

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

Hi Paul, Hence the question about the method name. It already documents explicitly that the nullDefault value is returned and does not restrict the value. To be a direct replacement for the current code, it should return the 2nd value regardless of whether it is null or not. Roger On

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

Hi Stephen, Guava's firstNonNull is a useful semantic, but would not be a drop in replacement for existing code which would need to be examined for behavioral changes due to possibly throwing an exception. So perhaps the nonNullorElse name would be more accurate. Thanks, Roger On 10/6/2015

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

Hi Roger (again, sorry)! I think I found a race in the implementation which could leave the Cleaner thread run forever: 238 public void run() { 239 Thread t = Thread.currentThread(); 240 ManagedLocalsThread mlThread = (t instanceof ManagedLocalsThread)

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

I agree that with Stephen that Guava's semantics of disallowing a null default are preferable. It would seem very odd if a method that has "nonNull" in its name is allowed to return null. It seems to me that the point of this and related methods is to provide a fluent way for a class to