On 06/19/2013 01:13 AM, Mike Duigou wrote:
On Jun 18 2013, at 05:19 , Doug Lea wrote:
On 06/17/13 19:30, Mike Duigou wrote:
I had to add the improved default for ConcurrentMap which was present in the
lambda repo in order to have correct behaviour. Since getOrDefault is already
in
On 06/19/2013 08:44 AM, Peter Levart wrote:
On 06/19/2013 01:13 AM, Mike Duigou wrote:
On Jun 18 2013, at 05:19 , Doug Lea wrote:
On 06/17/13 19:30, Mike Duigou wrote:
I had to add the improved default for ConcurrentMap which was
present in the lambda repo in order to have correct
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that
Hi,
On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
Hi Thomas,
Thanks for the detailed analysis.
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
The fix looks good. I was able to reproduce the failure with the
test case in the bug report running with jdk8 b94 fastdebug
Hi again,
some correction...
On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens
Hi,
one more note :)
On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote:
Hi again,
some correction...
On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas
On 6/19/13 11:00 AM, Daniel Fuchs wrote:
On 6/13/13 10:05 PM, Mandy Chung wrote:
Daniel,
I wonder what the list of logger names (loggers1 and loggers2) returned
by LoggingMXBean contains and that may include loggers in the running VM
other than the ones created and kept a strong reference by
On 6/13/13 10:05 PM, Mandy Chung wrote:
Daniel,
I wonder what the list of logger names (loggers1 and loggers2) returned
by LoggingMXBean contains and that may include loggers in the running VM
other than the ones created and kept a strong reference by the test. In
other words, would it be
On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
There is uncertainty around the issues that have come up as a result of
the follow two changesets, I would like to propose we anti-delta them:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04
http://hg.openjdk.java.net/jdk8/tl/langtools/rev/455be95bd1b5
This will afford the
On 19 June 2013 08:08, Peter Levart peter.lev...@gmail.com wrote:
I'd also like to suggest something. You have made lots of tests that cover
the functionality of new default methods in Map and other collections
interfaces which prove the correctness of behaviour when used with
implementations
Changeset: a76858faad59
Author:xuelei
Date: 2013-06-19 02:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a76858faad59
7188658: Add possibility to disable client initiated renegotiation
Reviewed-by: weijun, wetmore
! src/share/classes/sun/security/ssl/Handshaker.java
!
On Jun 19, 2013, at 8:44 AM, Peter Levart peter.lev...@gmail.com wrote:
On 06/19/2013 01:13 AM, Mike Duigou wrote:
On Jun 18 2013, at 05:19 , Doug Lea wrote:
On 06/17/13 19:30, Mike Duigou wrote:
I had to add the improved default for ConcurrentMap which was present in
the lambda repo
Hi Peter,
On Wed, 2013-06-19 at 11:05 +0200, Peter Levart wrote:
On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following
On 06/19/2013 11:45 AM, Paul Sandoz wrote:
On Jun 19, 2013, at 8:44 AM, Peter Levart peter.lev...@gmail.com wrote:
On 06/19/2013 01:13 AM, Mike Duigou wrote:
On Jun 18 2013, at 05:19 , Doug Lea wrote:
On 06/17/13 19:30, Mike Duigou wrote:
I had to add the improved default for
Changeset: 6d3b33aea370
Author:vromero
Date: 2013-06-19 11:09 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6d3b33aea370
8006981: javac, method toString() of class ...javac.code.Flags doesn't print
all the flag bits
Reviewed-by: jjg
!
On 19/06/2013 10:16, Chris Hegarty wrote:
There is uncertainty around the issues that have come up as a result
of the follow two changesets, I would like to propose we anti-delta them:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04
On 06/19/2013 11:45 AM, Paul Sandoz wrote:
On Jun 19, 2013, at 8:44 AM, Peter Levart peter.lev...@gmail.com wrote:
On 06/19/2013 01:13 AM, Mike Duigou wrote:
On Jun 18 2013, at 05:19 , Doug Lea wrote:
On 06/17/13 19:30, Mike Duigou wrote:
I had to add the improved default for
On 11/06/2013 14:23, Paul Sandoz wrote:
Hi,
Please review the following patch contributed by Brian Goetz:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
This syncs most of code in the pipeline implementations from lambda to tl (the
remaining aspects are to do with
On Jun 19, 2013, at 11:53 AM, Remi Forax fo...@univ-mlv.fr wrote:
This is another little oddity in Map.forEach:
try {
k = entry.getKey();
v = entry.getValue();
} catch(IllegalStateException ise) {
throw new
On 06/19/2013 11:45 AM, Paul Sandoz wrote:
Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to
use forEach. This trades off the entrySet iterator overhead for creation of a
capturing BiConsumer lambda.
But only in ConcurrentMap implementations that do override
Hi,
On Wed, 2013-06-19 at 09:25 +0200, Thomas Schatzl wrote:
Hi,
On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
Hi Thomas,
Thanks for the detailed analysis.
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
The fix looks good. I was able to reproduce the failure with
On 06/19/13 06:48, Peter Levart wrote:
On 06/19/2013 11:45 AM, Paul Sandoz wrote:
Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to
use forEach. This trades off the entrySet iterator overhead for creation of a
capturing BiConsumer lambda.
But only in ConcurrentMap
Hi Thomas,
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and somewhat
ill-defined, and also inadequate. I'm not convinced that adding code
inside a synchronized block really fixes a race condition caused by
Changeset: 22337da71eca
Author:chegar
Date: 2013-06-19 11:47 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22337da71eca
8017044: anti-delta fix for 8015402
Reviewed-by: alanb
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
!
On 06/18/2013 06:13 PM, Brian Burkhalter wrote:
This RFR was initially posted last month:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html
I hope that this is the final re-post. The issues in question are
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
On 19/06/2013 01:13, Brian Burkhalter wrote:
This RFR was initially posted last month:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html
I hope that this is the final re-post. The issues in question are
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
On 06/19/2013 04:05 PM, David Holmes wrote:
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and
somewhat ill-defined, and also inadequate. I'm not convinced that
adding code inside a synchronized block really fixes a
Hi,
On Wed, 2013-06-19 at 17:56 +0400, Aleksey Shipilev wrote:
On 06/19/2013 04:05 PM, David Holmes wrote:
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and
somewhat ill-defined, and also inadequate. I'm not
On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
With that notion in mind, I start to wonder if we just need to move the
check in enqueue() down into the synchronized(lock), and extend it to
capture NULL:
--- a/src/share/classes/java/lang/ref/ReferenceQueue.javaMon Jun 17
16:28:22 2013
Hi,
Since the bulk of changes to annotations and reflection have stabilized,
I'm bringing up a re-based batch that I have proposed some months ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html
The patch fixes a deadlock situation described in:
I think Tim is involved only in phases 3 and 4 of the BigInteger improvements
so we could remove him as author for now. His OCA status should however be
cleared up soon as I am hoping to move onto phase 3 before long.
Brian
On Jun 19, 2013, at 5:58 AM, Alan Bateman wrote:
One question on the
On 6/19/2013 8:58 PM, Alan Bateman wrote:
One question on the attribution (so that we have it right). In the
Contributed-by line then you have Alan Eliasen listed but the @author
tags have been extended to list Tim Buktu in addition to Alan. Is the
patch from both Alan and Tim? I ask because
I have updated this webrev per Martin's comments and removed Tim from the
@author list. If the latter is incorrect, please let me know.
Brian
On Jun 18, 2013, at 5:13 PM, Brian Burkhalter wrote:
the webrev as before is at
http://cr.openjdk.java.net/~bpb/4837946/
Hi,
Please find below a proposed fix for:
7184195 - java.util.logging.Logger.getGlobal().info()
doesn't log without configuration
Jim who was the original evaluator of this bug find out
that the root cause of the issue was that LogManager hadn't been
initialized yet, and therefore
I certainly have been curious as to how well our defaults work for the
non-OpenJDK collections implementations but unfortunately haven't had time to
pursue testing them yet. We plan to run a broader selection of software with
JDK8 as we progress to release and testing with Guava, Apache
Looks good.
Mike
On Jun 11 2013, at 06:23 , Paul Sandoz wrote:
Hi,
Please review the following patch contributed by Brian Goetz:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
This syncs most of code in the pipeline implementations from lambda to tl
(the
Looks fine.
On Jun 11 2013, at 03:12 , Paul Sandoz wrote:
Hi
Please review the following patch:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/
This syncs up java.util.stream.Node/Nodes from the lambda repo to the tl
repo. The main changes are related to reducing the
Looks fine. I would encourage you to test and push all four of these together.
Mike
On Jun 14 2013, at 05:40 , Paul Sandoz wrote:
Hi,
This patch implements optimizations for the limit/substream operations when
input to those operations have certain properties (corresponding to known
On 19/06/2013 16:14, Brian Burkhalter wrote:
I have updated this webrev per Martin's comments and removed Tim from the
@author list. If the latter is incorrect, please let me know.
Brian
Thanks, I think we are good now.
-Alan
Changeset: 9b802d99cb52
Author:bpb
Date: 2013-06-19 08:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b802d99cb52
4837946: Faster multiplication and exponentiation of large integers
4646474: BigInteger.pow() algorithm slow in 1.4.0
Summary: Implement Karatsuba and 3-way
Changeset: e7ece2dbdc70
Author:sla
Date: 2013-06-10 11:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7ece2dbdc70
8005008: Add Java Flight Recorder Phase II
Reviewed-by: erikj
Contributed-by: Karen Kinnear karen.kinn...@oracle.com, Bengt Rutisson
A ping to wake up the thread, there is a minor update regard the use of
@apiNote since last email.
Thanks in advance for reviewing.
Cheers,
Henry
On 06/15/2013 04:28 PM, Henry Jen wrote:
Reflecting feedbacks received so far, please see
Alan,
On Jun 19, 2013, at 5:27 AM, Alan Eliasen wrote:
Thanks for pushing this improvement. As I've said before, I'm more
than willing to put my personal e-mail address on this patch to support
the Karatsuba and Toom-Cook and pow() and radix conversion fixes. I'll
put my reputation on the
On 6/19/13 2:00 AM, Daniel Fuchs wrote:
On 6/13/13 10:05 PM, Mandy Chung wrote:
Daniel,
I wonder what the list of logger names (loggers1 and loggers2) returned
by LoggingMXBean contains and that may include loggers in the running VM
other than the ones created and kept a strong reference by
On 19/06/2013 15:23, Peter Levart wrote:
Hi,
Since the bulk of changes to annotations and reflection have
stabilized, I'm bringing up a re-based batch that I have proposed some
months ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html
:
This patch is
On 06/19/2013 08:54 PM, Alan Bateman wrote:
On 19/06/2013 15:23, Peter Levart wrote:
Hi,
Since the bulk of changes to annotations and reflection have
stabilized, I'm bringing up a re-based batch that I have proposed
some months ago:
Continuing on from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html
here is a new Request for Review, this time for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
The webrev is here
http://cr.openjdk.java.net/~bpb/4641897/
The code changes
Changeset: f6d72c4f6bf1
Author:dxu
Date: 2013-06-19 13:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6d72c4f6bf1
8016592: Clean-up Javac Overrides Warnings In
javax/management/NotificationBroadcasterSupport.java
Summary: Add hashCode() methods to ListenerInfo and
Changeset: de6b93fd6d23
Author:khazra
Date: 2013-06-19 14:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de6b93fd6d23
8016576: Overrides warnings in jdi and jconsole
Summary: Implement hashCode() in classes emitting warnings
Reviewed-by: alanb, chegar
!
Changeset: e1b18a666f76
Author:khazra
Date: 2013-06-19 14:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b18a666f76
8016698: Cleanup overrides warning in sun/tools/ClassDeclaration.java
Summary: Override Object.hashCode()
Reviewed-by: alanb, chegar
!
Changeset: be10ac0081b2
Author:vromero
Date: 2013-06-19 22:07 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be10ac0081b2
8016610: javac, add new internal symbols to make operator resolution faster
Reviewed-by: jjg
Contributed-by: maurizio.cimadam...@oracle.com
!
On 6/19/13 2:05 AM, Peter Levart wrote:
It doesn't make a difference between Reference.isEnqueued() and
ReferenceQueue.poll(), since there isn't any synchronization between
the two. So isEnqueued() can still be returning true while another
thread has already de-queued the instance. I guess
Hello all;
This is a fix to the Map.compute() default method and HashMap.compute()
implementation to correct the handling of keys mapped to null values when the
function returns null. This situation should result in the key being removed
but it was not.
Hi Mike,
On 20/06/2013 10:22 AM, Mike Duigou wrote:
Hello all;
This is a fix to the Map.compute() default method and HashMap.compute()
implementation to correct the handling of keys mapped to null values when the
function returns null. This situation should result in the key being removed
Thanks for the feedback.
On Jun 19 2013, at 21:51 , David Holmes wrote:
Hi Mike,
On 20/06/2013 10:22 AM, Mike Duigou wrote:
Hello all;
This is a fix to the Map.compute() default method and HashMap.compute()
implementation to correct the handling of keys mapped to null values when
the
56 matches
Mail list logo
