Most of this is for Stuart - very collection-y.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
This includes a rewrite of ArrayDeque to bring it to parity with ArrayList
(except for List features).
The patch includes public methods ensureCapacity, trimToSize, replace
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On Oct 17, 2016, at 7:20 PM, Stuart Marks wrote:
>
> Hi all, please review this tiny fix to the javadoc markup in
On 10/17/16 5:16 PM, Paul Sandoz wrote:
On 17 Oct 2016, at 16:36, John Rose wrote:
On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote:
On 17 Oct 2016, at 15:01, Stuart Marks wrote:
Usually I wrinkle my nose at a throw that's caught by a catch clause later on,
but in this case it's not obvious
On 18/10/2016 10:09 AM, Paul Sandoz wrote:
On 17 Oct 2016, at 15:33, David Holmes mailto:david.hol...@oracle.com>> wrote:
Hi Paul,
Looking at hotspot changes only ...
On 15/10/2016 8:08 AM, Paul Sandoz wrote:
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-e
> On 17 Oct 2016, at 16:36, John Rose wrote:
>
> On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote:
>>
>>
>>> On 17 Oct 2016, at 15:01, Stuart Marks wrote:
>>>
>>> Hi Paul,
>>>
>>> I took a look at the jdk changes. They look good to me.
>>>
>>> One section of code gave me pause, which is the
> On 17 Oct 2016, at 15:33, David Holmes wrote:
>
> Hi Paul,
>
> Looking at hotspot changes only ...
>
> On 15/10/2016 8:08 AM, Paul Sandoz wrote:
>> Hi,
>>
>> Please review:
>>
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/
>>
>> http://cr
> On Oct 17, 2016, at 4:30 PM, Peter Levart wrote:
>
> ...you would review the members that are allowed and then you should ask
> yourself: "Which are the ones that are denied? All the rest. What are they?",
> or: "Could there be any other that should be allowed? Which one?”
I’m happy with yo
On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote:
>
>
>> On 17 Oct 2016, at 15:01, Stuart Marks wrote:
>>
>> Hi Paul,
>>
>> I took a look at the jdk changes. They look good to me.
>>
>> One section of code gave me pause, which is the throw of ClassCastException
>> at 339 of CallSite.java, and
Hi Mandy,
On 10/17/2016 10:52 PM, Mandy Chung wrote:
On Oct 16, 2016, at 11:18 AM, Peter Levart wrote:
I think specifying both is more verbose on one hand, but OTOH it allows one to
visually inspect all the cases and think of each and every one in isolation to
see if it is valid in a parti
+1
-Joe
On 10/17/2016 4:20 PM, Stuart Marks wrote:
Hi all, please review this tiny fix to the javadoc markup in the
Deprecated annotation type.
Thanks,
s'marks
--- a/src/java.base/share/classes/java/lang/Deprecated.javaThu Oct
13 23:02:35 2016 +
+++ b/src/java.base/share/classes
Hi all, please review this tiny fix to the javadoc markup in the Deprecated
annotation type.
Thanks,
s'marks
--- a/src/java.base/share/classes/java/lang/Deprecated.java Thu Oct 13 23:02:35
2016 +
+++ b/src/java.base/share/classes/java/lang/Deprecated.java Mon Oct 17 16:18:26
2016 -070
> On 17 Oct 2016, at 15:01, Stuart Marks wrote:
>
> Hi Paul,
>
> I took a look at the jdk changes. They look good to me.
>
> One section of code gave me pause, which is the throw of ClassCastException
> at 339 of CallSite.java, and the throw of the exception returned from
> wrongTargetType()
Hi Paul,
Looking at hotspot changes only ...
On 15/10/2016 8:08 AM, Paul Sandoz wrote:
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-hotspot/webrev/
Hi Paul,
I took a look at the jdk changes. They look good to me.
One section of code gave me pause, which is the throw of ClassCastException at
339 of CallSite.java, and the throw of the exception returned from
wrongTargetType() at 344 of CallSite.java. This appears odd given the "rethrow
any
> On Oct 17, 2016, at 2:18 PM, Claes Redestad wrote:
>
> http://cr.openjdk.java.net/~redestad/8168073/webrev.02/
+1
Mandy
> On 17 Oct 2016, at 14:18, Claes Redestad wrote:
>
>
>
> On 2016-10-17 21:35, Alan Bateman wrote:
>>
>>
>> On 17/10/2016 19:45, Claes Redestad wrote:
>>>
>>> Most other SharedSecrets classes seems to be per-package, so not sure
>>> if this case is special enough to start making them per-cl
On 2016-10-17 21:35, Alan Bateman wrote:
On 17/10/2016 19:45, Claes Redestad wrote:
Most other SharedSecrets classes seems to be per-package, so not sure
if this case is special enough to start making them per-class, other
than the slightly more natural naming.
JavaNetHttpCookieAccess, Jav
> On Oct 16, 2016, at 11:18 AM, Peter Levart wrote:
>
>
> I think specifying both is more verbose on one hand, but OTOH it allows one
> to visually inspect all the cases and think of each and every one in
> isolation to see if it is valid in a particular caller/member/target
> arrangement. T
Hello,
I am sponsoring this patch for the client team, the issue here
is that the Windows installer copies the java launcher binaries to a
system folder, and those binaries need to locate the Java Runtime
using Windows registry. These changes are to allow calling an
internal (Registry locator) me
> On 17 Oct 2016, at 10:53, Claes Redestad wrote:
>
> Hi Paul,
>
> On 2016-10-17 19:39, Paul Sandoz wrote:
>> Hi Claes,
>>
>> This looks good.
>
> Thanks!
>
>>
>> Did you consider adding asserts to the package private constructor?
>
> No, might be reasonable. Do you insist? :-)
>
A gentl
> On Oct 17, 2016, at 11:07 AM, Alan Bateman wrote:
>
>
>
> On 17/10/2016 12:17, Claes Redestad wrote:
>> Hi,
>>
>> one partial cause for startup regressions due to jigsaw is related to
>> creating
>> URIs for the location of each module.
>>
>> By providing a package-private constructor we
On 17/10/2016 19:45, Claes Redestad wrote:
Most other SharedSecrets classes seems to be per-package, so not sure
if this case is special enough to start making them per-class, other
than the slightly more natural naming.
JavaNetHttpCookieAccess, JavaNetInetAddressAccess and
JavaNetSocketAcce
On 2016-10-17 20:07, Alan Bateman wrote:
On 17/10/2016 12:17, Claes Redestad wrote:
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to
scan and
validate
On 17/10/2016 12:17, Claes Redestad wrote:
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to
scan and
validate the URI, which takes a little time (exec
Hi Paul,
On 2016-10-17 19:39, Paul Sandoz wrote:
Hi Claes,
This looks good.
Thanks!
Did you consider adding asserts to the package private constructor?
No, might be reasonable. Do you insist? :-)
/Claes
Paul.
On 17 Oct 2016, at 04:17, Claes Redestad wrote:
Hi,
one partial cause
Hi Paul,
On 2016-10-17 19:39, Paul Sandoz wrote:
Hi Claes,
This looks good.
Thanks!
Did you consider adding asserts to the package private constructor?
No, might be reasonable. Do you insist? :-)
/Claes
Paul.
On 17 Oct 2016, at 04:17, Claes Redestad wrote:
Hi,
one partial cause
Hi Claes,
This looks good.
Did you consider adding asserts to the package private constructor?
Paul.
> On 17 Oct 2016, at 04:17, Claes Redestad wrote:
>
> Hi,
>
> one partial cause for startup regressions due to jigsaw is related to creating
> URIs for the location of each module.
>
> By pr
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to scan
and
validate the URI, which takes a little time (executes ~80K bytecodes)
but also
pushes various
Please file an RFE for this issue so that the core-libs team can evaluate.
While this seems like a good use for default methods, it may be difficult to
justify including a convenience method
at this late stage in the JDK 9 schedule.
Thanks.
> On 14 Oct 2016, at 22:21, Laird Nelson wrote:
>
>
Hi all
Please review the fix for the bug
Bug :https://bugs.openjdk.java.net/browse/JDK-8075205
The tests uses classes directory for the output files. This can result in the
files being left over after the test is complete which can result in
instability. The tests copies the files to be compi
30 matches
Mail list logo
