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,
(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
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
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
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
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.,
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
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)
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)
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
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 :)
+1 on all changes, except perhaps for this one in Collections.copy:
ListIterator? super T di=dest.listIterator();
ListIterator? extends T si=src.listIterator();
for (int i=0; isrcSize; i++) {
di.next();
di.set(si.next());
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
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
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.
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
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 peter.lev...@gmail.com 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:
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: 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
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 pure
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
!
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
!
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
!
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
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
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
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
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 interest
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;
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
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
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 ComparatorString c = new Comparator() { ... }
is effectively implemented automatically
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))
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
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 fo...@univ-mlv.fr wrote:
On 04/26/2013
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).
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/
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
.
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
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
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
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
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
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
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
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 it?
(If javac is supposed to synthesize
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 this annotation
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
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 BlockDouble, we created problems for
overloading. For example, consider this expected-to-be-common
overloading in BunchT:
U BunchU
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
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
Or when one functional interface wants to extend another, such as
IntBlock extends BlockInteger
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
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
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
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:
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 a
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
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
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 framework
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 of the process.
On 3/30/2012 4
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
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 actually
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 describe
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 chris.hega...@oracle.com wrote:
Hi Gary,
Thanks for taking this bug.
In similar tests I've preferred to use
I can recommend a good book
Sent from my iPhone
On Nov 7, 2011, at 4:53 PM, Rémi Forax fo...@univ-mlv.fr 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.
Sent from my iPhone
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,
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.
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 use
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
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
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 conversation
The only reason we're even having this discussion now -- as we're well
past freeze for 7 -- is to prevent the current situation from getting
carved into stone, where we have a nonNull() precondition-enforcing
method in Objects. While the correct name for the
postcondition-producing version is
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
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
I relatively recently discovered the existence of the new
java.util.Objects class, a repository of useful methods that people end
up rewriting endlessly for each project in classes named Util and such.
Most of the methods have to do with centralizing null handling (such
as Objects.hashCode(),
and
public staticT 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 T defaulted(T test, T defVal) {
return test == null ? defVal : test;
}
This would cover both of the above
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
,
is(not(nullValue(, which allows extensibility through matchers.
However, I wouldn't expect either style to be part of the core language.
*From:* Brian Goetz brian.go...@oracle.com
*To:* mark.reinh...@oracle.com
*Cc:* core-libs-dev
While on the subject of serialization deadlocks in core libraries, Amy Williams
and Mike Ernst did a paper (also became Amy's masters thesis) back when Mike
was at MIT on static detection of deadlocks and they built a tools which found
several deadlocks in the JDK collections. Does anyone
http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/
Looks good to me, and very easy to review.
One question on this. There are a couple of places where the original
statement was too long to fit on a single line so the RHS of the assignment
was pushed into a second line. With
Coin is part of Java 7. There may be *more* Coin features (Coin: the flip
side) coming in 8.
On Dec 16, 2010, at 2:15 PM, Ulf Zibis wrote:
Hi all,
in the recent issue of the German Java Spektrum I read, that the project
coin features are
scheduled for JDK-8 2012 (Plan B). (Jigsaw and
bits into the
Java code rather than being hidden in the bowels of the VM; and its
implementation will be faster than (Thread.getState() == RUNNABLE) regardless
of the implementation of the latter.
Éamonn
On 5/12/10 8:27 AM, Brian Goetz wrote:
As Eamonn writes it, it will never cache miss
As Eamonn writes it, it will never cache miss but may frequently branch
mispredict (possibly multiple times). If you do a shift + mask + index into a
small table, it will cache miss most the time but never branch mispredict.
(In a real program it will cache miss frequently since thread state
We're in the process of spinning up this effort. We have no answer for you
now other than there will be some, but as we progress you'll see details
showing up in one or more of: this list, lambda-dev, concurrency-interest.
On 11/24/2010 1:57 PM, Adam Rabung wrote:
Hi,
I would like to learn
The performance impact of this might be severe when deserializing object
graphs with lots of final fields (and we recommend using final fields wherever
possible.) And, I'm a little unclear on the approach here. If the goal is to
provide a happens-before edge between deserializing an object
Is it possible to coalesce the fences so that we don't incur them on every
field write?
On 11/22/2010 10:10 AM, Doug Lea wrote:
On 11/22/10 09:35, Rémi Forax wrote:
This is a patch to default deserialization so that it uses volatile-write when
setting final fields:
Mostly style issues, but at least one likely bug.
In a few places, you've used @SuppressWarnings(unchecked). While this may
well be unavoidable, it is worth factoring this out into the smallest possible
chunk. For BandStructure, you've applied it to the whole class, and there's
some big
Explicit non-objection :)
On Aug 13, 2010, at 9:58 AM, Chris Hegarty wrote:
The issue of whether Threads should be Cloneable came up during the
discussion of another problem. I talked to David about this and we believe
there is no value being able to clone a thread, in fact it can cause
So, this aspect of COIN is still somewhat new, and so I think it is worth
looking at carefully. There is a specification for this feature that was
discussed on coin-dev. You might want to take a look and comment -- its not
too late.
On Aug 12, 2010, at 5:00 PM, David Holmes wrote:
Mandy
This code has thread-safety issues. There is no happens-before between the
writes to suppressedExceptions (and its referenced state) and the places where
it is iterated (e.g., line 576).
You could plug this hole by replacing the idiom at line 576 (and similar) with
for (Throwable se :
201 - 299 of 299 matches
Mail list logo
