I guess your methods should return Box to be comparable to
Stream/Optional/CompletionStage cases.
On Mon, Jul 15, 2013 at 2:17 AM, Jed Wesley-Smith wrote:
> ignore me, you do actually need both ? extends on the type constructor and
> the inner type – dunno what I was thinking.
>
>
> On 15 July 20
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 resourc
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 b
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?
s
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
! src
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 U
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
AnnotationType.getInst
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 to
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/
AnnotationParser.java
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
> multipl
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
! src/shar
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:
>
> Collection {
> 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 changes
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), althou
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 think
I did supply a test that you can use to try it.
What we are talking about is whether type Box is substitutable by
Box in the contravariant position. Intuitively we think we only need
Box because we only care about the type parameter, but
the type – as you point out – is actually different. Box 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 wrote:
> Another example of possible missing a wildc
(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
comm
> 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() {
Optional some = some(new Parent());
Fu
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 wrote:
> I'm not entirely sure that is a problem, have a look at the following:
>
> https://gist.github.com/jedws/5993596#file-variancet
On 2013-07-15, at 9:02 AM, Aleksey Shipilev 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 on most scenarios.
I t
Reviewers:
Issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020409
Webrev http://cr.openjdk.java.net/~bpb/8020409/
Thanks,
Brian
On 07/15/2013 12:45 PM, Brian Burkhalter wrote:
Reviewers:
Issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020409
Webrev http://cr.openjdk.java.net/~bpb/8020409/
Thanks,
Brian
Hi Brian,
Looks fine, but I was a little surprised to see the "" tags get
added in resource bundle.
Hi Joe,
On Jul 15, 2013, at 1:11 PM, Joe Darcy wrote:
> I was a little surprised to see the "" 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 sam
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 os_laste
On Jul 15, 2013, at 4:13 PM, Martin Buchholz 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 */
>public Spli
On 07/15/2013 01:14 PM, Brian Burkhalter wrote:
Hi Joe,
On Jul 15, 2013, at 1:11 PM, Joe Darcy wrote:
I was a little surprised to see the "" 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
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 tha
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 C
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 SplittableRan
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 scenar
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
Contributed
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
! src/jdk/internal/dynalink/beans/AbstractJavaLinker.j
FileSystems static methods are inconsistent. I would expect that
"newFileSystem" methods will be same for URI and Path.
newFileSystem for Path is missing "env" parameter. So I can't create ZIP file
system from Path (with "create=true").
This was needed as workaround for Bug ID 7156873 (already
37 matches
Mail list logo
