On 01/16/2013 11:25 PM, Peter Levart wrote:
On 01/16/2013 05:58 PM, Joe Darcy wrote:
On 1/16/2013 8:32 AM, Florian Weimer wrote:
On 01/16/2013 05:27 PM, Brian Goetz wrote:
The primary purpose of this annotation is to *capture design
intent*. It is not required. The compiler will help you e
On 01/16/2013 05:09 PM, Brian Goetz wrote:
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.
so we agree,
like @
On 1/12/13 12:37 AM, Ulf Zibis wrote:
Am 11.01.2013 23:53, schrieb Christian Thalinger:
But you guys noticed that sentence in the initial review request, right?
"Move encoding loop into separate method for which VM will use
intrinsic on x86."
Just wanted to make sure ;-)
Good question Christ
On 1/16/2013 3:50 PM, Dean Long wrote:
Don't you need to change the split verifier as well?
Looks like the a corresponding change is already in
http://hg.openjdk.java.net/jdk8/tl/hotspot/diff/4735d2c84362/src/share/vm/classfile/verifier.cpp.
It bypasses verification of an overpass method (de
On 01/16/2013 05:58 PM, Joe Darcy wrote:
On 1/16/2013 8:32 AM, Florian Weimer wrote:
On 01/16/2013 05:27 PM, Brian Goetz wrote:
The primary purpose of this annotation is to *capture design
intent*. It is not required. The compiler will help you enforce
the design intent if you provide it.
Changeset: 8b749558767b
Author:darcy
Date: 2013-01-16 13:22 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b749558767b
8006283: Change to Class.cast() in javax.lang.model implementation for
repeating annotations
Reviewed-by: jjg
! src/share/classes/com/sun/tools/java
Changeset: cb40427f4714
Author:katleman
Date: 2013-01-03 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb40427f4714
Added tag jdk8-b71 for changeset 8171d23e914d
! .hgtags
Changeset: 191afde59e7b
Author:katleman
Date: 2013-01-10 09:55 -0800
URL: http
Changeset: 32a57e645e01
Author:katleman
Date: 2013-01-03 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32a57e645e01
Added tag jdk8-b71 for changeset 2a5af0f766d0
! .hgtags
Changeset: c9a914b11436
Author:katleman
Date: 2013-01-10 09:55 -0800
URL: http:/
Changeset: d9707230294d
Author:katleman
Date: 2013-01-03 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9707230294d
Added tag jdk8-b71 for changeset f577a39c9fb3
! .hgtags
Changeset: c606f644a5d9
Author:katleman
Date: 2013-01-10 09:55 -0800
URL: http
Changeset: 6f0986ed9b7e
Author:katleman
Date: 2013-01-03 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f0986ed9b7e
Added tag jdk8-b71 for changeset 467e4d9281bc
! .hgtags
Changeset: 45fed5cfd1c3
Author:katleman
Date: 2013-01-10 09:56 -0800
URL:
Changeset: bdf2af722a6b
Author:katleman
Date: 2013-01-03 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bdf2af722a6b
Added tag jdk8-b71 for changeset 499be952a291
! .hgtags
Changeset: 84946404d1e1
Author:katleman
Date: 2013-01-10 09:55 -0800
URL: http:
On Tue, Jan 15, 2013 at 5:33 PM, Martin Buchholz wrote:
> Actually, I think y'all should do 3 things:
> - backport Kumar's bug fix to jdk7
> - introduce a system property to turn off the zip64 support.
> I am working on a patch to introduce such a system property.
> We will probably default to dis
Hi Sherman,
As I was telling you, I had a very minor comment - the javadoc for the
enums DayOfWeek and Month shows the days/months in alphabetical order.
I am not sure if it is somehow possible to bypass that and show them in
the order of their occurrence instead.
Thanks,
- Kurchi
On 15.01.2
On 01/16/2013 04:08 AM, Alan Bateman wrote:
On 16/01/2013 00:13, Xueming Shen wrote:
Hi,
The Threeten project [1] is planned to be integrated into OpenJDK8 M6 milestone.
Here is the webrev
http://cr.openjdk.java.net/~sherman/8003680/webrev
and the latest javadoc
http://cr.openjdk.java.net/~sh
Changeset: f7f77bdf248b
Author:juh
Date: 2013-01-16 13:35 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7f77bdf248b
8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in
confusing way when some providers not present
Reviewed-by: mullan, weijun
! test/su
Please review the change at
http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/
Default interface methods are new in Java 8. VM creates overpass methods
in the vtable slots of classes to invoke a default method using
invokespecial.
Consequently, invocation of default interface methods (i.e
Changeset: 6b6311a8c9cc
Author:jjg
Date: 2013-01-16 10:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b6311a8c9cc
8006236: doclint: structural issue hidden
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EndTagsTest.ja
Changeset: 1afdf1f1472b
Author:mcimadamore
Date: 2013-01-16 17:40 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1afdf1f1472b
8005964: Regression: difference in error recovery after ambiguity causes JCK
test failure
Summary: Wrong implementation of ResolveError.access
On 01/16/2013 05:08 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 suppose
Changeset: f785dcac17b7
Author:mcimadamore
Date: 2013-01-16 16:27 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f785dcac17b7
8005854: Add support for array constructor references
Summary: Support constructor references of the kind int[]::new
Reviewed-by: jjg
! src/sha
On 1/16/2013 8:32 AM, Florian Weimer wrote:
On 01/16/2013 05:27 PM, Brian Goetz wrote:
The primary purpose of this annotation is to *capture design
intent*. It is not required. The compiler will help you enforce the
design intent if you provide it. The compiler will not synthesize
this ann
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
On 01/16/2013 05:27 PM, Brian Goetz wrote:
The primary purpose of this annotation is to *capture design intent*. It is
not required. The compiler will help you enforce the design intent if you
provide it. The compiler will not synthesize this annotation, since that would
be guessing at the
Yes it would.
The primary purpose of this annotation is to *capture design intent*. It is
not required. The compiler will help you enforce the design intent if you
provide it. The compiler will not synthesize this annotation, since that would
be guessing at the design intent. It is possib
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 Wei
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 01/16/20
On 1/16/2013 4:20 AM, Alan Bateman wrote:
On 16/01/2013 03:40, Martin Buchholz wrote:
:
It's a different story for the groups of users just now adopting jdk7.
The situation is a bit grim for those using jar files with>64k entries.
jdk7 is not only creating jar files that are unreadable by jdk6
Thanks to all for the reviews and suggestions here. As you probably
seen, I pushed these changes to jdk8/tl earlier today (sorry, I missed
Alan as an official reviewer on the changeset.). Consider it an initial
version, pending any outcome from this, or other, discussions.
Also, 8006409: "Thre
Changeset: c7d54f93d3e5
Author:juh
Date: 2013-01-16 09:51 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7d54f93d3e5
8005389: Backout fix for JDK-6500133
Reviewed-by: mullan
! src/share/classes/sun/security/x509/URIName.java
! test/sun/security/x509/URIName/Parse.java
Hi Roger,
and what's about my older bug reports? Do they have a Bug ID yet?
I did not receive any message.
Your report has been assigned an internal review ID of 2361929, which is NOT visible on the Sun
Developer Network (SDN).
The new one is:
Your report has been assigned an internal review
On 01/16/2013 12:48 PM, Doug Lea wrote:
On 01/16/13 03:59, Peter Levart wrote:
- Instead of Thread.threadLocalRandomSeed field it has a
Thread.threadLocalRandom reference field, pointing to an instance of
TLR.
- The ThreadLocalRandom is not a singleton, but an instance per
thread (like
JDK7'
On 16/01/2013 03:40, Martin Buchholz wrote:
:
It's a different story for the groups of users just now adopting jdk7.
The situation is a bit grim for those using jar files with>64k entries.
jdk7 is not only creating jar files that are unreadable by jdk6 - they
are also unreadable by the jdk7 laun
On 16/01/2013 00:13, Xueming Shen wrote:
Hi,
The Threeten project [1] is planned to be integrated into OpenJDK8 M6
milestone.
Here is the webrev
http://cr.openjdk.java.net/~sherman/8003680/webrev
and the latest javadoc
http://cr.openjdk.java.net/~sherman/8003680/javadoc
Review comments can
On 01/16/13 03:59, Peter Levart wrote:
- Instead of Thread.threadLocalRandomSeed field it has a
Thread.threadLocalRandom reference field, pointing to an instance of TLR.
- The ThreadLocalRandom is not a singleton, but an instance per thread (like
JDK7's).
Yes, this is the "Plan B" I mentioned
On 01/16/2013 01:23 PM, Peter Levart wrote:
> The test I used is simple:
> https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java
OK, you can't get serious with that test. The failures visible at the
surface are:
- dead-code
On 01/16/2013 10:51 AM, Florian Weimer wrote:
On 01/16/2013 07:54 AM, Joe Darcy wrote:
Hi Florian,
On 1/10/2013 1:23 AM, Florian Weimer wrote:
On 01/08/2013 10:24 PM, Joe Darcy wrote:
As discussed over on one of the Project Lambda lists [1], we're adding
an interface type to the platform to e
Changeset: 9d8ef6174cfd
Author:dl
Date: 2013-01-16 10:14 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d8ef6174cfd
8005926: Merge ThreadLocalRandom state into java.lang.Thread
Reviewed-by: shade, chegar
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/uti
On 01/16/2013 07:54 AM, Joe Darcy wrote:
Hi Florian,
On 1/10/2013 1:23 AM, Florian Weimer wrote:
On 01/08/2013 10:24 PM, Joe Darcy wrote:
As discussed over on one of the Project Lambda lists [1], we're adding
an interface type to the platform to explicitly mark interface types as
being functio
Hi Aleksey,
The test I used is simple:
https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java
I ran it on a i7-2600K (4 cores x 2 threads) PC with Linux OS and a JDK8
build from lambda repo using default JVM options (that m
Hi Peter,
This is an interesting experiment.
On 01/16/2013 12:59 PM, Peter Levart wrote:
> I did some micro benchmarks and here are the results:
>
> http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt
>
> Results indicate that usage pattern: Thread.current().nextInt() is as
> fast a
Hello,
I did an experiment with an alternative implementation of TLR:
http://dl.dropbox.com/u/101777488/TLR/webrev.01/index.html
This version is a modified proposed version. It has the following
differences:
- Instead of Thread.threadLocalRandomSeed field it has a
Thread.threadLocalRandom r
41 matches
Mail list logo
