Hi all,
Would you please help to review the test development of
https://bugs.openjdk.java.net/browse/JDK-8144321.
webrev : http://cr.openjdk.java.net/~mli/8144321/webrev.00/
Thank you
-Hamlin
I'd like agree with Goetz's opinion, Collectors like in Clojure 1.7
Transducers. Java 8 have some transducers, such as Comparator.comparing,
java.util.stream.Collectors.mapping、reducing、groupingBy、partitioningBy、summing
、Collectors.flatMapping(in Java 9) etc.
I think a Java 8 Collector is a "red
Hello!
Sounds reasonable. I already have such collector in my library [1].
As an alternative solution for your problem I have groupingBy
collector with domain parameter [2], so you can specify the set of
possible keys and all keys are guaranteed to be created:
Set getAllDepartmentsSet() {...}
M
> On Dec 4, 2015, at 8:56 AM, Roger Riggs wrote:
>
>
> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
67 * Unless otherwise noted, passing a {@code null} argument to a
constructor or
68 * method in any class
On 12/4/15 12:39 PM, Roger Riggs wrote:
Hi Stuart,
List.java:
- The varargs form would be more readable if the parameter was named
'elements' instead of 'es'.
- ditto Map and Set
Renamed.
Map.java:
- in the @returns I would say returns "a {@code Map}" to be explicit about the
retur
On 12/4/2015 3:35 PM, Aleksej Efimov wrote:
Hi Joe, Sean,
Thank you for the reviews and comments.
Joe,
Thank you for the suggestion. I added small test changes to address
your proposal. New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8133924/8/01/
Ok, that works.
Best,
Jo
> On Dec 4, 2015, at 5:47 AM, Paul Sandoz wrote:
>
>>
>> On 3 Dec 2015, at 22:33, Mandy Chung wrote:
>>
>>
>>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote:
>>>
>>> Hi,
>>>
>>> I have updated the patches:
>>>
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-j
Hi Joe, Sean,
Thank you for the reviews and comments.
Joe,
Thank you for the suggestion. I added small test changes to address your
proposal. New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8133924/8/01/
Best Regards,
Aleksej
On 12/05/2015 02:18 AM, huizhe wang wrote:
Hi A
Hi Aleksej,
First of all, I'm not a reviewer for 8u.
The test is fine in proving that no NPE is thrown, which indicates the
2nd nodeset is not null. However, there's a 2nd aspect of this: it
should be empty. I suggest improving the test so that it further proves
that it's not only "not null"
On 12/4/15 1:50 AM, Stephen Colebourne wrote:
Sorry for my delayed review. Basically, I'm happy with this.
Great!
Map.ofEntries(Entry...)
"The entry objects themselves are not stored in the map."
This seems wrong. `Entry` might be implemented as a value, not an
object in the future. And if
Uh, you did mention you need entry with value zero. I knew I miss something. :)
Cheers,
Henry
> On Dec 4, 2015, at 12:53 PM, ShinyaYoshida wrote:
>
> Thank you for your comment.
>
> 2015-12-05 3:28 GMT+09:00 Henry Jen :
> My first thought is what’s wrong with
>
> stream.filter(predicate).col
Hi Stuart
small question: I find it a bit odd that EnumSet has max 5 parameters,
while Set has more than that.
Also, would it be possible, maybe to add overloads to Set that
specifically works on Enum constants?
> of(Z z1, Z z2) { ... }
This would give you a way to call Set.of and get diffe
Hi Peter,
On 12/04/2015 04:31 PM, Peter Levart wrote:
...
Would writing something like the following make sense: "A future
implementation may use more than one thread. The ThreadFactory
should not assume that only one thread will be requested." ?
I'm not sure it adds anything to talk ab
.. are not necessarily stored in the Map ...
On 12/4/2015 4:50 AM, Stephen Colebourne wrote:
Sorry for my delayed review. Basically, I'm happy with this. Some oddments:
Map.ofEntries(Entry...)
"The entry objects themselves are not stored in the map."
This seems wrong. `Entry` might be impleme
This seems reasonable; mapping() already exists for use in this space
(as a combinator for the downstream collector of groupingBy and
friends), filtering() is also reasonable in this context.
On 12/4/2015 3:53 PM, ShinyaYoshida wrote:
Thank you for your comment.
2015-12-05 3:28 GMT+09:00 Henr
> On Dec 4, 2015, at 10:07 AM, Kim Barrett wrote:
>
> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote:
>>
>>> [Indeed, this whole section isn't strictly necessary; all of it can be
>>> inferred from information in other places.]
>>
>> Agree. This section is no longer necessary and maybe just r
I still need an official OpenJDK Reviewer.
+1
Thanks.
This is purely a suggestion, take it or leave it: you could use a static import
for Objects.requireNonNull, that makes the current code marginally easier on
the eyes (i know this area is likely to change).
Will consider for future co
Hi Patrick,
Please see my response to a similar query from Peter Levart:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036909.html
Briefly, this is something we should consider as a future extension. The current
workaround is to load values into an array and then call the
On 12/04/2015 10:04 PM, Roger Riggs wrote:
Hi Peter,
On 12/04/2015 03:30 PM, Peter Levart wrote:
Just a nit more, Roger:
131 *
132 * The cleaner terminates when it is unreachable and all of the
133 * registered cleaning functions are complete.
(and also in the javadoc of
Hi Peter,
On 12/04/2015 03:30 PM, Peter Levart wrote:
Just a nit more, Roger:
131 *
132 * The cleaner terminates when it is unreachable and all of the
133 * registered cleaning functions are complete.
(and also in the javadoc of the other create() method)
The cleaner is an
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8144677
http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
Tested with JPRT with:
• "-testset hotspot"
• "-testset svc"
• "-testset chris" from the example custom testset provided in the CR.
• no t
Thank you for your comment.
2015-12-05 3:28 GMT+09:00 Henry Jen :
> My first thought is what’s wrong with
>
> stream.filter(predicate).collect(...)?
>
> In your case, that would be,
>
> amps.stream().filter(e -> e.getSalary() > 2000)
> .collect(groupingBy(Employee::getDepartment), Collectors.coun
Hi Stuart,
List.java:
- The varargs form would be more readable if the parameter was named
'elements' instead of 'es'.
- ditto Map and Set
Map.java:
- in the @returns I would say returns "a {@code Map}" to be explicit
about the return type.
(ditto in Set and List to reinforce the ret
Just a nit more, Roger:
131 *
132 * The cleaner terminates when it is unreachable and all of the
133 * registered cleaning functions are complete.
(and also in the javadoc of the other create() method)
The cleaner is an object. What terminates is a thread. So what about:
"Th
Looks fine Sherman; thanks,
-Joe
On 12/4/2015 11:41 AM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8143854
Issue: https://bugs.openjdk.java.net/browse/JDK-8143854
webrev: http://cr.openjdk.java.net/~sherman/8143854
This is triggered by the same cause of bug JDK-8079419. H
Hi,
Please help review the change for JDK-8143854
Issue: https://bugs.openjdk.java.net/browse/JDK-8143854
webrev: http://cr.openjdk.java.net/~sherman/8143854
This is triggered by the same cause of bug JDK-8079419. However
the fix for 8079419 missed the possibility that the last character
of th
On Dec 4, 2015, at 1:16 PM, Kim Barrett wrote:
>
> I'd rather not clutter and uglify this and other tests to deal with a
> problem we don't (so far as I can tell) presently actually have. If a
> problem does arise, the form of that problem will help guide what the
> solution needs to be. I susp
Looks OK. Sorry for the continuing troubles, but this test has
survived many iterations on Google machines without failure. Failures
are more likely to be collector-specific than random-number-specific.
If you can repro, you can try varying hotspot GC flags.
On Fri, Dec 4, 2015 at 10:31 AM, joe
Hi Joe,
Looks fine, Roger
On 12/04/2015 01:31 PM, joe darcy wrote:
Hello,
Please review the patch below to address
JDK-8144742: Instrument intermittently failing test
GCDuringIteration.java
In brief, after GCDuringIteration.java was un-@ignored recently, it
has been seen to fail int
Hello,
Please review the patch below to address
JDK-8144742: Instrument intermittently failing test
GCDuringIteration.java
In brief, after GCDuringIteration.java was un-@ignored recently, it has
been seen to fail intermittently in some of our testing. As the test
uses randomness, to hel
My first thought is what’s wrong with
stream.filter(predicate).collect(...)?
In your case, that would be,
amps.stream().filter(e -> e.getSalary() > 2000)
.collect(groupingBy(Employee::getDepartment), Collectors.counting())
That should work just fine?
Cheers,
Henry
> On Dec 3, 2015, at 10:57
Hi Alberto,
It might be easier to discuss these proposals by separating them into
individual emails, to help keep things focussed. I'm not even sure if this
is the right list for Java language discussions.
I'm not an expert but just sharing some quick thoughts...
On Fri, Dec 4, 2015 at 10:22 AM
On Dec 4, 2015, at 2:16 AM, Per Liden wrote:
>
> On 2015-12-02 19:37, Kim Barrett wrote:
>> Please review this change to PhantomReference processing, changing the
>> GC-based notification to automatically clear the referent.
>>
>> […]
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8071507
>>
Hi,
I'm Alberto, a Java EE developer from Spain. I would like to suggest
several improvements to the Java language and API. These are my suggestions:
*1) Variable declaration block*
I don't know why, but you can declare variables in a for declaration,
but not in an if declaration. I would ad
While we are painting the bikeshed, what about `powerNap()`
On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich wrote:
> Minor quibble, but why the "on" prefix in the name? Maybe just me, but
> onXYX is typically used for event notification style APIs.
>
> Also, the "wait" part seems inappropriate
Hi, core-libs-dev and Brian, Paul,
I'd like to propose adding filtering method to Collectors.
When I consider the operation what is "grouping the number of employees
whose income is over 2000 by the depertment from employees", we have to
write following because there is no way to filter for Collec
On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote:
>
>> [Indeed, this whole section isn't strictly necessary; all of it can be
>> inferred from information in other places.]
>
> Agree. This section is no longer necessary and maybe just remove it:
I wasn't actually intending to suggest removal. It
Looks fine Aleksej. Reviewed.
Also approved for jdk8u-dev.
Regards,
Sean.
On 04/12/15 00:25, Aleksej Efimov wrote:
Hi,
Please, help to review and approve JDK-8133924 backport to JDK8. The
source fix is identical to JDK9 changes, but there was no test added
for this issue in JDK9.
The exis
Hi Kim,
Corrected
Thanks for all the review, Roger
On 12/4/2015 12:56 PM, Kim Barrett wrote:
On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote:
Hi Mandy,
The webrev[1] and javadoc[2] are updated in to address your comments.
Thanks, Roger
[1] http://cr.openjdk.java.net/~rriggs/webrev-cleane
On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote:
>
> Hi Mandy,
>
> The webrev[1] and javadoc[2] are updated in to address your comments.
>
> Thanks, Roger
>
> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
>
One t
Alexander,
>What is wrong with get/serErrorManager for Formatter? It should be just
>a way for Formatter to report its internal errors.
1. You can't inherit the Handler error manager until after construction of the
formatter. That means the concept of inheriting an error manager from a
handler
Hi Mandy,
The webrev[1] and javadoc[2] are updated in to address your comments.
Thanks, Roger
[1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
[2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
On 12/3/2015 8:43 PM, Mandy Chung wrote:
On Dec 3, 2015, at 1:19 PM, Roge
Hi,
Thanks for the review and comments.
The webrev[1] and javadoc[2] are updated in place.
Roger
[1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
[2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
On 12/3/2015 4:50 PM, mark.reinh...@oracle.com wrote:
Looks good -- th
Hi,
please review this issue to remove explicit initialization of
MethodHandleImpl, which doesn't seem to be needed after recent
j.l.invoke bootstrap improvements.
Bug: https://bugs.openjdk.java.net/browse/JDK-8144723
Webrev: http://cr.openjdk.java.net/~redestad/8144723/webrev.01/
This remov
On Dec 4, 2015, at 3:34 AM, Alan Bateman wrote:
> I suspect this is going to need a spec update to make it clear that close
> will now block when there is another thread blocking on the reader.
Do you think that could be done for java.io.Reader.close() (“This method might
block when another t
On 12/04/2015 03:17 PM, Per Liden wrote:
Hi Peter,
On 2015-12-04 13:35, Peter Levart wrote:
On 12/04/2015 08:16 AM, Per Liden wrote:
test/java/lang/ref/PhantomReferentClearing.java:
85 // Delete root -> O1, collect, verify P1 notified, P2 not
notified.
86 O1 = null;
Hi Kim,
On 12/3/2015 5:29 PM, Kim Barrett wrote:
On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote:
...
src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java
237 /**
238 * Returns true if the list's next reference refers to itself.
239 *
240 * @r
On 12/04/2015 02:46 PM, Doug Lea wrote:
Also, could you explain...
Note that such code and similar code in
ForkJoinTask.getThrowableException
will probably have to be modified for jigsaw to include dynamic
addition of
read-edge to the module of exception class...
-Doug
As jigsaw curr
Hi Peter,
On 2015-12-04 13:35, Peter Levart wrote:
On 12/04/2015 08:16 AM, Per Liden wrote:
test/java/lang/ref/PhantomReferentClearing.java:
85 // Delete root -> O1, collect, verify P1 notified, P2 not
notified.
86 O1 = null;
87 System.gc();
88 if (Q1
> On 3 Dec 2015, at 22:33, Mandy Chung wrote:
>
>
>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote:
>>
>> Hi,
>>
>> I have updated the patches:
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-
On 12/03/2015 04:22 AM, Peter Levart wrote:
What about the 4th option (keep current behavior, but try the best-effort
with reflection to make new exception of the same type):
We could do this, and if the attempt to clone fails, fall back
to addSuppressed of the original exception. As in:
On 12/04/2015 08:16 AM, Per Liden wrote:
test/java/lang/ref/PhantomReferentClearing.java:
85 // Delete root -> O1, collect, verify P1 notified, P2 not
notified.
86 O1 = null;
87 System.gc();
88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) {
89
Hi Brian,
On 12/4/15 9:48 AM, Daniel Fuchs wrote:
> I wonder if:
> 248 public void close() throws IOException {
> 249 synchronized (lock) {
> 250 buf = null;
> 251 }
> 252 super.close();
> 253 }
>
> would be a safer implementation. I don't know the
On 04/12/2015 00:23, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8143394
Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/
The NPE apparently occurred in PushbackReader because a call to close() was
made after the conditi
Hi ,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8142936/webrev.04/
Thanks and Regards,
Nadeesh
On 12/4/2015 3:12 AM, Roger Riggs wrote:
Hi Nadeesh,
Thanks for the update, sorry I missed some editorial comments last time.
toSeconds method missing a f
Sorry for my delayed review. Basically, I'm happy with this. Some oddments:
Map.ofEntries(Entry...)
"The entry objects themselves are not stored in the map."
This seems wrong. `Entry` might be implemented as a value, not an
object in the future. And if so, it might form part of the state of an
opt
On 03/12/15 21:47, John Rose wrote:
> We are takeing a crack at it with Panama, since using C APIs
> often requires timely deallocation of (non-Java) temps.
Indeed it does, and I guess I'll wait. I'm a bit disappointed because
I quite fancied trying to do mapped ByteBuffer.close(). While I could
> On 4 Dec 2015, at 01:58, Stuart Marks wrote:
>
> Small refresh here: after some consultation with Brian Goetz and John Rose,
> I've updated the class doc text covers immutability and value-based. They now
> say,
>
> * They are structurally immutable. Elements cannot be added, removed, or
>
Hi Brian,
The fix looks good to me! Good that you were able to find these
other classes where the same issue appeared.
I see that FilterReader.close() calls in.close(). Hopefully wrapping
this call (from PushbackReader) in a synchronized(lock) block
won't be an issue. I wonder if:
248 publi
59 matches
Mail list logo
