> On Oct 8, 2015, at 6:18 PM, John Rose wrote:
>
> 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
>> identif
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://cr.openjdk.java.
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 Optio
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 be used to cove
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. The third one I pointed out
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
http://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
> 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 preparation for JEP 260 [2].
>
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 Ro
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 do
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:
http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-81386
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 method
- Mail original -
> De: "Roger Riggs"
> À: fo...@univ-mlv.fr
> Cc: "core-libs-dev"
> Envoyé: Jeudi 8 Octobre 2015 21:09:26
> Objet: 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
> i
Hi Fabian,
As you might have seen from my message to Sebastian, I agree that the Boolean
constructors shouldn't be deprecated -- at least not with deprecation in its
current form.
The idea is eventually to mark them somehow, in a way that warns developers that
other APIs are preferable, but
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 l
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 2:37
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]
http://mail.openjdk.java.net/pipermail/discuss/2015-Septem
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 = Objec
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 : java.lang.Objects new method to default to
> non-null
> Hi Remi,
> On 10/8/
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
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:
H
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.
> 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 ...
*/
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' variable
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 vo
Hi Roger!
In the test, why the 'result' variable is needed?
242 String result;
243 errors += (result = Objects.nonNullOf(nullString,
defString)) == defString ? 0 : 1;
244 errors += (result = Objects.nonNullOf(nonNullString,
defString)) == nonNullString ? 0 : 1;
245
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: https
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 can
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 yield hint :)
--
*The infor
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 can be
omitted.
It puts the link where the reader sees the reference and is just as
informative.
Otherwise
On 10/08/2015 07:01 AM, David M. Lloyd wrote:
On 10/08/2015 05:58 AM, Doug Lea wrote:
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 voi
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, () -> "");
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 sight. In the past dumping these
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 th
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:
h
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 wer
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 sake
On 10/07/2015 09:21 PM, Gil Tene wrote:
> Interesting. I was going off of the 32 bit ARM documentation. Looks like
> ARMv8 improved on that, and did it implicitly (without requiring different
> instructions).
>
> You can see the differences on the unlock path between the 32 bit and 64 bit
> imple
> 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 occurs a few times:
>>
>> byte[
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
On 8 Oct 2015, at 09:32, Paul Sandoz wrote:
>
>> 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/web
> 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 Roger. Couldn't this be c
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 in the updated webrev:
>> http://cr.openjd
On Oct 7, 2015, at 3:01 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
On Oct 5, 2015, at 2:41 AM, Andrew Haley
mailto:a...@redhat.com>> wrote:
Hi Gil,
On 04/10/15 17:22, Gil Tene wrote:
Summary
Add an API that would allow Java code to hint that a spin loop is
being executed.
I don'
44 matches
Mail list logo
