On 05/05/2015 22:00, Mandy Chung wrote:
:
About the test selection, one typical aspect of svc tests is to run a
j* tool in a child process (e.g. jinfo, jstack, jstat, jstatd,jcmd,
jps etc that are in jdk.jcmd module). I would expect all
test/sun/tools/jcmd tests should have @modules
Hi,
Is there any interest to propose JEP 132 for JDK9 ?
I have some ideas how to achieve it's goals.
Regards, Peter
Ivan,
It looks like your change (I don't know whether it was intentional or not)
brings some more fail-fast-ness which is good! For instance, before the
change, this snippet:
ListInteger integers = new LinkedList();
integers.addAll(Arrays.asList(0, 1));
ListInteger sublist =
Thanks!
the comments in ValueBoxGen24 are somewhat cryptic to me at least
Yes, indeed... Roger mentioned that these may be some (outdated?) bug
tracker references, so I prefer not to touch them; just remove the angle
brackets to avoid warnings.
Regards,
Alexander
On 05.05.2015 21:25, Lance
On 6/05/2015 5:57 PM, Peter Levart wrote:
On 05/05/2015 03:25 AM, David Holmes wrote:
Hi Brent,
On 5/05/2015 2:11 AM, Brent Christian wrote:
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I would
like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
On 06/05/15 11:41, David Holmes wrote:
I don't think you want to de-synchronize the load* methods - you don't
want two threads calling load concurrently. But that then raises the
problem of concurrent modification while a load is in progress.
Synchronization ensures serialization and by removing
On May 5, 2015, at 7:39 PM, Martin Buchholz marti...@google.com wrote:
I'd prefer to go the other way, deleting those trivial methods entirely,
utilizing the rarely used .new syntax.
Very good, even better!
Paul.
On 05/05/2015 03:25 AM, David Holmes wrote:
Hi Brent,
On 5/05/2015 2:11 AM, Brent Christian wrote:
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I would
like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
On May 6, 2015, at 12:37 PM, Paul Sandoz paul.san...@oracle.com wrote:
On May 2, 2015, at 11:31 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi all,
today, I stubble on a variant of JDK-8050818 [1],
trying to call negate() on a lambda which is not yet a Predicate (due to
target typing)
On May 2, 2015, at 11:31 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi all,
today, I stubble on a variant of JDK-8050818 [1],
trying to call negate() on a lambda which is not yet a Predicate (due to
target typing) which requires either to cast the lambda to a Predicate and
everybody knows
Scala provides a filterNot method as a work around. This is a less generic fix,
but arguably more pragmatic for the common case of the streams API.
Sent from Yahoo Mail on Android
From:Attila Szegedi attila.szeg...@oracle.com
Date:Wed, May 6, 2015 at 4:59 am
Subject:Re: Add Predicate.of(),
Any official Reviewers with a couple of cycles to spare?
Thanks,
Peter Levart
On 04/27/2015 08:24 PM, Stephen Colebourne wrote:
This seems like a good enhancement.
Stephen
On 27 April 2015 at 16:26, Peter Levart peter.lev...@gmail.com wrote:
Hi,
Please review the following improvement
On May 6, 2015, at 1:58 PM, Attila Szegedi attila.szeg...@oracle.com wrote:
On May 6, 2015, at 12:37 PM, Paul Sandoz paul.san...@oracle.com wrote:
On May 2, 2015, at 11:31 PM, Remi Forax fo...@univ-mlv.fr wrote:
Hi all,
today, I stubble on a variant of JDK-8050818 [1],
trying to call
On 6 May 2015 at 14:53, Paul Sandoz paul.san...@oracle.com wrote:
In some respects i wonder if the default methods on the functional
interfaces are an attractive nuisance.
Meaning, if .negate(Predicate) were a static method on the Predicate class
instead of a default method, then
Hello everyone!
Here's the second iteration of the fix.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
I changed all the sub-list classes to be non internal, but standalone.
I think the logic become more obvious now.
Hi Peter,
Yes, looks good.
Roger
On 5/6/2015 8:21 AM, Peter Levart wrote:
Any official Reviewers with a couple of cycles to spare?
Thanks,
Peter Levart
On 04/27/2015 08:24 PM, Stephen Colebourne wrote:
This seems like a good enhancement.
Stephen
On 27 April 2015 at 16:26, Peter Levart
Hi Peter,
The logic looks good to me.
But I'm not an expert of the field, despite my small incursions :-)
I wish we didn't have to do defensive cloning - but I don't see
any way around.
best regards,
-- daniel
On 27/04/15 17:26, Peter Levart wrote:
Hi,
Please review the following
Hi Peter,
Thanks for the analysis and followup.
Yes, I think thesimple check as you propose is the desired clarification.
I agree that the change should not affect any existing code outside the JDK
and does not raise a compatibility issue.
Roger
On 5/4/2015 6:22 AM, Peter Levart wrote:
Hi,
On May 6, 2015, at 4:08 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Hello everyone!
Here's the second iteration of the fix.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
This is cleaner.
For extra bonus
Hi Pavel!
It was intentional to avoid checking for co-modification for every pair
of list-sublist in the chain.
It's surely enough to only compare modCount of the root and the sublist
we're dealing with.
However, I didn't notice that SubList.size() had not checked for
comodifications
Mandy,
Thanks fro your review! Please see my comment inlined.
On 05/05/2015 11:00 PM, Mandy Chung wrote:
com.sun.management has been moved to jdk.management module. The
patch for JDK-8042901 is just integrated in jdk9/dev today. Most, if
not all, test/com/sun/management tests need updates
Looks fine.
On 05/06/2015 03:19 PM, Joseph D. Darcy wrote:
PS Shortly after I pushed this fix I thought, it would have been better to add the
intermittent keyword to the test too. Please review this change to add the keyword:
diff -r a199b72a5b37 test/java/util/regex/RegExTest.java
---
Hi Ivan,
I'm afraid of these changes - they are hard to review.
Can't we fix the SOE with a relatively small change to ArrayList.SubList
methods that recursively invoke parent methods to use iteration instead,
i.e. can't you implement updateSizeAndModCount in the existing SubList
class?
---
I
PS Shortly after I pushed this fix I thought, it would have been better
to add the intermittent keyword to the test too. Please review this
change to add the keyword:
diff -r a199b72a5b37 test/java/util/regex/RegExTest.java
--- a/test/java/util/regex/RegExTest.javaWed May 06 21:15:07 2015
And here's another update:
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/2/webrev/
This is cleaner.
For extra bonus test points you could add singleton-list, checked wrappers, and
synchronized list wrappers to the test set.
Done.
I also added a simple implementation of AbstractList,
OK, we will merge slightly tidier ConcurrentSkip* sources during the Great
jsr166 jdk9 Merge.
On Wed, May 6, 2015 at 1:14 AM, Paul Sandoz paul.san...@oracle.com wrote:
On May 5, 2015, at 7:39 PM, Martin Buchholz marti...@google.com wrote:
I'd prefer to go the other way, deleting those trivial
On 05/06/2015 04:21 AM, Yekaterina Kantserova wrote:
The new webrev can be found here:
http://cr.openjdk.java.net/~ykantser/8078896/webrev.02/
Looks good.
About the test selection, one typical aspect of svc tests is to run a
j* tool in a child process (e.g. jinfo, jstack, jstat,
On 05/06/2015 04:11 PM, Roger Riggs wrote:
Hi Peter,
Yes, looks good.
Roger
On 05/06/2015 02:44 PM, Daniel Fuchs wrote:
Hi Peter,
The logic looks good to me.
But I'm not an expert of the field, despite my small incursions :-)
I wish we didn't have to do defensive cloning - but I don't
On 06/05/15 16:47, Paul Sandoz wrote:
n May 6, 2015, at 4:08 PM, Ivan Gerasimovivan.gerasi...@oracle.com wrote:
Hello everyone!
Here's the second iteration of the fix.
BUGURL:https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV:http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
I am also happy with this change.
Stephen
On 6 May 2015 at 15:43, Roger Riggs roger.ri...@oracle.com wrote:
Hi Peter,
Thanks for the analysis and followup.
Yes, I think thesimple check as you propose is the desired clarification.
I agree that the change should not affect any existing code
This is better (fixed a data race in Cleaner.clean()):
http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/Investigation/webrev.05/
Regards, Peter
On 05/06/2015 07:13 PM, Peter Levart wrote:
Hi,
I might have a closure for this long beard issue [1] and I'd like to
propose a
Cool!
Do we need any CCC approval as this *is* a spec change isn't it?
I haven't done such a thing yet, so please give me some pointers. I also
intend to add a jtreg test that verifies this new behavior.
Regards, Peter
On 05/06/2015 05:06 PM, Stephen Colebourne wrote:
I am also happy with
Hi Peter,
I'll run the CCC side, mostly it follows the similar rationale and
structure as the jira entry.
And the details are in your webrev.
Thanks, Roger
On 5/6/2015 11:43 AM, Peter Levart wrote:
Cool!
Do we need any CCC approval as this *is* a spec change isn't it?
I haven't done such
33 matches
Mail list logo
