Hello all;
This changeset fixes a small corner case where Arrays.parallelPrefix (all
variants) failed to throw NPE if the operation was null. If the array or range
was empty then op was never examined. The solution in this patch is to add an
an explicit Objects.requireNonNull(op) check.
http:/
Hello all;
When JDK-8006709 (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cff8d7768d72)
was pushed it changed the default source level for the jdk project NetBeans
projects to 1.8. This was a reasonable change since at this point there was
already a small amount of Java 8 "-source 1.8" code in
Changeset: d921ce805abe
Author:mduigou
Date: 2013-09-27 17:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d921ce805abe
8025610: Add explicit @throws NPE documentation to Optional constructor and
Optional.of
Reviewed-by: briangoetz, chegar, alanb
! src/share/classes/java/
Hello all;
As pointed out by Roger Riggs, Optional.of (and the private Optional(T)
constructor) don't explicitly document throwing NPE in response to a null value
despite describing value as "non-null". This changeset improves the
documentation to add an @throws NPE tag to the javadoc.
http://
Changeset: fbe6f5dbb24f
Author:mduigou
Date: 2013-09-27 13:30 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbe6f5dbb24f
8023339: Refined Collection.removeIf UOE conditions
Reviewed-by: mduigou
Contributed-by: paul.san...@oracle.com
! src/share/classes/java/util/Collection.
is not
> * supported
>
> ?
>
> Paul.
>
> On Sep 17, 2013, at 3:35 PM, Mike Duigou wrote:
>
>> Hello all;
>>
>> Another, hopefully final, attempt at refining the @throws UOE javadoc for
>> Collections.removeIf and the @throws UOE
Changeset: 4ed8565fa536
Author:mduigou
Date: 2013-09-27 11:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ed8565fa536
8024842: Define ABS_TEST_OUTPUT_DIR via TEST_OUTPUT_DIR
Reviewed-by: ihse, erikj, vromero
! test/Makefile
Changeset: 914f8d4570df
Author:mduigou
Date: 2013-09-27 10:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914f8d4570df
8025595: Remove alt-rt.jar, used by +AggressiveOps (jdk repo portion of
JDK-8024826)
Reviewed-by: alanb, chegar, dholmes, ksrini
! makefiles/CompileJava
Changeset: 8f27030686a6
Author:bchristi
Date: 2013-09-26 11:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f27030686a6
8025173: HashMap.put() replacing an existing key can trigger a resize()
Summary: Ensure that HashMap is not resized if we're just replacing a value
Revie
Hello all;
Another, hopefully final, attempt at refining the @throws UOE javadoc for
Collections.removeIf and the @throws UOE and NPE javadoc for List.replaceAll().
This cycle adopts the verbiage suggested by Paul Sandoz in the last round of
8023339.
Both changesets are combined into a single
The Map/Defaults.java changes only test HashMap. It should probably be extended
to test most/all of the other implementations.
I have some worry that the superfluous assignment of the
Objects.requireNonNull() result might have a non-negligible cost.
Mike
On Sep 17 2013, at 13:49 , Brian Burkh
both hotspot and jdk changes.
>>
>> Thumbs up and good riddance! :)
>>
>> How do you propose to handle the coordination of the push?
>>
>> Thanks,
>> David
>>
>> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>>> Hello all;
>>&
s platform test build along with the closed source portion. The
closed portion has to happen after the open jdk repo makefile changes.
Mike
>
> Thanks,
> David
>
> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>> Hello all;
>>
>> This is a cross-repo patch whi
Hello all;
This is a cross-repo patch which disables building and enabling of the
alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts
option (which will be remaining for other optimizations). This jar file
formerly contained (closed-source) versions of several JDK cl
Ping!
(still need a reviewer on this)
Mike
On Sep 4 2013, at 11:44 , Mike Duigou wrote:
> Hello all;
>
> I have updated the proposed changeset for this issue. I have moved the note
> to the interface documentation for Collection and Map and made it more
> general:
>
ved or if, in general, removal is
> not
> * supported.
>
> Paul.
>
> On Sep 13, 2013, at 11:52 PM, Mike Duigou wrote:
>
>> Hello all;
>>
>> A very small patch that refines the declared conditions under which the
>> Collection.removeIf
changes look fine.
Mike
On Sep 13 2013, at 17:22 , Henry Jen wrote:
> Hi,
>
> Please kindly review webrev at
> http://cr.openjdk.java.net/~henryjen/tl/8024825/0/webrev/
>
> This webrev is a typo fix + the cleanup made in lambda repo in following
> changeset.
> http://hg.openjdk.java.net/lambda/
Hello all;
A very small patch that refines the declared conditions under which the
Collection.removeIf() method will throw UOE. The intent of this patch is to
allow the default implementation to be used for immutable collections. It's
important that the default implementations provided and the
Based upon feedback we've decided to withdraw this change. It will remain
removeIf()
Mike
On Sep 4 2013, at 14:08 , Mike Duigou wrote:
> Hello all;
>
> The naming of the Collection.removeIf(Predicate) method has always been an
> uncertain choice. We've gone back and f
Changeset: 67f64101616e
Author:mduigou
Date: 2013-09-13 12:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/67f64101616e
8024201: Update bugdatabase url
Reviewed-by: wetmore
! make/scripts/webrev.ksh
Changeset: c65848f2b6a1
Author:mduigou
Date: 2013-09-13 11:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c65848f2b6a1
8021591: Additional explicit null checks
Reviewed-by: psandoz, alanb
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Hashtab
On Sep 13 2013, at 10:20 , Brent Christian wrote:
>> Done, new webrev is here:
>
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
>
>
> On 9/6/13 4:09 PM, Mike Duigou wrote:
>>
>> I am surprised that strdup isn't needed for the constant &quo
On Sep 11 2013, at 17:56 , Stephen Colebourne wrote:
> HijrahChronology mixes "final transient" and "transient final". They
> should be consistently one way or the other files should be checked,
> and I think there is an official coding standard for this).
The resource I have been quoted for th
Hi Brent;
Thanks for cleaning this up. The changes look fine.
(A simplifying change in Collections, how unexpected!)
Mike
On Sep 11 2013, at 17:13 , Brent Christian wrote:
> Please review my fix to remove the jdk.map.useRandomSeed system property
> added earlier in jdk8.
>
> Some history is
Tests look fine.
In the BiFunction test the unknown word "delieve" is used. I am not sure what
word was intended.
Mike
On Sep 10 2013, at 22:03 , Henry Jen wrote:
> Sorry I forgot it again. Copied but not pasted. :(
>
> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>
> Thanks fo
Responding to both of your messages at once.
On Sep 5 2013, at 21:49 , David Holmes wrote:
> Hi Mike,
>
> On 6/09/2013 2:58 AM, Mike Duigou wrote:
>> Hello all;
>>
>> A very small spec clarification for review. The spec clarification ensures
>> that the be
Looks like good changes all around. I didn't see any "breaking" changes.
Some of the javadoc examples ( blocks) are wrapped at 80 columns. I have
been allowing them to go wider (110 columns roughly) so that they don't end up
being very narrow in the HTML output.
Mike
On Sep 6 2013, at 23:18
The non-MacOS parts look fine to me. I can't comment on the Objective C or
MacOS code but the test you describe seems sufficient to confirm it is correct.
I am surprised that strdup isn't needed for the constant "?" string but
java_props_md.c seems to include other constant strings in sprops so
Hello all;
A very small spec clarification for review. The spec clarification ensures that
the behaviour of the default method can satisfy the needs of unmodifiable
implementations.
http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/
Thanks,
Mike
Hello all;
The naming of the Collection.removeIf(Predicate) method has always been an
uncertain choice. We've gone back and forth between naming it removeIf and
overloading the existing removeAll(Collection) with a removeAll(Predicate). Now
that all other library and language decisions seem to
ementations do not do so.
The webrev is at:
http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/
Mike
On Aug 27 2013, at 19:06 , Mike Duigou wrote:
> Hello all;
>
> Fairly frequently it is reported that various Collection/Map implementations
> of hashCode() fail when the i
On Sep 4 2013, at 04:00 , Alan Bateman wrote:
> On 04/09/2013 00:23, Mike Duigou wrote:
>> Hello all;
>>
>> Here is an updated webrev of just 8024014:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/
>>
>> The controversial item
e the list of files is quite static and would not have
changed since Java 6 (except for jdk_stream) I think we should be able to
tolerate the not-too-long list of files for the jdk_collections category.
Other opinions?
Mike
On Aug 29 2013, at 17:13 , Mike Duigou wrote:
> Hello all;
>
Changeset: 6d7f27953da6
Author:mduigou
Date: 2013-09-03 15:23 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/6d7f27953da6
8024200: handle hg wrapper with space after #!
Reviewed-by: tbell
! common/bin/hgforest.sh
On Sep 3 2013, at 02:03 , Paul Sandoz wrote:
>
> On Aug 28, 2013, at 12:56 AM, Mike Duigou wrote:
>
>> Hello all;
>>
>> Here's an updated version of the patch which incorporates feedback and
>> improves the tests (the reason for delay):
>>
>&g
Looks fine.
On Sep 3 2013, at 11:38 , Henry Jen wrote:
> Hi,
>
> Please review a simple webrev at
>
> http://cr.openjdk.java.net/~henryjen/tl/8024178/0/webrev/
>
> The reverted change was included as part of JDK-8015318 fix at late
> stage, after more thoughts, it is not needed.
>
> As a coll
FYI, I have pushed 8024015 but not 8024014.
I will have an updated (cleaner) patch for 8024014 shortly.
Mike
On Aug 29 2013, at 17:13 , Mike Duigou wrote:
> Hello all;
>
> This is a review for two changesets. The first change (JDK-8024014) splits up
> the jdk_util test gr
Changeset: 4bdbe25b1e04
Author:mduigou
Date: 2013-09-03 11:29 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbe25b1e04
8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang
Reviewed-by: alanb, mchung
! test/TEST.groups
Looks fine to me as well.
Mike
On Sep 3 2013, at 09:33 , Paul Sandoz wrote:
> Hi,
>
> Due to recent compiler changes a test is failing to compile.
>
> The fix is already in lambda and needs to be pushed to tl:
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389
>
> Paul.
>
the JDK to
> finally provide this itself. Everyone has encountered situations where
> joining strings is required, and it is a Good Thing™ that we can now express
> that through a standard API that every Java developer (eventually) will know.
> "
>
>
> On 2013-
On Aug 29 2013, at 22:37 , Alan Bateman wrote:
> On 30/08/2013 01:13, Mike Duigou wrote:
>> Hello all;
>>
>> This is a review for two changesets. The first change (JDK-8024014) splits
>> up the jdk_util test group a bit by introducing three sub-groups,
>>
On Aug 29 2013, at 18:37 , David Holmes wrote:
> On 30/08/2013 11:21 AM, Mandy Chung wrote:
>> On 8/29/2013 5:13 PM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This is a review for two changesets. The first change (JDK-8024014)
>>> splits up the j
Hello all;
This is a review for two changesets. The first change (JDK-8024014) splits up
the jdk_util test group a bit by introducing three sub-groups, jdk_collections,
jdk_stream and jdk_concurrent. The main advantage is that it's easier/quicker
to test individual components. The intent is tha
Changeset: 51a61778a99d
Author:mduigou
Date: 2013-08-29 16:04 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/51a61778a99d
8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to
put output.
Reviewed-by: erikj, vromero, henryjen
! test/Makefile
On Aug 28 2013, at 15:54 , Alan Eliasen wrote:
> On 08/28/2013 04:47 PM, Guy Steele wrote:
>> *ahem* Y'know, Common Lisp had a good solution for
>> printing self-referential structures (by a user-extensible print
>> function) back in 1984.
>>
>> It leaned on the solution that had been provided
collections.
> Or really, any recursive ("deep") algorithm.
A class level note then for specific classes? A general warning on the
interfaces regarding self-referential being optional?
Mike
> And the typical failure mode is inflooping or stack overflow.
>
>
>
n of hashCode may fail with an
> exception. Implementations may optionally try to handle this scenario,
> however most current implementations do not do so.
>
> Stephen
>
> On 28 August 2013 03:06, Mike Duigou wrote:
>> Hello all;
>>
>> Fairly frequently it is re
Hello all;
Fairly frequently it is reported that various Collection/Map implementations of
hashCode() fail when the instance directly or indirectly contains itself. For a
variety of reasons, mostly performance and resource related, most
implementations choose not to support calculation of hash
e promoted builds. This changeset will not be
integrated until after the next JTReg promotion.
Mike
On Aug 7 2013, at 14:44 , Mike Duigou wrote:
> Hello all;
>
> This changesest simplifies how the the jdk/test/Makefile processes excluded
> tests. Previously the test exclusions
then it would have been more prudent to amend the interface spec to
remove the NPE notice.
A few other inconsistencies around null handling were also resolved. Some unit
tests issues were also cleaned up.
Mike
On Jul 26 2013, at 16:31 , Mike Duigou wrote:
> Hello all;
>
> This p
Looks good.
Random::
- Seems fine.
ThreadLocalRandom::
- I don't understand the point of having a writeObject() if the readResolve()
ignores the result. My expectation for a serialized TLR might be that upon
de-serialization the seeding state is restored. If that isn't provided, why
offer a
Looks good.
On Aug 21 2013, at 16:19 , Henry Jen wrote:
> On 08/20/2013 02:21 AM, Paul Sandoz wrote:
>> [resending unsigned, sorry if a dup arrives later on]
>>
>> On Aug 19, 2013, at 9:18 PM, Henry Jen wrote:
>>
>>> Hi,
>>>
>>> Please review the webrev at
>>> http://cr.openjdk.java.net/~hen
On Aug 26 2013, at 18:37 , Mike Duigou wrote:
>
> On Aug 19 2013, at 15:35 , Martin Buchholz wrote:
>
>> My feeling is that the JDK specs have been creeping in the direction of
>> excessive pedantry and doc lawyerism. I think it's overall a benefit of
>> Jav
> A vote from me for maintaining the already high level of pedantry we have,
> but not raising it any further.
I always imagine it's more like limbo. ;-)
Mike
>
>
>
> On Mon, Aug 19, 2013 at 3:15 PM, Mike Duigou wrote:
>
> On Aug 1 2013, at 08:57 , Alan Batema
With most recent changes, +1.
Mike
On Aug 19 2013, at 04:06 , Paul Sandoz wrote:
> Hi,
>
> This is the patch for SplittableRandom:
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
>
> The algorithm remains the same as reported by Doug on the 9th August:
>
> h
Changeset: f643fee2b40f
Author:mduigou
Date: 2013-08-26 10:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f
8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj
! common/makefiles/Main.gmk
! test/Makefile
I will need to spend more time reviewing the HashMap/LinkedHashMap
implementations but here are some initial comments.
Mike
HashMap::
- The "Sorry if you don't like..." comment can be omitted.
SpliteratorCharacteristics::
- style comment : I always define my assertXXX in the (value, expected
On Aug 23 2013, at 17:10 , Brian Burkhalter wrote:
>
> On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote:
>
>> I would strongly recommend holding back on this change until someone
>> familiar with the crypto implications takes a look at it. Unfortunately
>> neither
I would strongly recommend holding back on this change until someone familiar
with the crypto implications takes a look at it. Unfortunately neither the
random constructor nor probablePrime indicate any expectations regarding the
quality of random numbers needed from the offered PRNG.
- Changin
Looks like the same text as agreed on the Lambda EG list. So, +1
Mike
On Aug 23 2013, at 14:35 , Henry Jen wrote:
> Hi,
>
> Please review the javadoc spec change for AutoCloseable.
>
> Basically, it clarifies that AutoCloseable is to be automatically closed
> with try-with-resource construct,
I considered that as well but since the types are generics you'd have to cast
anyway.
The only viable declaration is:
private static Function CASTING_IDENTITY = i -> i;
On usage you'd have to add (Function) CASTING_IDENTITY
(Which assumes the compiler would even accept this heinous cast, I hav
Nice cleanups. Looks good!
Mike
On Aug 23 2013, at 12:17 , Henry Jen wrote:
> Hi,
>
> Please kindly review the fix for eliminate some warnings in
> java.util.stream package.
>
> Chained Sink is an internal implementation detail, add the type for
> downstream is more precise but verbose.
>
> I
Looks OK to me.
Mike
On Aug 22 2013, at 20:21 , Henry Jen wrote:
> Hi,
>
> Please review a relative simple webrev[1] that basically simply renaming
> Comparator methods. The reason behind the renaming can be found at this
> email thread[2]. The specdiff is also available here[3].
>
> Cheers,
>
On Aug 21 2013, at 17:01 , David M. Lloyd wrote:
> On 8/21/13 5:37 PM, Brian Burkhalter wrote:
>> With respect to this issue
>>
>> http://bugs.sun.com/view_bug.do?bug_id=6470700
>>
>> the code of concern from java.lang.Math is
>>
>> 701private static Random randomNumberGenerator;
>> 702
>>
Changeset: fad3b6673159
Author:mduigou
Date: 2013-08-21 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad3b6673159
8023306: Add replace() implementations to TreeMap
Reviewed-by: psandoz, alanb, chegar, bpb
! src/share/classes/java/util/TreeMap.java
Changeset: 91a31c7
On 08/20/2013 11:07 AM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This is a proposal to deprecate (Any votes for outright removal?)
>>
>> Yes; take them out!
>
> Me too! Just take 'em out. Unlike some other sun.misc APIs :-/ there are
> already suitable public alternatives for these.
>
> s'marks
>
Changeset: c8da1b6a9762
Author:mduigou
Date: 2013-08-20 17:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762
8023433: Improve 'make help'
Reviewed-by: tbell
! NewMakefile.gmk
On Aug 20 2013, at 05:13 , Alan Bateman wrote:
>
> For some time now we have been chipping away at the make files that are used
> to run the jdk tests. Mike has his wielded his axe on several occasions
> recently to remove logic and rules that are no longer needed.
I've started to sharpen my
On Aug 20 2013, at 04:57 , Paul Sandoz wrote:
> [resending unsigned, sorry if a dup arrives later on]
>
> On Aug 19, 2013, at 9:04 PM, Mike Duigou wrote:
>
>> Looks pretty good. Two points concern me:
>>
>> - Every source of non-crypto quality randoms should e
Paul Sandoz pointed out (again) that I let synchronized slip back into the
split out patch.
http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/
Corrects this error.
Mike
On Aug 20 2013, at 11:11 , Mike Duigou wrote:
> Hello all;
>
> This is a small changeset I have split out
Hello all;
This is a small changeset I have split out from the mostly unrelated
JDK-8021591. This changeset adds Map.replace(key,value) and
Map.replace(key,oldValue,newValue) implementations to TreeMap that are more
efficient that that provided by the defaults in Map.
webrev: http://cr.openjdk
Hello all;
This is a proposal to deprecate (Any votes for outright removal?) two classes
in the private sun.misc package. These are ancient vestigial classes who's
usage has long been eliminated in the JDK in favour of
java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int
s
Looks very good!
On Aug 20 2013, at 05:13 , Alan Bateman wrote:
>
> For some time now we have been chipping away at the make files that are used
> to run the jdk tests. Mike has his wielded his axe on several occasions
> recently to remove logic and rules that are no longer needed. One of the
Looks OK to me.
On Aug 20 2013, at 08:39 , Paul Sandoz wrote:
> Hi,
>
> Please see below for a simple fix to stop throwing an NPE on
> Collections.emptyList().sort(null);
>
> Paul.
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
>
> diff -r 3647aab7b1d5 src/share/classes/ja
On Aug 1 2013, at 08:57 , Alan Bateman wrote:
> On 26/07/2013 16:31, Mike Duigou wrote:
>> Hello all;
>>
>> This patch adds some missing checks for null that, according to interface
>> contract, should be throwing NPE. It also improves the existing tests t
On Aug 19 2013, at 13:12 , Guy Steele wrote:
>
> On Aug 19, 2013, at 3:17 PM, Mike Duigou wrote:
>
>> - I find disallowing the zero bounds and empty ranges slightly annoying. It
>> requires me to externally special case for situations such as:
>>
>> Ran
- @SuppressWarnings("unchecked") would appear to be in some of the cases.
- Replace:
@summary Unit tests for wrapping classes should delegate to default methods
with
@summary Ensure Collections wrapping classes provide non-default implementations
- ArrayList list -> List list
- TestNG DataPro
- documentation of "bound" should mention that it is exclusive rather than
relying on the return documentation.
- I find disallowing the zero bounds and empty ranges slightly annoying. It
requires me to externally special case for situations such as:
Random ran = new Random();
String[] users =
Looks pretty good. Two points concern me:
- Every source of non-crypto quality randoms should explicitly document that it
should not be used for generating keys or other crypto purposes. There is
mention that the seeding is insecure in the implementation docs but more
explicit mention in the pu
Looks correct.
mike
On Aug 14 2013, at 15:08 , Chris Hegarty wrote:
> Typo that crept in during a refactoring.
>
> http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011695.html
>
> This change is already in the jsr166 CVS.
>
> diff --git a/src/share/classes/java/util/concurrent/
Looks fine.
Mike
On Aug 14 2013, at 14:59 , Chris Hegarty wrote:
> Source changes that follow Doug's mail on lambda-libs-spec-observers
>
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html
>
> These changes are already in the jsr166 CVS, and there is a
Changeset: 17dfbb3f60d3
Author:bpb
Date: 2013-08-12 10:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dfbb3f60d3
8022109: Evaluate adding incrementExact, decrementExact, negateExact to
java.lang.Math
Summary: Add the methods for parameter types int and long.
Reviewed-by
Looks good to me.
Mike
On Aug 12 2013, at 20:26 , Henry Jen wrote:
> Hi,
>
> Please review the webrev[1] adds an API to help compose a Collector with
> an additional "finish" function.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8019401/0/webrev/
>
Looks fine to me.
On Aug 12 2013, at 11:25 , Alan Bateman wrote:
> On 12/08/2013 16:24, Paul Sandoz wrote:
>> Hi,
>>
>> Here is another go at characteristics reported for spliterators of empty
>> collections:
>>
>> diff -r f8d92ce66886 src/share/classes/java/util/Collection.java
>> --- a/src/s
Hi Doug;
Several minor recent cleanups and proposed cleanups in HashMap made me wonder
how things are progressing on this work. Do you feel it's nearly ready to
integrate into the jdk8 repos? What additional work remains? Are you tracking
changes going in to the jdk8 repos?
Mike
On Jul 8 2013
Looks good to me. I am glad we were able to get this back into Java 8.
Mike
On Aug 9 2013, at 17:39 , Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue http://bugs.sun.com/view_bug.do?bug_id=8022109
> Webrevhttp://cr.openjdk.java.net/~bpb/8022109/
>
> The update is
Looks good to me. Nice cleanup Mani and thank you for sponsoring the change
Henry!
Mike
On Aug 9 2013, at 17:25 , Henry Jen wrote:
> Hi,
>
> Please review a webrev contributed by Mani Sarkar that converts junit
> tests in test/java/lang/invoke to testng.
>
> http://cr.openjdk.java.net/~henryj
On Aug 9 2013, at 06:04 , Paul Sandoz wrote:
> Hi Peter,
>
> On Aug 8, 2013, at 12:44 PM, Peter Levart wrote:
>
>> Hi Paul,
>>
>> Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and
>> ORDERED? Like Collections.singletonSpliterator...
>>
>
> Perhaps, for consistency. II
Fine from me as well.
On Aug 9 2013, at 09:51 , Joe Darcy wrote:
> Agreed; looks good.
>
> Thanks,
>
> -Joe
>
> On 8/9/2013 8:27 AM, Lance Andersen - Oracle wrote:
>> looks fine chris
>>
>> Best
>> Lance
>> On Aug 9, 2013, at 11:03 AM, Chris Hegarty wrote:
>>
>>> These changes address the re
On 2013-08-08, at 9:22, Jonathan Gibbons wrote:
> On 08/08/2013 09:13 AM, Chris Hegarty wrote:
>>
>> So we need a b07 of jtreg before we can proceed with this?
>>
>> -Chris.
>
> General question to all:
>
> How much will fall over if we call it 4.2?
Some of the build scripts and makefies us
On 2013-08-07, at 18:22, Alan Bateman wrote:
> On 07/08/2013 14:44, Mike Duigou wrote:
>> Hello all;
>>
>> This changesest simplifies how the the jdk/test/Makefile processes excluded
>> tests. Previously the test exclusions were pre-processed by scripts in th
Hello all;
This changesest simplifies how the the jdk/test/Makefile processes excluded
tests. Previously the test exclusions were pre-processed by scripts in the
Makefile before being passed to JTReg. JTReg will now the all the processing.
The change depends upon improvements in JTReg since the
Why not have Class[] on the left side as well?
Mike
On Aug 7 2013, at 10:49 , Dan Xu wrote:
> Hi All,
>
> Please review the simple warning fix in
> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java.
>
> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/
>
> Thanks,
>
> -Dan
Changeset: e117fcdd2176
Author:mduigou
Date: 2013-08-06 18:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e117fcdd2176
8022476: cleanup some raw types and unchecked warnings in java.util.stream
Reviewed-by: darcy
Contributed-by: mike.dui...@oracle.com, henry@oracle.com
Hello all;
A changeset of primarily warning suppression in java.util.stream that reduces
the warnings on some of the stream pipeline and ops classes.
http://cr.openjdk.java.net/~mduigou/JDK-8022476/0/webrev/
Mike
Looks fine (reviewed patch file rather than webrev)
Mike
On Aug 6 2013, at 14:08 , Stuart Marks wrote:
> Please review the following change to suppress a bunch of deprecation
> warnings from the sun.rmi package.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022440
> (not yet p
Looks OK. A few minor non-blocking comments:
DelegatingStream::
- I wonder if an extends wildcard might also be included on R
ReduceOps::
- It is not clear in makeRef why collector.accumulator() wouldn't also benefit
from a Objects.requireNonNull
General::
- Is there a constant immutable Enu
On Aug 1 2013, at 16:05 , David Holmes wrote:
> On 2/08/2013 1:57 AM, Alan Bateman wrote:
>> On 26/07/2013 16:31, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This patch adds some missing checks for null that, according to
>>> interface contract,
On Aug 1 2013, at 10:38 , Nick Williams wrote:
> That was the ticket! All the tests run with this command, despite the fact
> that some of them fail. Thanks!
>
> You might want to update the readme with this command, at least as an
> alternative to the one there now.
>
> Nick
>
> On Jul 31,
Looks good to me. Thanks for incorporating the 6546713 changes.
Can we also incorporate the changes in JDK-7178639:
http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
into this changeset? It seems like an an opportune time.
Mike
On Aug 1 2013, at 03:34 , Chris Hegarty wrote:
> These ch
201 - 300 of 908 matches
Mail list logo
