This is an optimization that is theoretically possible (and was
anticipated in the design), but in reality is likely to be so
low-priority that it would be a really long time before it was worth
putting engineering resources on this. It would have to be an unordered
stream, and we'd have to kn
Didn’t we just discuss this like a week ago?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026506.html
On Apr 17, 2014, at 12:30 AM, Otávio Gonçalves de Santana
wrote:
> I would to add for news methods on Iterable, I believe it will helpful for
> many Java Developers.
>
Its a fair question. Certainly the stream construction you suggest will do the
job; you’re looking for a more compact way to do it. Note that of course you
could write your own static method that encapsulates the stream operation and
you’d be done.
Map.replace/replaceAll are in-place, mutativ
In the course of JSR-335, we considered a number of possible methods on
Iterable. There are literally hundreds of methods that might "sensibly"
appear on Iterable; see RichIterable from GS-Collections or IEnumerable
from .NET for some examples. After considering the landscape, we
decided, bas
I suspect you were expecting this response: we don't add language
semantics through annotations.
Technically, we're not adding language semantics. The JVM is the one
interpreting the annotations. BTW, as I mentioned in another post in this
thread, I specifically asked about this at the JVM Lan
Why not go for something far less intrusive then?
I'm all for unintrusive. Though note that the intrusiveness metric on
language features I(f) is not uniform across observers :)
Here's my straw man
proposal:
Add an annotation that can be placed on native methods to synthesize
atomic access
(This is already-traveled ground.)
The ++/--/+= trick is cute as a shorthand, but without a means of
expressing a full-blown CAS, falls short of the goal of "integrate
atomic read-modify-write operations into the programming model." IF the
latter problem was addressed, we might consider redef
Embedded in this proposal is the desire to not provide a
full-blown "lvalue" form for variables; supporting any form of
pass-by-reference at the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and
also provides lots of other value (for exa
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This includes language syntax (e.g.,
x.volatile.
Except that Lock has features that are not supported by intrinsic locks
(timed wait, interruptible wait.) So the Lock returned would not
conform to Lock's contract, and attempting to call these methods would
probably throw UOE.
On 2/27/2014 6:12 AM, Stephen Colebourne wrote:
On 26 February 2
Seems like a symbolic victory, at least :) It's less unsafe than some
unsafe methods (you can use it to create a DoS but not to violate safety
constraints like bounds checking or pointer casting) but its a start!
On 2/26/2014 10:12 AM, Paul Sandoz wrote:
Hi,
Out of all the methods on Unsafe
I understand why you want this, though I think you’ll find that there are still
thousands of other things “missing” from reflection.
In the Java 1.0 days, the difference between the Java language and the class
file was pretty small. So reflection served as both the class file (VM)
reflection
can you be a little more specific and provide the way
foo.volatile.compareAndSet is compiled with this example:
Hey, the JEP isn't even out of draft yet! Stop asking hard questions.
The current strawman, though, is to expose direct (CP-ready) MH forms
(Lookup API / constant pool format TBD) f
It's about time we brought atomic ops out of the shadows of Unsafe and
into the programming model proper! It was a good compromise ten years
ago to stuff these into Unsafe, but its time for these features to grow
up.
Specific to this proposal, I like how the VolatileXxx interface approach
al
A future version of Java will hopefully have value types. The disclaimers
about "value-based" are intended as a stake in the ground, to preserve the
option to migrate these specific new-to-Java-8 types to value types in the
future. (Older sort-of-valueish-like-but-not-quite types, like Integer
Webrev at:
http://cr.openjdk.java.net/~briangoetz/JDK-8031373/webrev/
If someone with ASM fu (Remi?) could sanity check the JLI changes, that
would be appreciated.
I can take on java.lang.
When your IDE tells you about "unnecessary boxing" in Integer.valueOf(),
or "inner class can be converted to lambda" in LambdaMetafacory, don't
believe it :)
Paul deliberately stayed away from the JUC classes. Can we get a
definitive list of non-JUC classes that primarily live in the JSR166 CVS?
On 12/19/2013 11:48 AM, Martin Buchholz wrote:
(as always) Please don't modify jsr166 classes (ArrayDeque) here, since
they are maintained upstream in jsr1
+1 on all changes, except perhaps for this one in Collections.copy:
ListIterator di=dest.listIterator();
ListIterator si=src.listIterator();
for (int i=0; iThe code is bizarre enough (calling next based on a range loop rather
than hasNext()) to leave alone.
On 12/1
Coming late to the party...
Overall I'll +1 this change, with the following nit:
@throws NullPointerException if the specified key or value is null and
* this map does not support null keys or values, or the
* remappingFunction is null
This should be:
@throws NullPoin
Gernot's answer is exactly correct.
Think of it this way: do you expect BufferedReader.readLine() to close
the stream when it is at the EOF? Because that's all lines() does --
repeatedly call readLine() for you. If you opened the buffered reader,
then try-with-resources is what you want.
B
You are right that collect() would be a good start, but sadly there is no
DoubleCollector which trucks in doubles. So the concept is right but it
doesn't quite get you all the way there. Looking one level down, you'll find a
nicer answer. I would look at ReduceOps.makeDouble(), which ultimatl
I believe a long time ago it used to work this way; there was a private
"handoff" constructor in String that StringBuffer would use. Probably got
changed when we added StringBuilder?
On Nov 6, 2013, at 10:54 PM, Robert Stupp wrote:
> Hi,
>
> I was wondering why the mostly allocated class in
Ineexof(char) sounds like as fast and simpler?
Sent from my iPhone
On Nov 5, 2013, at 8:55 AM, Peter Levart wrote:
> On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
>> Changeset: 51b002381b35
>> Author:rfield
>> Date: 2013-11-04 10:12 -0800
>> URL: http://hg.openjdk.java.n
Changeset: 82ee370c3d7e
Author:briangoetz
Date: 2013-10-31 10:37 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82ee370c3d7e
8024637: Lambda linkage performance - use reflection instead of ASM to
manipulate parameter types
8023984: Lambda linkage performance - use a method r
Changeset: 9732816c9d17
Author:briangoetz
Date: 2013-10-29 12:45 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9732816c9d17
8024633: Lambda linkage performance - initialize generated class earlier
Reviewed-by: briangoetz, rfield
Contributed-by: sergey.kukse...@oracle.com
!
Changeset: ddb0b681654a
Author:briangoetz
Date: 2013-10-29 12:31 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb0b681654a
8027318: Lambda Metafactory: generate serialization-hostile read/writeObject
methods for non-serializable lambdas
Reviewed-by: rfield, psandoz
! src/
Changeset: 62a67e0875ff
Author:briangoetz
Date: 2013-10-30 14:12 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62a67e0875ff
8024930: Re-enable disabled bridging tests
Reviewed-by: psandoz, rfield
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
Yes, the intent the JSR166 EG had for Callable was "a deferred
computation" in the same way Runnable is "a deferred task".
On 10/30/2013 10:03 AM, Gernot Neppert wrote:
Hello,
I'd like to repeat my proposal to add @FunctionalInterface to
java.util.concurrent.Callable,
since that looks like a "
Changeset: 5fa2fd782993
Author:briangoetz
Date: 2013-10-24 13:06 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fa2fd782993
8019646: Clarify javadoc contract of LambdaMetafactory
Reviewed-by: briangoetz, rfield
Contributed-by: dan.sm...@oracle.com
! src/share/classes/java/l
This webrev:
http://cr.openjdk.java.net/~briangoetz/JDK-8019646/webrev/
contains minor changes to the lambda metafactory implementation, and a
significant overhaul of its specification. There are only two
behavioral changes, the rest of the changes are in exposition:
- Metafactory no long
Of these, the only one I might question is Iterable. While it is
commonly used as a mixin like Closeable or Flushable, unlike the others,
Iterables also make sense to stand on their own, and there are some
libraries that truck entirely in Iterable to perform stream-like
behavior (being the lea
I've created a survey about people's attitudes towards erasure and
reification.
If you participate, please take the time to answer the free-response
question; that's really what is going to help us.
Survey here:
https://www.surveymonkey.com/s/SCJC93R
For skip: should rename the parameters away from "startInclusive" to
something like "toSkip".
For slice: should probably change back to slice(toSkip, maxSize) rather
than start/end offsets; in this way, slice is skip+limit.
On 10/8/2013 11:38 PM, Mike Duigou wrote:
Hello all;
Based upon fee
> Is there something I missed? Is this something that has been considered?
If memory efficiency were the only metric in the world, this would be a
no-brainer. But, by having different classes for different nodes, many many
paths where the VM could prove monomorphism and thereby inline through n
To put it in aviation lingo: the cabin door has been closed and we've pulled
away from the jetbridge.
On Sep 22, 2013, at 5:40 AM, Stephen Colebourne wrote:
> I coded the methods I was thinking of on the plane to SFO:
> https://gist.github.com/jodastephen/6659515
>
> If there is still intere
http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/
I'm still mildly opposed.
The main uncompellingness
is that removeIf is a more descriptive name than removeAll.
The method currently called removeIf is like an atom with one valence
electron, searching for a pattern to bond with; righ
One of the main consequences of how lambda matching rules
panned out is that it is in general a bad idea to overload any
method accepting a lambda.
It is only a bad idea to overload methods that take same-arity lambdas
in the same position.
removeAll(Collection)
vs
removeAll(Predicate)
+1 from me.
On 9/4/2013 5:08 PM, Mike Duigou wrote:
Hello all;
The naming of the Collection.removeIf(Predicate) method has always been an
uncertain choice. We've gone back and forth between naming it removeIf and
overloading the existing removeAll(Collection) with a removeAll(Predicate). Now
Because non-capturing lambdas are *already* constants! The commonly
used trick, that was needed with inner classes to avoid instantiating
multiple instances of essentially identical objects:
static final Comparator c = new Comparator() { ... }
is effectively implemented automatically (and l
Nice. +1.
On 8/23/2013 3:17 PM, Henry Jen wrote:
Hi,
Please kindly review the fix for eliminate some warnings in
java.util.stream package.
Chained Sink is an internal implementation detail, add the type for
downstream is more precise but verbose.
Included is also a couple other warnings clea
The whole reflection thing is a red herring. As is the performance thing.
The reason not to call close() has nothing to do with the expensive of
calling close; it is about not mucking up your code for no reason.
Consider:
list.stream()
.filter(s -> s.startsWith("foo"))
.map(Str
The following webrev describes changes to the lambda metafactory enabled
by the compiler generating bridge methods in interfaces, and therefore
the metafactory need not try and guess which other methods should be
bridged to the main SAM method. The compiler can optionally generate a
specific l
If we can't deprecate this, we might as well deprecate @Deprecated.
On May 14, 2013, at 10:25 AM, Alan Bateman wrote:
>
> I would like to broach the subject of pulling out the implementation of
> Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I mean
> changing it to uncon
With
changeset: 7058:6feee75b0a8b
summary: 8012664: Add tests for java.util.stream and lambda translation
we now have the lion's share of the java.util.stream code and tests put
back into the JDK8 repositories (16+ KLoC of new code and 15+ KLoC of
new tests, with nearly 100% coverage)*.
Webrev at:
http://cr.openjdk.java.net/~briangoetz/JDK-8012664/webrev/
These tests give ~92% line coverage on java.util.stream (they are being
reviewed separately to minimize putback dependencies.)
How many years ago was this done? Hasn't the hardware reality changed since
then? What might have been a justifiable crime then may just be a crime now.
On Apr 26, 2013, at 10:12 AM, Paul Sandoz wrote:
>
> On Apr 26, 2013, at 3:25 PM, Remi Forax wrote:
>
>> On 04/26/2013 01:43 PM, Paul Sa
This is a review request for the bulk of the java.util.stream
implementation; webrev at:
http://cr.openjdk.java.net/~briangoetz/JDK-8011920/webrev/
You might ask: with 15,000 lines of new code, why are there no tests?
The simple answer is: we've got plenty of 'em, but they can't be put
back
The motivation was indeed that it would support more efficient
Collection.toString. (But, I don't believe anything actually uses that
feature right now, other than tests.)
Even if *our* implementations were not to use this because we had a
better for-experts construction, I still think this i
Updated spec for Collection.spliterator; default methods for
Collection.stream() and parallelStream(). Specialized implementations
in subtypes will come in a separate putback.
Webrev at:
http://cr.openjdk.java.net/~briangoetz/JDK-8012542/webrev/
Single new source file at:
http://hg.openjdk.java.net/lambda/lambda/jdk/file/76ac19e61df1/src/share/classes/java/util/stream/Collectors.java
Doc at:
http://cr.openjdk.java.net/~briangoetz/JDK-8008682/api/java/util/stream/Collectors.html
for JDK-8011917 (Collectors class in java.util.stream).
.
On 2/21/2013 2:16 PM, Brian Goetz wrote:
At:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
there is a webrev of a subset of the implementation of java.util.stream,
for review. These are all new files. None of these are public classes;
they are internal interfaces for the Stream
> Has the optional classes been verified to serialize/deserialize correctly?
>
They are not serializable.
> Finally, are these utilities critical to some other part JDK 8 that they were
> pushed out now as opposed to JDK 9?
>
>
They are part of the libraries being added by JSR-335 / Project L
What percentage of the empty lists are default-sized? I suspect it is large,
in which case we could apply this trick only for the default-sized lists, and
eliminate the extra field.
On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
> Hello all;
>
> This is a review for optimization work that
2) I find X_IN and X_OUT type parameters to be disruptive to reading.
Sticking to a simple "I" and "O" would be much easier to read.
I'll answer this one because we've gotten it from a few places.
This is a nice idea, and it works fine up to a certain level of
complexity. But when you have a
I've posted an updated webrev incorporating comments received to date:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/
On 2/21/2013 2:16 PM, Brian Goetz wrote:
At:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
there is a webrev of a subset o
At:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
there is a webrev of a subset of the implementation of java.util.stream,
for review. These are all new files. None of these are public classes;
they are internal interfaces for the Stream library, as well as some
implementation
Runtime behavior of Java will NOT depend on optional annotations. Where did
you get that idea?
The reflection aspect is separate and also desirable.
On Jan 16, 2013, at 8:32 AM, Florian Weimer wrote:
> On 01/16/2013 05:27 PM, Brian Goetz wrote:
>
>> The primary purpose of thi
:08 PM, Brian Goetz wrote:
>> There is a benefit for languages *other* than Java, that can use this as a
>> means to determine whether the interface is suitable for passing to the SAM
>> conversion machinery.
>
> But this would miss non-annotated classes, wouldn't i
There is a benefit for languages *other* than Java, that can use this as a
means to determine whether the interface is suitable for passing to the SAM
conversion machinery. The JDK support for lambda conversion is available to
other languages as well.
On Jan 16, 2013, at 1:51 AM, Florian Wei
The point is not to provide an ironclad guarantee that SAM conversion will
never fail. It is to capture the original author's design intent and provide a
small amount of compile-time tooling to help enforce that. Like @Override.
On Jan 16, 2013, at 2:21 AM, Remi Forax wrote:
> On 01/16/20
I think a significant fraction of the community would disagree with you.
We ran a survey where we collected suggestions for lambdafying API
methods, and this one came in top of the list.
There is a significant fraction of the developer community that uses the
logging API and doesn't care at a
Henry - just a quick comment on the class description. I think it would
be better not to include the sentence "Since 1.8 ..." as it that will
quickly become a historical note. It would be much better (in my view)
to just highlight the methods with something like "Several of the
methods take a Supp
Yes, this is a deliberate u-turn that comes as a result of the
unexpected interactions with the overloading resolution rules.
By having DoubleBlock extending Block, we created problems for
overloading. For example, consider this expected-to-be-common
overloading in Bunch:
Bunch transform
This suggestion makes me nervous, because we're already asking a great
deal of type inference. If you say
reduce(Operators::plus)
and there are eight versions of Operators to choose from (and add boxing
into the mix), I think we'll see a lot more inference errors. If the
user says Integer
Or when one functional interface wants to extend another, such as
IntBlock extends Block
On 11/14/2012 12:12 PM, Mike Duigou wrote:
The issue is primarily when one class wants to implement more than one
functional interface. If the names collide then the class will only be able to
impleme
I've updated the webrev for the first set of lambda functional interfaces
(JSR-335) with the feedback from the first review round. The updated webrev is:
http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/
This update includes:
- Mapper.map becomes Function.apply
- Factory.make becomes Suppl
I believe this change is not source compatible. If a user says:
try { clone() }
catch (RuntimeException e) { ... }
catch (CloneNotSupportedException e1) { }
this compiles today but would fail to compile under this change.
On Oct 14, 2012, at 7:06 PM, Mike Duigou wrote:
> Seems reasonab
From a concurrency perspective it is also preferable to NOT initialize
variables to their default values, as doing so can cause some weird
problems. For example:
class A {
public int x = 0;
public void increment() { ++x; }
public int get() { return x; }
}
// Thread X
// Assume: T
Oops, forgot to actually review the patch: approved.
On 5/10/2012 7:11 PM, Mike Duigou wrote:
Hello all;
A benign but potentially expensive race condition was discovered in
java.util.UUID. The initialization of numberGenerator may cause the creation of
a number of SecureRandom instances if mu
Farther afield: the "Holder" idiom for thread-safe lazy initialization
is one that we could now replace with invokedynamic (since a
ConstantCallSize acts as a lazily initialize cache), if there were only
a way to actually express the indy code from Java. This would let us
replace a class with
This all looks great.
My only concern is the mention of a "fences" API; I would think that
this might rise to the level of wanting its own JSR, since the memory
model does not necessarily provide for the all various relaxed
consistency modes that such an API would seem to imply, and might
inv
Reducing the number of SoftReferences in ReflectionHelper also seems an
attractive target for memory reduction. Rather than eight soft
references (eight extra objects), maintaining a SoftRef to the entire
RH, or at least to the part of the RH that is currently SR'ed if the two
non-SR'ed fields
;good enough"), we chose the path of "let's get something done."
On 4/2/2012 5:28 PM, Ulf Zibis wrote:
Thanks Brian.
Is there any article, why you prefer testNG over JUnit?
-Ulf
Am 02.04.2012 19:47, schrieb Brian Goetz:
Yes. We'll be migrating those to TestNG as part
Yes. We'll be migrating those to TestNG as part of the process.
On 3/30/2012 4:35 PM, Ulf Zibis wrote:
Am 30.03.2012 19:38, schrieb Brian Goetz:
Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit fra
Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?
There's good news on this front. We are in the process of making TestNG
a supported test framework for writing uni
I would think scanning for test files that have a main() method but not a @run
tag would be a good way to find more of these...
On Mar 11, 2012, at 4:21 AM, Alan Bateman wrote:
>
> I was looking at a test and happen to notice that it had a @build tag but no
> @run tag so the test wasn't actual
> In your subsequent email, I found that the asXXX and toXXX variants to be too
> similar to
> make it clear which throws and which does not or other differences unless it
> were a pervasive
> pattern that all developers would know and use.
We encourage this convention:
- Use "asXxx" to describ
I can recommend a good book
Sent from my iPhone
On Nov 7, 2011, at 4:53 PM, Rémi Forax wrote:
> On 11/07/2011 09:50 PM, Brian Goetz wrote:
>> Wait/notify may be better than sleeping, but semaphore/latch/barrier are
>> much better than wait/notify. Much.
>>
&
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Sent from my iPhone
On Nov 7, 2011, at 1:28 PM, chris hegarty wrote:
> Hi Gary,
>
> Thanks for taking this bug.
>
> In similar tests I've preferred to use j.u.c.Paser/CountDownLatc
This is a call for proposals for "point lambdafication candidates."
Once we introduce lambda to the language, the libraries immediately
start to look a little older. One subgoal of Project Lambda is to
upgrade the libraries to take better advantage of the new language
features. Of course, th
You might consider storing the cached item in checkAccess() in a
ThreadLocal instead of a static. Not only would this eliminate the
volatile accesses, but it reduces the chance of a "miss" in this
one-element cache, since it will then be impervious to interleavings
where other threads might us
It is an open question whether we want to support extension methods on
array types, and on the list for the EG to discuss.
On 3/17/2011 12:50 AM, Paulo Levi wrote:
Actually, doing maps and folds over arrays would be pretty cool too.
For some definition of "in", much work remains to deliver the functionality.
That said, this is the right place to propose ideas of APIs that are
sensible candidates for using lambdas. Could you sketch out what you
had in mind?
On 3/17/2011 12:39 AM, Paulo Levi wrote:
Would that ruin the ef
Ignore my comment -- I was reading the diffs backwards :(
On 2/22/2011 11:53 PM, Brian Goetz wrote:
I think you have a potential visibility problem here. You use -1 as the
initial value, but observing threads might see instead the default value
if the initializing write is not visible, and
I think you have a potential visibility problem here. You use -1 as the
initial value, but observing threads might see instead the default value
if the initializing write is not visible, and mistakenly think that the
zero default value represents a computed value. (This is different from
the
Changeset: 25462d7eee24
Author:briangoetz
Date: 2011-02-02 13:13 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25462d7eee24
7012540: java.util.Objects.nonNull() incorrectly named
Reviewed-by: darcy, weijun
! src/share/classes/java/io/PrintStream.java
! src/share/classes/jav
Overall these look like good additions. I haven't reviewed the code in
detail but a quick sanity check suggests that this is a good direction.
There's definitely some more work needed on the testing (for example,
testing that the contents of x and unmodifiable(x) are identical,
testing that t
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
But there are two methods we want to rename this to, and we can't use
this name twice. I propose we generate random method names instead.
01 AM, David Schlosnagle wrote:
On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz wrote:
Additional notes: After much discussion on core-libs-dev, the name
requireNonNull() seemed the least objectionable.
I think requireNonNull(x) is confusing.
Remember there's two versions of someModif
This ground has been already covered. "as", "to", etc, are fine for
conversions -- but by definition this is a conversion will never
succeed. At the same time, we need to leave room in the namespace for a
conversion operation that *will* succeed. (If we didn't need both, this
whole conversat
Additional notes: After much discussion on core-libs-dev, the name
requireNonNull() seemed the least objectionable.
I think requireNonNull(x) is confusing.
Remember there's two versions of someModifierNonNull being discussed;
the one currently in Objects is the precondition-enforcing variety,
There is a webrev for CR 7012540 (java.util.Objects.nonNull()
incorrectly named) at:
http://cr.openjdk.java.net/~briangoetz/7012540/webrev/
Code review would be appreciated.
Text of CR:
The class java.util.Objects is new for JDK 7. Its mission is to provide
"null-safe or null-tolerant v
I still don't like checkNonNull. It checks whether its argument is
non-null, but then what does it do? Throw an exception if it is
non-null? Throw an exception if it isn't? Do something else?
My aversion to checkNonNull naming pattern comes from experience. Long,
long ago in a code base far,
Thinking some more:
- The name nonNull() is just confusing. It could reasonably mean one
of several things, and we've seen this in people's reactions: some don't
like it for the throwing behavior because its not clear that it has a
strong checking behavior, others don't like it for the defau
(nullValue(, which allows extensibility through matchers.
However, I wouldn't expect either style to be part of the core language.
*From:* Brian Goetz
*To:* mark.reinh...@oracle.com
*Cc:* core-libs-dev@openjdk.java.net
I'm still troubled by the "check" prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior.
Here's an idea: Why not treat this as a (degenerate) kind of conversion
operation? Call it asNo
NPE; they'd mostly rather not have to deal explicitly with the
null case. Providing a something that reads more smoothly (like
checkNonNull(x)) will make them happier.
On 1/13/2011 6:57 PM, Ulf Zibis wrote:
Am 13.01.2011 23:38, schrieb Brian Goetz:
People use these to simplify cases
to go either way (both checkNonNull and ensureNonNull better match the actual
behavior of the method than plain nonNull) but we might as well pick the right
convention.
Rémi's throwIfNull(x) suggestion does capture the precise meaning,
though it begs the question of what, exactly, will be thrown
and
public static T nonNull(String obj) {
return (obj == null) ? "" : obj;
}
etc.
I don't know, this doesn't feel right to me. It would probably make more
sense to have a:
public static T defaulted(T test, T defVal) {
return test == null ? defVal : test;
}
This would cover both of the above c
201 - 300 of 317 matches
Mail list logo
