I guess your methods should return BoxA to be comparable to
Stream/Optional/CompletionStage cases.
On Mon, Jul 15, 2013 at 2:17 AM, Jed Wesley-Smith j...@wesleysmith.io wrote:
ignore me, you do actually need both ? extends on the type constructor and
the inner type – dunno what I was thinking.
On 07/12/2013 01:22 PM, David Holmes 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
Mandy,
Looks fine to me. I agree that we should back it out for 7u40. I
would think we want to leave the change in jdk8 and continue the
investigation and resolving the JCK failures for jdk8. Is that what
you are thinking? If so, we don't need to back it out from jdk8.
I was hoping to
Hi, Peter,
Not a reviewer, and have barely any time to have the careful review, so
just a few nitpicks below:
On 07/09/2013 12:54 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
AnnotationParser.java:
- Do you want make contains() generic?
Changeset: e4ce6502eac0
Author:plevart
Date: 2013-07-15 10:55 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0
7122142: (ann) Race condition between isAnnotationPresent and getAnnotations
Reviewed-by: dholmes, jfranck
! src/share/classes/java/lang/Class.java
!
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8016579
http://bugs.sun.com/view_bug.do?bug_id=8016579
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016579/webrev.00/
Summary:
We have THREE locales in action:
1. Thread default locale - dictates
Hi David,
I think now that recursion is broken by special-purpose parsing
code-path and, depending on how we solve the other contention point in
j.l.Class.initAnnotationsIfNecessary(), there might be no danger of
dead-lock even if we used double-checked locking idiom in
On 7/15/2013 4:14 PM, Seán Coffey wrote:
Mandy,
Looks fine to me. I agree that we should back it out for 7u40. I
would think we want to leave the change in jdk8 and continue the
investigation and resolving the JCK failures for jdk8. Is that what
you are thinking? If so, we don't need
On 07/15/2013 11:04 AM, Aleksey Shipilev wrote:
Hi, Peter,
Not a reviewer, and have barely any time to have the careful review, so
just a few nitpicks below:
On 07/09/2013 12:54 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
Thanks for the review David,
I have pushed version 5 of the patch.
cheers
/Joel
On 2013-07-15, David Holmes wrote:
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
Changeset: 7cc35dd1885d
Author:coffeys
Date: 2013-07-15 13:42 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cc35dd1885d
8017566: Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl
Reviewed-by: mchung
! src/share/lib/security/java.security-linux
!
On 07/12/2013 09:26 PM, Paul Sandoz wrote:
Here is the webrev:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-splittable-random/webrev/
OK, early performance data follows. I've used a simple benchmark [1] to
estimate the standalone costs for getting int/long/double, as well as
the usage
On 07/15/2013 04:36 PM, Peter Levart wrote:
I was guided by the Collection.contains() signature:
CollectionT {
boolean contains(Object o);
Dunno. This was done for compatibility with non-generic code. In your
code, you seem always know the type of the argument, it does not bother
me to
Thank you Joel, Alan, David and Aleksey for reviews.
Regards, Peter
On 07/15/2013 02:30 PM, Joel Borggrén-Franck wrote:
Thanks for the review David,
I have pushed version 5 of the patch.
cheers
/Joel
On 2013-07-15, David Holmes wrote:
Joel, Peter,
I've looked at the synchronization
On 07/15/2013 03:02 PM, Aleksey Shipilev wrote:
The results are here [2]. Notable results follow.
Hi Aleksey,
Somehow the files in the directories under:
http://cr.openjdk.java.net/~shade/8020292/data/
... are not accessible (403 - Forbidden), although the sub-directories
are browsable...
On 07/15/2013 05:43 PM, Peter Levart wrote:
On 07/15/2013 03:02 PM, Aleksey Shipilev wrote:
The results are here [2]. Notable results follow.
Somehow the files in the directories under:
http://cr.openjdk.java.net/~shade/8020292/data/
... are not accessible (403 - Forbidden), although the
On 07/15/13 00:24, Martin Buchholz wrote:
Thoughts:
I was sad when ThreadLocalRandom reused the lousy pseudorandom implementation
from Random. I continue to think we can do better.
Yes, I'm working on it.
It would be nice if we could guarantee a minimum period of 2^64.
OK. I cannot
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
I'm not entirely sure that is a problem, have a look at the following:
https://gist.github.com/jedws/5993596#file-variancetest-java
it is only the one with a covariance annotation on the parameter that fails…
On 15 July 2013 12:52, Zhong Yu zhong.j...@gmail.com wrote:
Another example of
(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
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());
ignore me, you do actually need both ? extends on the type constructor and
the inner type – dunno what I was thinking.
On 15 July 2013 13:02, Jed Wesley-Smith j...@wesleysmith.io wrote:
I'm not entirely sure that is a problem, have a look at the following:
On 2013-07-15, at 9:02 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
The conclusion is: SR is a reasonable alternative with no obvious
performance show-stoppers. That said, TLR is also reasonably fast at
this point, and further improvements to TLR will probably beat the SR or
tie it
Hi Joe,
On Jul 15, 2013, at 1:11 PM, Joe Darcy wrote:
I was a little surprised to see the /li tags get added in resource bundle.
Why? They were missing although perhaps doclint did not complain about that, I
cannot recall. It is OK to leave them in, is it not?
Thanks,
Brian
Yes, it just happened! SQE team has agreed and we'll start to plan on
the migration!
-Joe
On 7/12/2013 4:57 PM, Iris Clark wrote:
FWIW, I really like the idea of migrating the jaxp tests to the jaxp repo.
I've always thought it odd that the code change and the test for it aren't in
the
I guess Alexey made the changes based on the existing implementation of
JVM_GetLastErrorString() in hotspot, which is os::lasterror(char* buf,
size_t len) in os_windows.cpp.
One comment about the code at line 105 in win32Error().
105 const int errnum = GetLastError();
Since in
On Jul 15, 2013, at 4:13 PM, Martin Buchholz marti...@google.com wrote:
I'll be your loyal adversary today, trying to break SplittableRandom.
Thanks so much! This is exactly the sort of skepticism we need.
Let's make it easier by providing a low-level constructor:
/** Testing */
On 07/15/13 16:13, Martin Buchholz wrote:
I'll be your loyal adversary today, trying to break SplittableRandom.
Let's make it easier by providing a low-level constructor:
/** Testing */
public SplittableRandom(long seed, long gamma, Error ) {
Now you see why we don't do
On 07/15/13 12:59, Martin Buchholz wrote:
If we make the wraparound point for seeds Long.MIN_VALUE instead of 0L, then we
can optimize addGammaModGeorge.
This was a great suggestion; thanks!
I continue to worry that we are producing a PRNG that will end up not being
acceptable to the Monte
On 07/15/13 19:06, Martin Buchholz wrote:
Another experiment that provides bit-full seed but poor gamma
Keeping in mind that we won't support the seed+gamma constructor,
For what value of K would you be content to know that
the generators associated with the first K splits for
any
On 07/15/13 09:02, Aleksey Shipilev wrote:
OK, early performance data follows.
...
- 64 bit: on moderately saturated machine (1, 16 threads), SR double is
marginally faster than TLR, and SR int/long is significantly faster than TLR
- 32 bit: TLR is vastly faster in int/long standalone
Changeset: 94e1a4b10811
Author:bpb
Date: 2013-07-15 14:37 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811
8020409: Clean up doclint problems in java.util package, part 1
Summary: Clean up doclint problems in java.util package, part 1
Reviewed-by: darcy
Changeset: 973d78ee0728
Author:attila
Date: 2013-07-15 12:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/973d78ee0728
8020324: Implement Object.bindProperties(target, source) for beans
Reviewed-by: hannesw, sundar
!
33 matches
Mail list logo
