The latest set of webrevs and bug reports has no known problems.
I tried to find all the "bug dups" that were awaiting this integration.
On Mon, Sep 21, 2015 at 12:21 PM, Paul Sandoz
wrote:
> Hi Martin,
>
> Thanks so much for doing this.
>
> Chris and I will cherry pick the appropriate API chang
Hi Remi,
On 22 Sep 2015, at 08:08, Remi Forax wrote:
> Hi Paul,
> to summarize, there are a lot of codes that do bound checking in the JDK that
> report different kind of exceptions.
>
Yes, and I suspect it is a similar state of affairs for code outside of the JDK
too.
> A way to retrofit
Hi Jason,
Not a bad idea, after some I tend to agree.
I was hesitating for two reasons, one is that they might be harder to find, and
the other is not all reported exceptions will be instances of
IndexOutOfBoundsException. However, as you point out not all bound checks are
related to arrays an
Hi,
Thanks for all the feedback.
Here is a new webrev:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/
Changes:
- Move check methods to IndexOutOfBoundsException
- Use BiFunction, rather than a specific exception mapping function.
- Add check methods t
Hi Martin,
Please take another look?
The language has been updated so it does not require discarding using a
file.
The URI of the webrev changed also:
http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/
Thanks, Roger
On 9/22/2015 2:52 AM, Martin Buchholz wrote:
On Mon, Sep 21
Dawid,
Multi-precision is one of several more or less interchangeable terms to
indicate that the precision of a value is limited by the amount of memory
available as opposed to the size of the primitive data type. For example in the
case of Java, large integers are represented internally to the
On 9/21/2015 11:51 PM, Dawid Weiss wrote:
Not that I understand the math behind it, but out of curiosity I
looked and spotted a typo in:
muti-precision
(unless it's some kind of complex IEEE-approved jargon for something I
have no idea about :).
No; just a typo in the original pow sources :
I approve the latest webrev.
But can't-stop-nitpicking Martin would write instead of
+ * The output may be discarded by writing to the operating
system specific
+ * null file.
"""A typical implementation discards the output by writing to an operating
system specific "null file".
Hi Mandy,
Here is a new webrev [1] - thanks a lot for all the time you
spent working with me on the API documentation!
As you suggested:
The specification of how readConfiguration uses system
properties to find the configuration has been
moved from the class-level documentation to the method
do
Hi,
Please review the following which adds methods to Arrays for performing
equality, comparison and mismatch:
https://bugs.openjdk.java.net/browse/JDK-8033148
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-
Dear all,
please review this change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00
This is actually a change to improve error reporting for identifying the issue
causing https://bugs.openjdk.java.net/browse/JDK-8131129, turni
+1
-Sundar
On 9/22/2015 10:40 PM, Michael Haupt wrote:
Dear all,
please review this change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00
This is actually a change to improve error reporting for identifying the issue
caus
On 22 Sep 2015, at 19:10, Michael Haupt wrote:
> Dear all,
>
> please review this change.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
> Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00
>
> This is actually a change to improve error reporting for identifying the
> iss
Hello,
Pack200 converts the timestamps to UTC for the pack200 archive format,
in order to do so, the default TimeZone was set to UTC, while reading
and
writing archives. This is problematic in a multi threaded environment.
With the fix for JDK-8075526 in place, the pack200 code is refactored
Hi Paul,
> Am 22.09.2015 um 19:54 schrieb Paul Sandoz :
>> This is actually a change to improve error reporting for identifying the
>> issue causing https://bugs.openjdk.java.net/browse/JDK-8131129, turning
>> assertions into actual checks. As the issue 8131129 is intermittent and
>> cannot be
On 09/22/2015 09:27 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.02
Looking quite good. Thanks for making the change.
Below are mostly javadoc comments and some minor implementation comments.
1474 * which should be in {@linkplain java.util.Properti
Hi Paul,
- Mail original -
> De: "Paul Sandoz"
> À: "core-libs-dev"
> Envoyé: Mardi 22 Septembre 2015 12:40:03
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
>
> Hi,
>
> Thanks for all the feedback.
>
> Here is a new webrev:
>
>
> http://cr.openjdk.jav
Hi Joe,
Overall this looks good. I only have a couple of minor observations related to
internal documentation.
1. FdLibm.java
Lines 158-166: The verbiage in the note might benefit from a little reworking.
2. HypotTests.java
Line 46: “Commutative” is misspelled.
Thanks,
Brian
On Sep 21, 201
On Sep 21, 10:38pm, rob.mcke...@oracle.com (Rob McKenna) wrote:
-- Subject: Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of str
| I'll have a new webrev up soon that addresses the first comment and
| Rogers feedback.
You know, given the complexity of the strerror_r() hacks to make
Hello!
Quite interesting feature. Isn't it a typo here?
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html
419if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i]))
487
20 matches
Mail list logo
