Joel, Peter,
I've looked at the synchronization changes and the use of CAS and it
seems sound.
The only performance-related concern is the wasted effort when multiple
threads each call "new AnnotationType(annotationClass)". But if that
turns out to be an issue we can address it (using memoiz
On 15/07/2013 2:47 PM, Paul Benedict wrote:
It's a post-condition to using the object. I've emphasized the "must"
part of the contract but the full contract is: "must be closed when it
is no longer needed". That's a pretty clear post-condition language that
must be true. So when you're done with
It's a post-condition to using the object. I've emphasized the "must" part
of the contract but the full contract is: "must be closed when it is no
longer needed". That's a pretty clear post-condition language that must be
true. So when you're done with the AutoCloseable type, as in the
post-conditi
On 12/07/2013 11:57 PM, Paul Benedict wrote:
I see closeability as a postcondition. A subtype can't weaken it. The
contract of AutoCloseable says its a resource that "must" be closed. Now
MHCR says it can/should/doesn't have to be closed -- so it is backwards.
A "postcondition" of what? pre- an
Another example of possible missing a wildcard
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletionStage.html#thenCompose%28java.util.function.Function%29
thenCompose(Function> fn)
should be
thenCompose(Function> fn)
The problem is probably wide spread, and we nee
X> is not a subtype of X>. We have to go
wildcard all the way - X>.
The subtyping rules don't care about final-ness of types. For example,
X is a distinct type from X, even though
String has only one subtype (itself).
Zhong Yu
On Sun, Jul 14, 2013 at 8:04 AM, Jed Wesley-Smith wrote:
> (accident
I think the type you talking about here is Optional instead of ?
extends Optional.
IIRC, Optional is not a subtype of Optional, just like any
other Collection class. List is not a List.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith wrote:
> > The ? extends Optional is unnecess
I think I understand what you are saying. However, unless we make
Optional not final, the extends part just doesn't matter.
You probably know that the example provided is not completed ported to
work with our Optional implementation, and fugue works around the type
system with Option as abstract c
(Sorry to postpone answering this one while tied up in logistics...)
On 07/11/13 08:23, Aleksey Shipilev wrote:
On 07/11/2013 04:16 PM, Doug Lea wrote:
(I've been contemplating re-exploring alternatives in TLR,
but the options are more limited because it is a subclass
of Random. Which made sens
