On Mon, Dec 7, 2015 at 4:19 PM, Stuart Marks wrote:
> Hi Maurizio,
>
> Well, maybe we should add five more overloads to EnumSet.of()? (Only
> slightly joking here.)
>
> Setting aside the number of overloads, it would add N more overloads to
> Set.of(). I guess the erasure of > would be Enum, so th
On 8/12/2015 1:39 AM, Rafael Winterhalter wrote:
In this case, one might consider:
if (o instanceof java.util.RandomAccess && (List)o).size() != size())
return false;
You'd also have to check the type of 'this'.
Type checks are cheap, so the overhead of this additional statement should
no
On 7/12/2015 9:39 PM, Erik Joelsson wrote:
On 2015-12-07 12:18, David Holmes wrote:
On 7/12/2015 6:33 PM, Erik Joelsson wrote:
On 2015-12-04 22:00, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8144677
http://cr.openjdk.java.net/~cjplu
Hi,
Another way have been found to satisfy the requirement(Thank you,
@gaku).
FYI, we can write it easy using toMap in this case:
Map map = emps.stream()
.collect(toMap(Employee::getDepartment,
e -> e.getSalary() > 2000 ? 1L : 0L, Long::sum));
However, filtering is still necessar
Thanks Mikael!
Chris
On 12/7/15 3:22 PM, Mikael Vidstedt wrote:
Thumbs up!
Cheers,
Mikael
On 2015-12-07 14:27, Chris Plummer wrote:
Thanks David!
Can I get a second reviewer please?
thanks,
Chris
On 12/6/15 3:52 PM, David Holmes wrote:
Hi Chris,
On 5/12/2015 7:00 AM, Chris Plummer wro
Hi Chris,
Yes, absolutely, my plan is to introduce a serial proxy in a subsequent round of
changes. The serial proxy will be the only new serial form introduced; the
optimized implementations won't have a serial form of their own exposed.
The skeleton implementations are in fact serializable
Hi Maurizio,
Well, maybe we should add five more overloads to EnumSet.of()? (Only slightly
joking here.)
Setting aside the number of overloads, it would add N more overloads to
Set.of(). I guess the erasure of > would be Enum, so there
wouldn't be any overload ambiguity
To me the quest
On Dec 4, 2015, at 3:34 AM, Alan Bateman wrote:
> 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 o
On Dec 4, 2015, at 12:48 AM, Daniel Fuchs wrote:
> The only other possible issue I spotted is in the test:
>
> Because readers[0] is set by one thread and read by both then using
> an array without synchronization is not thread safe. I would
> advise using an AtomicReference instead.
The only
Thumbs up!
Cheers,
Mikael
On 2015-12-07 14:27, Chris Plummer wrote:
Thanks David!
Can I get a second reviewer please?
thanks,
Chris
On 12/6/15 3:52 PM, David Holmes wrote:
Hi Chris,
On 5/12/2015 7:00 AM, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.jav
Thanks David!
Can I get a second reviewer please?
thanks,
Chris
On 12/6/15 3:52 PM, David Holmes wrote:
Hi Chris,
On 5/12/2015 7:00 AM, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8144677
http://cr.openjdk.java.net/~cjplummer/8144677/w
Thanks!
I'm not seeing this fail recently.
On Mon, Dec 7, 2015 at 1:39 PM, joe darcy wrote:
> Hello,
>
> Please review the changes to address
>
> JDK-8144880: Instrument intermittently failing test ConfigChanges.java
>
> The test
>
> java/util/concurrent/ThreadPoolExecutor/ConfigChanges.j
Hi Martin,
FYI, within the past month, we've seen this test fail at least once on
64-bit windows and at least once more on Solaris x64.
Thanks for the review,
-Joe
On 12/7/2015 2:07 PM, Martin Buchholz wrote:
Thanks!
I'm not seeing this fail recently.
On Mon, Dec 7, 2015 at 1:39 PM, joe da
Hi Joe
+1
Best
Lance
On Dec 7, 2015, at 4:39 PM, joe darcy wrote:
> Hello,
>
> Please review the changes to address
>
>JDK-8144880: Instrument intermittently failing test ConfigChanges.java
>
> The test
>
>java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java
>
> fails interm
Hello,
Please review the changes to address
JDK-8144880: Instrument intermittently failing test ConfigChanges.java
The test
java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java
fails intermittently and uses randomness. In the patch below, It is
marked accordingly and downgraded
On 07/12/2015 20:43, Joel Borggrén-Franck wrote:
:
Good question. Anyone? I'll grep for 1.9 if it is still there in lots of
places I would expect "someone else" to do a big cleanup job.
I think Iris is planning a bulk update to change them to 9 soon, might
need a couple of rounds to ensure th
Hi Paul,
See inline,
On Mon, 7 Dec 2015 at 21:39 Paul Benedict wrote:
> Joel, some comments on AnnotatedType#getAnnotatedOwnerType():
>
> * Is it convention to use tags to describe the complexity of the
> return value vs. just explaining it all in the @return tag?
>
> It is for the Core Reflec
Joel, some comments on AnnotatedType#getAnnotatedOwnerType():
* Is it convention to use tags to describe the complexity of the return
value vs. just explaining it all in the @return tag?
* What is the convention for @see nowadays? Is it 1.9 or 9?
Cheers,
Paul
On Mon, Dec 7, 2015 at 2:29 PM, Jo
Hi,
Thanks for the comments. I removed the allocations and fixed the
quadratic copy in popAllLocations.
New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.01/
cheers
/Joel
On Thu, Nov 19, 2015 at 2:07 PM, Claes Redestad
wrote:
> Hi Joel,
>
> looks good. I see a CCC has been filed.
On 12/06/2015 07:17 PM, Sundararajan Athijegannathan wrote:
Hi,
Please review the updated webrevs
http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.01/
http://cr.openjdk.java.net/~sundar/8143404/top/webrev.01/
http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/
Looks good.
Hi Sean,
Thanks for the review. Webrev has been updated accordingly. The
only suggestion I did not follow is to append the file name into the
zip error/exception message. I would assume it might have vuln
concern if the file name is published in such exception. It might be
OK to only publish the
Hi David,
Thanks for the comments,
Updated the javadoc and webrev with editorial changes.
[1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
[2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
On 12/6/15 7:46 PM, David Holmes wrote:
Hi Roger,
Sorry to be late here but w
2015/12/4 5:47 -0800, paul.san...@oracle.com:
>> On 3 Dec 2015, at 22:33, Mandy Chung wrote:
>>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote:
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachab
2015/11/30 6:58 -0800, g...@azul.com:
> Update: After some significant back-and-forth between Doug and I on
> naming and JavaDoc'ing, and with Martin (Thompson) stepping in to
> help, we have what we think is a good spec and name selection for this
> thing. We're proposing to add a new static metho
Hi Sherman,
Nice work. It'll certainly help protect the VM from bad application
code. I've no major issues with the new code. Some comments below.
src/java.base/share/classes/java/util/zip/ZipFile.java
unused import :
import java.nio.file.Path;
line 840 : This could be marked final
private
> On 7 Dec 2015, at 16:23, Tagir F. Valeev wrote:
>
> Hello, Chris, Paul!
>
> Thank you for the review.
>
>>> Tagir,
>>>
>>> It would seem most useful to update the implementation to
>>> match the current spec.
>
> PS> Yes, it’s an oversight and lacked a test for such case.
>
> PS> Tagir, t
In this case, one might consider:
if (o instanceof java.util.RandomAccess && (List)o).size() != size())
return false;
Type checks are cheap, so the overhead of this additional statement should
not be too big. Yet, maybe many list comparisons in practice involve lists
of equal size. Otherwise, t
I assume one reason it's done this way is that depending on the list
implementation you are using, getting the size might involve iterating over
all elements, so you would be iterating twice at worst case.
2015-12-07 16:28 GMT+01:00 Langer, Christoph :
> Hi all,
>
> a Java application developer o
Hi all,
a Java application developer of our company has indicated that it might yield
some performance benefit to modify the coding of
java.util.AbstractList.equals() that it would first compare the size of the
lists before iterating the elements. It would for sure be better in cases where
one
Hello, Chris, Paul!
Thank you for the review.
>> Tagir,
>>
>> It would seem most useful to update the implementation to
>> match the current spec.
PS> Yes, it’s an oversight and lacked a test for such case.
PS> Tagir, thanks for finding this. Would it be possible for you to
PS> also add a test
On 07/12/15 13:55, Paul Sandoz wrote:
On 7 Dec 2015, at 11:18, Chris Hegarty wrote:
Tagir,
It would seem most useful to update the implementation to
match the current spec.
Yes, it’s an oversight and lacked a test for such case.
Tagir, thanks for finding this. Would it be possible for you
> On 7 Dec 2015, at 11:18, Chris Hegarty wrote:
>
> Tagir,
>
> It would seem most useful to update the implementation to
> match the current spec.
Yes, it’s an oversight and lacked a test for such case.
Tagir, thanks for finding this. Would it be possible for you to also add a test
to jdk/te
On 05.12.15 21:23, Peter Levart wrote:
Digging up the src.jar of JDK 1.2.2, here's what the constructor of
PhantomReference looked like:
/**
* Creates a new phantom reference that refers to the given object and
* is registered with the given queue.
*
* @throws NullP
Hi Remi,
On 2015-12-07 12:42, Remi Forax wrote:
Hi Claes,
Makers should be declared 'private', so the constructor by default will be
private.
You should remove 'private' in front of TYPED_COLLECTORS,
PRODUCE_BLOCK_INLINING_FORM and PRODUCE_REINVOKER_FORM because otherwise the
compiler will g
Hi Claes,
Makers should be declared 'private', so the constructor by default will be
private.
You should remove 'private' in front of TYPED_COLLECTORS,
PRODUCE_BLOCK_INLINING_FORM and PRODUCE_REINVOKER_FORM because otherwise the
compiler will generate methods access$xxx inside Makers to access
On 2015-12-07 12:18, David Holmes wrote:
On 7/12/2015 6:33 PM, Erik Joelsson wrote:
On 2015-12-04 22:00, Chris Plummer wrote:
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 J
102 * They are serializable if all elements are serializable.
To avoid any ambiguity or "leaking", would it make sense to
have the serial form of these types be defined, in a similar
manner to what was done for Serializable types in the
java.time package [1].
This can be done as a follow up,
On 7/12/2015 6:33 PM, Erik Joelsson wrote:
On 2015-12-04 22:00, Chris Plummer wrote:
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"
• "-tests
Tagir,
It would seem most useful to update the implementation to
match the current spec. To that end, your first patch looks
like the most appropriate change, pattern-patch.txt.
-Chris.
On 06/12/15 12:21, Tagir F. Valeev wrote:
Hello!
Currently Pattern.splitAsStream JavaDoc says [1]:
* If
On 07/12/2015 03:17, Sundararajan Athijegannathan wrote:
Hi,
Please review the updated webrevs
http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.01/
http://cr.openjdk.java.net/~sundar/8143404/top/webrev.01/
http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/
Updated patches l
Hi Paul,
Thank you for your answer.
I've just updated my webrev to use 9:
http://cr.openjdk.java.net/~shinyafox/8144675/webrev.01/
Regards,
shinyafox(Shinya Yoshida)
2015-12-07 17:31 GMT+09:00 Paul Sandoz :
>
> On 7 Dec 2015, at 03:45, ShinyaYoshida wrote:
>
> Hi,
> I'd like to wait for the r
Hi Claes,
this is a lower-case review, but thumbs up. Truth or dare. ;-)
Best,
Michael
> Am 04.12.2015 um 17:28 schrieb Claes Redestad :
>
> Hi,
>
> please review this issue to remove explicit initialization of
> MethodHandleImpl, which doesn't seem to be needed after recent j.l.invoke
> bo
On 2015-12-04 22:00, Chris Plummer wrote:
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 exampl
> On 7 Dec 2015, at 03:45, ShinyaYoshida wrote:
>
> Hi,
> I'd like to wait for the review, but I have a trivial question:
>
> Which @since is preferred, 1.9 or 9?
>
@since 9
> For ex, at Optional#or and stream, @since 9 is used.
> On the other hand, at Collectors#flatMap, @since 1.9 is used
44 matches
Mail list logo
