On 03/05/2013 19:02, huizhe wang wrote:
:
Removed the repetitive value definition from the
setAttribute/setProperty methods. The open statements already have
references to the properties in XMLConstants.
Updated to:
The default value is implementation specific and therefore not
specified.
On 05/04/2013 01:42 AM, Vitaly Davidovich wrote:
Personally, I think I'd exit the VM in this case. The odds of hitting
OOM while allocating TIE and having it be just a very unfortunate
transient condition are quite low; most likely, the VM is going to
have lots of trouble elsewhere anyway.
On 05/02/2013 06:37 PM, Brian Burkhalter wrote:
On May 2, 2013, at 5:02 AM, Alan Bateman wrote:
On 02/05/2013 02:34, Tim Buktu wrote:
:
Alan is working on an improved BigInteger.toString() that should
be dramatically faster for large numbers. What's the deadline for
getting this in?
Am 04.05.2013 04:28, schrieb Mike Duigou:
I have updated the webrev to include incorporate the feedback I have received.
http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/
Regarding the naming of the nonNull method. I originally added this method in 2011 but I've forgotten since
then
Hi Sherman,
looks good to me.
Maybe you like to compare with webrevs from:
https://bugs.openjdk.java.net/show_bug.cgi?id=100092
https://bugs.openjdk.java.net/show_bug.cgi?id=100095
-Ulf
Am 03.05.2013 06:29, schrieb Xueming Shen:
Hi,
Please help review the proposed fix for 8012326.
The
Oops, that was my mistake - I thought the lock here was a j.u.c.Lock which
of course doesn't even make sense given we're talking about ObjectMonitor.
So disregard that bit.
Ignoring OOM and continuing just seems very fragile as it means you somehow
know that all state is still consistent. Most
Thanks Ulf!
There is another version with a new ExtendedCharsets.java at
http://cr.openjdk.java.net/~sherman/8012326/webrev.newECP/
I merged the stuff in AbstractCharsetProvider into ExtendedCharsets.java.
The standardcharset provider now uses the FastCharsetProvider, so there
is no need to
On 05/04/2013 07:38 PM, Vitaly Davidovich wrote:
Oops, that was my mistake - I thought the lock here was a j.u.c.Lock
which of course doesn't even make sense given we're talking about
ObjectMonitor. So disregard that bit.
Ignoring OOM and continuing just seems very fragile as it means you
On 05/04/2013 2:13 PM, Alan Eliasen wrote:
My multiplication tests were written to test general multiplication,
but also to very strongly test around the regions at which Karatsuba and
Toom-Cook have edge cases. Since I don't know the Schönhage-Strassen
algorithms, I don't know where they
