Re: class SplittableRandom
(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 sense at the time I did it, but ...)
What exactly limits us to adopt the PRNG from SR into TLR, thus gaining
the same good statistical properties? Does extending Random actually
forces us to match the PRNG j.u.Random has? It does not seem likely if
we don't control the seed for TLR anyway.
There are two different questions here:
1. Why a new API / class?
SplittableRandom takes a form that we are likely to see more
of as we improve support for structured parallelism:
pseudo-interface SplittableGeneratorT {
T generate();
SplittableGeneratorT split();
}
As opposed to ThreadLocalRandom's form:
pseudo-interface PerThreadGeneratorT {
T generate() {
// lazily construct and use a thread-local instance
}
}
As I've mentioned, each form is useful, but there's
little overlap in the contexts in which they are useful.
While you can emulate the effects of one with the other,
it's not at all pretty or efficient. Without an explicit call
to split(), the thread-local form would need some side-channel to
construct an instance of known form (rather than default-initialize).
Conversely, without automated thread-local-ness, you'd need
some other means of sharing use of the same instance
in different parts of a program running in the same thread,
and may encounter variants of memory locality/contention
we've seen.
One underlying motivation for introducing SplittableRandom
in JDK8 is to establish and get some usage experience with
generators of this form, while at the same time addressing a
known gap in java.util.stream support for using random streams.
2. Can/should we improve ThreadLocalRandom?
Probably yes. The ThreadLocalRandom javadocs/specs don't
themselves promise that they use the same base generator
algorithm as java.util.Random. When TLR was introduced
in JDK7, it was a judgement call to make it identical
to java.util.Random except for the the thread-local-ness,
maintaining the same speed/quality tradeoffs.
java.util.Random's algorithm does have known weaknesses,
but it is far from the worst choice. So it is not all
that terrible that java.util.Random specs mandate use
of this algorithm. But for TLR, we should re-explore
options. The algorithm underlying SplittableRandom
(minus everything surrounding splits) is one possible
candidate.
Since nothing else depends on these internals, so long as
they don't lose RNG quality or noticeably impact
performance, we can look into this during the
performance/functionality improvement phase of OpenJDK8.
-Doug
Re: RFR: 8015317: Optional.filter, map, and flatMap
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 class.
Cheers,
Henry
On Jul 13, 2013, at 4:35 PM, Jed Wesley-Smith j...@wesleysmith.io wrote:
I did supply a test that you can use to try it.
What we are talking about is whether type BoxParent is substitutable
by BoxChild in the contravariant position. Intuitively we think we
only need Box? extends Parent because we only care about the type
parameter, but the type – as you point out – is actually different.
BoxParent is not inherited by BoxChild.
Specifically, if we have a consuming Box, and we replace it with a Box
of a more specific type parameter, we could attempt feed the more
general type into it, ie. a BoxChild isn't going to appreciate
having Parent fed to it. This is why covariance and mutable containers
don't mix well, and why Java's covariant arrays are problematic.
In this situation we have an immutable container, and we can
substitute the type of our container with one of a more specific type,
as it will only ever supply a value – and a value of Child will
suffice as a Parent. So, for this case we need a Box that is
substitutable, and therefore we need to add the covariance to our box.
? extends Box is simply adding covariance to our Box type.
For a much better explanation than I can give about this, see this
excellent post describing generics in Scala, which – apart from have
declaration-site variance and using [A] in place of A – generally
follow the same pattern:
http://termsandtruthconditions.herokuapp.com/blog/2012/12/29/covariance-and-contravariance-in-scala/
cheers,
jed.
On 14 July 2013 04:49, Henry Jen henry@oracle.com
mailto:henry@oracle.com wrote:
I think the type you talking about here is Optional? extends U
instead of ? extends OptionalU.
IIRC, Optional? extends U is not a subtype of OptionalU, just
like any other Collection class. ListChild is not a ListParent.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith j...@wesleysmith.io
mailto:j...@wesleysmith.io wrote:
The ? extends Optional is unnecessary in flatMap as Optional is
final.
interestingly enough, it actually is.
try the following test:
class OptionalTest {
class Parent {};
class Child extends Parent {};
@Test public void covariantReturn() {
OptionalParent some = some(new Parent());
FunctionParent, OptionalChild f = new FunctionParent,
OptionalChild() {
@Override public OptionalChild apply(Parent p) {
return some(new Child());
}
};
OptionalParent mapped = some.Parent flatMap(f);
assertThat(mapped.get(), notNullValue());
}
}
adapted from the fugue test suite:
https://bitbucket.org/atlassian/fugue/src/96a65067fb7aaf1edae1bffa07167a5865cbebec/src/test/java/com/atlassian/fugue/OptionTest.java#cl-155
The point to remember is that OptionalChild is a type and as
such is actually a subtype of OptionalParent – and therefore
requires a covariant return.
cheers,
jed.
On 13 July 2013 04:15, Mike Duigou mike.dui...@oracle.com
mailto:mike.dui...@oracle.com wrote:
The ? extends Optional is unnecessary in flatMap as Optional
is final. Otherwise this looks good.
Mike
On Jul 5 2013, at 14:37 , Henry Jen wrote:
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8015317.0/webrev/
http://cr.openjdk.java.net/%7Ehenryjen/ccc/8015317.0/webrev/
Which adds following method to Optional,
public static T OptionalT ofNullable(T value) {}
public OptionalT filter(Predicate? super T predicate) {}
publicU OptionalU map(Function? super T, ? extends U
mapper) {}
publicU OptionalU flatMap(Function? super T, ? extends
OptionalU
mapper) {}
Also included is some cleanup on javadoc.
Cheers,
Henry
Re: RFR: 8015317: Optional.filter, map, and flatMap
I think the type you talking about here is Optional? extends U instead of ?
extends OptionalU.
IIRC, Optional? extends U is not a subtype of OptionalU, just like any
other Collection class. ListChild is not a ListParent.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith j...@wesleysmith.io wrote:
The ? extends Optional is unnecessary in flatMap as Optional is final.
interestingly enough, it actually is.
try the following test:
class OptionalTest {
class Parent {};
class Child extends Parent {};
@Test public void covariantReturn() {
OptionalParent some = some(new Parent());
FunctionParent, OptionalChild f = new FunctionParent,
OptionalChild() {
@Override public OptionalChild apply(Parent p) {
return some(new Child());
}
};
OptionalParent mapped = some.Parent flatMap(f);
assertThat(mapped.get(), notNullValue());
}
}
adapted from the fugue test suite:
https://bitbucket.org/atlassian/fugue/src/96a65067fb7aaf1edae1bffa07167a5865cbebec/src/test/java/com/atlassian/fugue/OptionTest.java#cl-155
The point to remember is that OptionalChild is a type and as such is
actually a subtype of OptionalParent – and therefore requires a covariant
return.
cheers,
jed.
On 13 July 2013 04:15, Mike Duigou mike.dui...@oracle.com wrote:
The ? extends Optional is unnecessary in flatMap as Optional is final.
Otherwise this looks good.
Mike
On Jul 5 2013, at 14:37 , Henry Jen wrote:
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8015317.0/webrev/
Which adds following method to Optional,
public static T OptionalT ofNullable(T value) {}
public OptionalT filter(Predicate? super T predicate) {}
publicU OptionalU map(Function? super T, ? extends U mapper) {}
publicU OptionalU flatMap(Function? super T, ? extends OptionalU
mapper) {}
Also included is some cleanup on javadoc.
Cheers,
Henry
Re: RFR: 8015317: Optional.filter, map, and flatMap
XYChild is not a subtype of XY? extends Parent. We have to go
wildcard all the way - X? extends Y? extends Parent.
The subtyping rules don't care about final-ness of types. For example,
XString is a distinct type from X? extends String, even though
String has only one subtype (itself).
Zhong Yu
On Sun, Jul 14, 2013 at 8:04 AM, Jed Wesley-Smith j...@wesleysmith.io wrote:
(accidentally didn't post to the list)
You probably know that the example provided is not completed ported to
work with our Optional implementation,
It should be, for the example I wrote an Optional that is final and should
be otherwise identical. It should certainly be fairly easy for any
committer to try. If you can make it work without the ? extends Optional
I'd love an explanation of how.
and fugue works around the type system with Option as abstract class.
As I've tried to explain, this isn't about the implementation of the
container class, but how covariance works with a parameterised class.
We originally had the non-, but in a discussion with Brian he alerted us to
the fact that the signature was wrong. We hastily fixed it:
https://bitbucket.org/atlassian/fugue/commits/9eca663326a5baeb8f23974732ec585d5627a05c
To further demonstrate, I give you a minimal example of a final Optional
implementation that does not compile for this test:
https://gist.github.com/jedws/5993596#file-gistfile1-java-L57
cheers,
jed.
On 14 July 2013 15:02, Henry Jen henry@oracle.com wrote:
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 class.
Cheers,
Henry
On Jul 13, 2013, at 4:35 PM, Jed Wesley-Smith
j...@wesleysmith.ioj...@wesleysmith.iowrote:
I did supply a test that you can use to try it.
What we are talking about is whether type BoxParent is substitutable
by BoxChild in the contravariant position. Intuitively we think we only
need Box? extends Parent because we only care about the type parameter,
but the type – as you point out – is actually different. BoxParent is not
inherited by BoxChild.
Specifically, if we have a consuming Box, and we replace it with a Box
of a more specific type parameter, we could attempt feed the more general
type into it, ie. a BoxChild isn't going to appreciate having Parent fed
to it. This is why covariance and mutable containers don't mix well, and
why Java's covariant arrays are problematic.
In this situation we have an immutable container, and we can substitute
the type of our container with one of a more specific type, as it will only
ever supply a value – and a value of Child will suffice as a Parent. So,
for this case we need a Box that is substitutable, and therefore we need to
add the covariance to our box.
? extends Box is simply adding covariance to our Box type.
For a much better explanation than I can give about this, see this
excellent post describing generics in Scala, which – apart from have
declaration-site variance and using [A] in place of A – generally follow
the same pattern:
http://termsandtruthconditions.herokuapp.com/blog/2012/12/29/covariance-and-contravariance-in-scala/
cheers,
jed.
On 14 July 2013 04:49, Henry Jen henry@oracle.com wrote:
I think the type you talking about here is Optional? extends U instead
of ? extends OptionalU.
IIRC, Optional? extends U is not a subtype of OptionalU, just like
any other Collection class. ListChild is not a ListParent.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith j...@wesleysmith.io
wrote:
The ? extends Optional is unnecessary in flatMap as Optional is final.
interestingly enough, it actually is.
try the following test:
class OptionalTest {
class Parent {};
class Child extends Parent {};
@Test public void covariantReturn() {
OptionalParent some = some(new Parent());
FunctionParent, OptionalChild f = new FunctionParent,
OptionalChild() {
@Override public OptionalChild apply(Parent p) {
return some(new Child());
}
};
OptionalParent mapped = some.Parent flatMap(f);
assertThat(mapped.get(), notNullValue());
}
}
adapted from the fugue test suite:
https://bitbucket.org/atlassian/fugue/src/96a65067fb7aaf1edae1bffa07167a5865cbebec/src/test/java/com/atlassian/fugue/OptionTest.java#cl-155
The point to remember is that OptionalChild is a type and as such is
actually a subtype of OptionalParent – and therefore requires a
covariant return.
cheers,
jed.
On 13 July 2013 04:15, Mike Duigou mike.dui...@oracle.com wrote:
The ? extends Optional is unnecessary in flatMap as Optional is final.
Otherwise this looks good.
Mike
On Jul 5 2013, at 14:37 , Henry Jen wrote:
Hi,
Please review the webrev at
Re: RFR: 8015317: Optional.filter, map, and flatMap
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? super T,? extends CompletionStageU fn)
should be
thenCompose(Function? super T,? extends CompletionStage? extends U fn)
The problem is probably wide spread, and we need a tool to find these mistakes.
Zhong Yu
On Sun, Jul 14, 2013 at 8:04 AM, Jed Wesley-Smith j...@wesleysmith.io wrote:
(accidentally didn't post to the list)
You probably know that the example provided is not completed ported to
work with our Optional implementation,
It should be, for the example I wrote an Optional that is final and should
be otherwise identical. It should certainly be fairly easy for any
committer to try. If you can make it work without the ? extends Optional
I'd love an explanation of how.
and fugue works around the type system with Option as abstract class.
As I've tried to explain, this isn't about the implementation of the
container class, but how covariance works with a parameterised class.
We originally had the non-, but in a discussion with Brian he alerted us to
the fact that the signature was wrong. We hastily fixed it:
https://bitbucket.org/atlassian/fugue/commits/9eca663326a5baeb8f23974732ec585d5627a05c
To further demonstrate, I give you a minimal example of a final Optional
implementation that does not compile for this test:
https://gist.github.com/jedws/5993596#file-gistfile1-java-L57
cheers,
jed.
On 14 July 2013 15:02, Henry Jen henry@oracle.com wrote:
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 class.
Cheers,
Henry
On Jul 13, 2013, at 4:35 PM, Jed Wesley-Smith
j...@wesleysmith.ioj...@wesleysmith.iowrote:
I did supply a test that you can use to try it.
What we are talking about is whether type BoxParent is substitutable
by BoxChild in the contravariant position. Intuitively we think we only
need Box? extends Parent because we only care about the type parameter,
but the type – as you point out – is actually different. BoxParent is not
inherited by BoxChild.
Specifically, if we have a consuming Box, and we replace it with a Box
of a more specific type parameter, we could attempt feed the more general
type into it, ie. a BoxChild isn't going to appreciate having Parent fed
to it. This is why covariance and mutable containers don't mix well, and
why Java's covariant arrays are problematic.
In this situation we have an immutable container, and we can substitute
the type of our container with one of a more specific type, as it will only
ever supply a value – and a value of Child will suffice as a Parent. So,
for this case we need a Box that is substitutable, and therefore we need to
add the covariance to our box.
? extends Box is simply adding covariance to our Box type.
For a much better explanation than I can give about this, see this
excellent post describing generics in Scala, which – apart from have
declaration-site variance and using [A] in place of A – generally follow
the same pattern:
http://termsandtruthconditions.herokuapp.com/blog/2012/12/29/covariance-and-contravariance-in-scala/
cheers,
jed.
On 14 July 2013 04:49, Henry Jen henry@oracle.com wrote:
I think the type you talking about here is Optional? extends U instead
of ? extends OptionalU.
IIRC, Optional? extends U is not a subtype of OptionalU, just like
any other Collection class. ListChild is not a ListParent.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith j...@wesleysmith.io
wrote:
The ? extends Optional is unnecessary in flatMap as Optional is final.
interestingly enough, it actually is.
try the following test:
class OptionalTest {
class Parent {};
class Child extends Parent {};
@Test public void covariantReturn() {
OptionalParent some = some(new Parent());
FunctionParent, OptionalChild f = new FunctionParent,
OptionalChild() {
@Override public OptionalChild apply(Parent p) {
return some(new Child());
}
};
OptionalParent mapped = some.Parent flatMap(f);
assertThat(mapped.get(), notNullValue());
}
}
adapted from the fugue test suite:
https://bitbucket.org/atlassian/fugue/src/96a65067fb7aaf1edae1bffa07167a5865cbebec/src/test/java/com/atlassian/fugue/OptionTest.java#cl-155
The point to remember is that OptionalChild is a type and as such is
actually a subtype of OptionalParent – and therefore requires a
covariant return.
cheers,
jed.
On 13 July 2013 04:15, Mike Duigou mike.dui...@oracle.com wrote:
The ? extends Optional is unnecessary in flatMap as Optional is
Re: RFR: 8017513: Support for closeable streams
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- and post-conditions go with methods.
closeability is an invariant as far as I can see. Hence must be
maintained in a substitutable subtype - which it is not no matter which
way you try the inheritance.
David
On Fri, Jul 12, 2013 at 6:22 AM, David Holmes david.hol...@oracle.com
mailto:david.hol...@oracle.com wrote:
On 12/07/2013 6:22 AM, Paul Benedict wrote:
Paul S.'s said the negative of using AutoCloseable is it is
no longer
clear whether a stream should be closed or not (6/20). That's
true because
the semantics of AutoCloseable indicates you have a resource
that requires
closing.
However, the choice to make MayHoldCloseableResource a
sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution principle *says that sub-interfaces can't loosen
the contracts
of their superinterface.
Not quite. It says:
- Preconditions cannot be strengthened in a subtype.
- Postconditions cannot be weakened in a subtype.
- Invariants of the supertype must be preserved in a subtype.
Question is: what kind of property is closeability?
If anything, AutoCloseable should be subclass of this new
interface, which MIGHT hold a resource that requires closing.
The current
choice is just plainly backwards.
No what you just said is plainly backwards. If AutoCloseable is a
subtype of MHCR then you should be able to use an AC instance
anywhere you use a MHCR. But valid code doesn't have to close a
MHCR, so if you replace it with an AC which requires closing then
you have broken code. Hence not substitutable, hence invalid
inheritance relationship.
But if anything this is just another variation of the
Square/Rectangle inheritance fallacy. While you can define either as
a specialization of the other, you can always violate
substitutability by doing something that relies on the property that
gets specialized.
David
-
For the above reason stated, and for the fact the interface adds
no new
functionality, it's superfluous. If the interface relationship
can't be
inverted, then chuck it -- it does nothing anyway. At the least,
keep the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com
mailto:henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface,
java.util.__MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need
to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that
situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/__pipermail/lambda-libs-spec-__experts/2013-June/002081.html
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to
guide users/static
analysis tools that a MHCR instance that definitely
hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is
that you don't
want to give up the last reference to a closeable
resource without
calling close()—and not leak references which out-live
the call to
close(). This is definitely not a property of the type
of the resource,
so I don't see why the MayHoldCloseableResource
interface is needed (or
can confer relevant information). The HoldsResource
annotation could be
useful, but based on the current documentation, it's not
clear if it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The
MHCR is
different from AutoCloseable on the chances of holding
critical resources.
Perhaps that suggests the javadoc is not clear enough, I
would like to
know what is important and missing.
Cheers,
Re: RFR: 8017513: Support for closeable streams
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-condition, it must be closed. That's the expected behavior when using
this type.
On Sun, Jul 14, 2013 at 10:53 PM, David Holmes david.hol...@oracle.comwrote:
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- and post-conditions go with methods.
closeability is an invariant as far as I can see. Hence must be
maintained in a substitutable subtype - which it is not no matter which way
you try the inheritance.
David
On Fri, Jul 12, 2013 at 6:22 AM, David Holmes david.hol...@oracle.com
mailto:david.holmes@oracle.**com david.hol...@oracle.com wrote:
On 12/07/2013 6:22 AM, Paul Benedict wrote:
Paul S.'s said the negative of using AutoCloseable is it is
no longer
clear whether a stream should be closed or not (6/20). That's
true because
the semantics of AutoCloseable indicates you have a resource
that requires
closing.
However, the choice to make MayHoldCloseableResource a
sub-interface of
AutoClosable should be resisted. It's an inverted design. The
Liskov
*substitution principle *says that sub-interfaces can't loosen
the contracts
of their superinterface.
Not quite. It says:
- Preconditions cannot be strengthened in a subtype.
- Postconditions cannot be weakened in a subtype.
- Invariants of the supertype must be preserved in a subtype.
Question is: what kind of property is closeability?
If anything, AutoCloseable should be subclass of this new
interface, which MIGHT hold a resource that requires closing.
The current
choice is just plainly backwards.
No what you just said is plainly backwards. If AutoCloseable is a
subtype of MHCR then you should be able to use an AC instance
anywhere you use a MHCR. But valid code doesn't have to close a
MHCR, so if you replace it with an AC which requires closing then
you have broken code. Hence not substitutable, hence invalid
inheritance relationship.
But if anything this is just another variation of the
Square/Rectangle inheritance fallacy. While you can define either as
a specialization of the other, you can always violate
substitutability by doing something that relies on the property that
gets specialized.
David
-
For the above reason stated, and for the fact the interface adds
no new
functionality, it's superfluous. If the interface relationship
can't be
inverted, then chuck it -- it does nothing anyway. At the least,
keep the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com
mailto:henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface,
java.util.__**MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need
to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that
situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/_**
_pipermail/lambda-libs-spec-__**experts/2013-June/002081.htmlhttp://mail.openjdk.java.net/__pipermail/lambda-libs-spec-__experts/2013-June/002081.html
http://mail.openjdk.java.net/**pipermail/lambda-libs-spec-**
experts/2013-June/002081.htmlhttp://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to
guide users/static
analysis tools that a MHCR instance that definitely
hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is
that you don't
want to give up the last reference to a closeable
resource without
calling close()—and not leak references which out-live
the call to
close(). This is definitely not a property of the type
of the resource,
Re: RFR: 8017513: Support for closeable streams
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 the AutoCloseable type, as in the post-condition, it must be closed. That's the expected behavior when using this type. That's not a post-condition in a type substitutability sense, it is an invariant property of the object. David On Sun, Jul 14, 2013 at 10:53 PM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: 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- and post-conditions go with methods. closeability is an invariant as far as I can see. Hence must be maintained in a substitutable subtype - which it is not no matter which way you try the inheritance. David On Fri, Jul 12, 2013 at 6:22 AM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com mailto:david.holmes@oracle.__com mailto:david.hol...@oracle.com wrote: On 12/07/2013 6:22 AM, Paul Benedict wrote: Paul S.'s said the negative of using AutoCloseable is it is no longer clear whether a stream should be closed or not (6/20). That's true because the semantics of AutoCloseable indicates you have a resource that requires closing. However, the choice to make MayHoldCloseableResource a sub-interface of AutoClosable should be resisted. It's an inverted design. The Liskov *substitution principle *says that sub-interfaces can't loosen the contracts of their superinterface. Not quite. It says: - Preconditions cannot be strengthened in a subtype. - Postconditions cannot be weakened in a subtype. - Invariants of the supertype must be preserved in a subtype. Question is: what kind of property is closeability? If anything, AutoCloseable should be subclass of this new interface, which MIGHT hold a resource that requires closing. The current choice is just plainly backwards. No what you just said is plainly backwards. If AutoCloseable is a subtype of MHCR then you should be able to use an AC instance anywhere you use a MHCR. But valid code doesn't have to close a MHCR, so if you replace it with an AC which requires closing then you have broken code. Hence not substitutable, hence invalid inheritance relationship. But if anything this is just another variation of the Square/Rectangle inheritance fallacy. While you can define either as a specialization of the other, you can always violate substitutability by doing something that relies on the property that gets specialized. David - For the above reason stated, and for the fact the interface adds no new functionality, it's superfluous. If the interface relationship can't be inverted, then chuck it -- it does nothing anyway. At the least, keep the annotation. Paul On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com mailto:henry@oracle.com mailto:henry@oracle.com mailto:henry@oracle.com wrote: On 07/11/2013 01:13 AM, Florian Weimer wrote: On 07/10/2013 11:30 PM, Henry Jen wrote: A new interface, java.util.MayHoldCloseableResource, indicates an implementation may or may not hold a resource need to be closed. Why doesn't close() throw Exception? Because there is really much a developer can do on that situation. The API simply make it not throw a *checked* exception. See EG discussion on this topic,
Re: RFR 7122142 : (ann) Race condition between isAnnotationPresent and getAnnotations
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 memoization pattern that installs a Future for the AnnotationType). Thanks, David *From: *Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com *Subject: **RFR 7122142 : (ann) Race condition between isAnnotationPresent and getAnnotations* *Date: *8 juli 2013 22:54:12 CEST *To: *Joel Borggrén-Franck joel.fra...@oracle.com mailto:joel.fra...@oracle.com *Cc: *Alan Bateman alan.bate...@oracle.com mailto:alan.bate...@oracle.com, core-libs-dev@openjdk.java.net mailto:core-libs-dev@openjdk.java.net core-libs-dev core-libs-dev@openjdk.java.net mailto:core-libs-dev@openjdk.java.net Helo, I need a Reviewer for the following patch: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/ This fixes deadlock situation described in bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122142 The in-depth evaluation of the patch is described in the introductory message of this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018226.html The above is the 5th revision of the patch that also makes sure a single AnnotationType instance is ever returned for the same Class object even when multiple threads concurrently request one. Regards, Peter On 07/05/2013 04:04 PM, Joel Borggrén-Franck wrote: Hi Peter, Thanks for the quick update! While I have looked over the changes to j.l.Class and the cas in AnnotationType I don't think I'm qualified to review that. (FWIW it looked fine to me but my jmm isn't swapped in at the moment so I won't pretend to know the interactions between volatile and Unsafe cas). Thinking out loud I suppose we can assume a stable offset of fields in Class, and I realize that part has been under review before. The rest of AnnotationType, AnnotationParser and the tests look fine though. I also ran the tests before and after the change and results were as expected. Since I'm not a Reviewer kind of reviewer you need to get one those to sign off but after that I think you are good to go. I can sponsor this as well if Alan is busy. cheers /Joel On 5 jul 2013, at 11:12, Peter Levartpeter.lev...@gmail.com wrote: Hi Again, Sorry, the 4th revision I posted is not rebased to the current tip of jdk8-tl so it contained some diffs that reverted some things. Here's the correct patch: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/ Regards, Peter On 07/05/2013 10:32 AM, Peter Levart wrote: Hi Joel, Here's the 4th revision of the patch: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.04/ This one introduces CAS-ing of the AnnotationType instance into the Class.annotationType field so that there's only a single instance ever returned for a single Class. I also introduced new private static Class.Atomic nested class that is used to lazily initialize Unsafe machinery and to provide a safe wrapper for internal j.l.Class use. Previously this was part of ReflectionData nested class because it was only used for it's purpose. In anticipation to have a need for more atomic operations in the future, I moved this code to a separate class. ReflectionData is now just a record. Regards, Peter
