On 07/19/2014 02:59 PM, Ivan Gerasimov wrote:
This looks just beautiful!
Thanks!
But why do you need the digits() function at all?
In my opinion, using formatUnsignedLong directly would be no less
clearer.
Sure!
http://cr.openjdk.java.net/~redestad/8006627/webrev.2/
Small improvement
On 20/07/2014 11:57, Peter Firmstone wrote:
Since private methods are only be called by the ObjectOutputStream /
ObjectInputStream, during de-serialisation, subclass are not responsible
for calling these methods, hence subclass ProtectionDomain's are not
present in the Thread's
Hi Kumar
Actually, the null check macros have different parameters.
NCRV_return_value is an integer.
RETURNVALUE in CHECK_JNI_RETURN is a macro, which allows us to have
only the two macros:
CHECK_JNI_RETURN
and
CHECK_JNI_RETRUN_EXCEPTION
I also think it is cleaner since there are only two,
Hi Claes,
Invalid inputs to UUID.fromString() behave a little different than
before. IllegalArgumentException is not thrown for the following inputs:
For example:
0: IllegalArgumentException: Invalid UUID string: 0 (before patch)
0: IndexOutOfBoundsException (after patch)
-0:
It appears input like now triggers different exception, the spec says
it should throw IAE.
-Sherman
On 07/21/2014 04:41 AM, Claes Redestad wrote:
On 07/19/2014 02:59 PM, Ivan Gerasimov wrote:
This looks just beautiful!
Thanks!
But why do you need the digits() function at all?
In my
Hello,
As a general comment, I think we should use more of StringJoiner in the
JDK libraries; it would help get rid of some awkward loops, even if it
isn't that compelling a code benefit in this case.
While performance is an important concern, I don't know if producing
modifier strings is
Hi,
new webrev which ensures we always throw some kind of IAE for invalid
inputs and adds a few tests to cover this behavior:
http://cr.openjdk.java.net/~redestad/8006627/webrev.4
/Claes
On 2014-07-21 20:05, Claes Redestad wrote:
Hi,
IIOB is invalid to throw here, so I'll fix that.
Hi,
was asked offline to add a length check at the start (prevents
potentially costly scans for huge, invalid input; negligible performance
impact for normal cases) and realized dash1 0 || dash2 0 || dash3
0 implies dash4 0, so the first three checks are unnecessary and can
be skipped:
On 07/21/2014 09:21 PM, Claes Redestad wrote:
Hi,
was asked offline to add a length check at the start (prevents
potentially costly scans for huge, invalid input; negligible
performance impact for normal cases) and realized dash1 0 || dash2
0 || dash3 0 implies dash4 0, so the first
On 7/18/14 4:41 PM, David M. Lloyd wrote:
On 07/18/2014 06:36 PM, Stuart Marks wrote:
Map.of()
.add(k0, v0)
.add(k1, v1)
...
.add(kN, vN);
this would result in O(N^2) performance and space allocation, though
most of the allocated space is garbage.
On 7/19/14 2:04 AM, Remi Forax wrote:
You can combine these 2 approachesi using a Ruby like builder approach with a
lambda,
which provide a builder object (so static method call are replaced by instance
method call) avoiding the creation of too many entry objects
Map.of(b - b
On 2014-07-21 22:05, Peter Levart wrote:
On 07/21/2014 09:21 PM, Claes Redestad wrote:
Hi,
was asked offline to add a length check at the start (prevents
potentially costly scans for huge, invalid input; negligible
performance impact for normal cases) and realized dash1 0 || dash2
0 ||
Hi Roman;
Somewhat unfortunately, just return null is what the default and all
conforming implementations do of compute do when presented with a Map
containing a mapping to null and a mapping function returning null. The
specification of the new Java 8 Map methods does not always handle maps
On Mon, Jul 21, 2014 at 10:58 AM, Joe Darcy joe.da...@oracle.com wrote:
Hello,
As a general comment, I think we should use more of StringJoiner in the
JDK libraries; it would help get rid of some awkward loops, even if it
isn't that compelling a code benefit in this case.
In performance
On 07/18/2014 12:00 PM, Georgiy Rakov wrote:
On 18.07.2014 20:14, Joe Darcy wrote:
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
15 matches
Mail list logo