Hello Olivier.
Olivier Lagneau wrote:
Please review The implementation of a fast-path algorithm for
optimizing the
DecimalFormat(double, ...) call stack.
The webrev is here :
http://cr.openjdk.java.net/~alanb/7050528/webrev.01
As described in the CR evaluation and suggested fix,
the speed-up
Looks fine.
On 9/13/2011 1:54 PM, Mandy Chung wrote:
6915797: Remove sun.tools.jar.JarImageSource that is not used
7090178: Move java.util.XMLUtils to another package to avoid split
package
Webrev at:
http://cr.openjdk.java.net/~mchung/6915797/webrev.00/
The synopsis says it all.
Thank
On 14/09/2011 3:26 AM, Alan Bateman wrote:
Michael McMahon wrote:
Can I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/
I scanned this briefly (I haven't done a detailed code review) but one
initial comment is that Runtime.exec will now throw
Il
Changeset: ca2e2b85f437
Author:mchung
Date: 2011-09-13 16:37 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca2e2b85f437
7090297: Remove com.sun.tools.javac.Launcher from tools.jar
Reviewed-by: jjg
- src/share/classes/com/sun/tools/javac/Launcher.java
Please review The implementation of a fast-path algorithm for optimizing the
DecimalFormat(double, ...) call stack.
The webrev is here :
http://cr.openjdk.java.net/~alanb/7050528/webrev.01
As described in the CR evaluation and suggested fix,
the speed-up on a micro-benchmark is ~x11 on Sparc-USI
6915797: Remove sun.tools.jar.JarImageSource that is not used
7090178: Move java.util.XMLUtils to another package to avoid split package
Webrev at:
http://cr.openjdk.java.net/~mchung/6915797/webrev.00/
The synopsis says it all.
Thanks
Mandy
Hi i created a small concept-demo how i think we can manage to remove
some flaws(public accessible fields) out of the jdk without breaking
binary-compatibility. I uploaded the "code of cencept" to my
github-incubator[0] and posted some description on my weblog[1]. It
would be nice to get some
Michael McMahon wrote:
Can I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/
I scanned this briefly (I haven't done a detailed code review) but one
initial comment is that Runtime.exec will now throw
IllegalArgumenetException for that a case tha
Can I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/
The problem is when calling Runtime.exec(String) with a program name
containing
white space (on win32), it is difficult to distinguish between the
program name and
any parameters to it.
Eg.
Changeset: 3bec5415a227
Author:cl
Date: 2011-08-18 18:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/3bec5415a227
Added tag jdk8-b01 for changeset f42e3d9394b4
! .hgtags
Changeset: e01201e727da
Author:neugens
Date: 2011-07-26 21:54 +0200
URL: http://hg.openjdk
Changeset: ed338593b0b6
Author:mcimadamore
Date: 2011-09-13 14:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ed338593b0b6
7086595: Error message bug: name of initializer is 'null'
Summary: Implementation of MethodSymbol.location() should take into account
static/in
Changeset: e0c1282a0ead
Author:coffeys
Date: 2011-09-13 11:21 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0c1282a0ead
7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file
descriptor be closed when still in use
Reviewed-by: alanb
! src/share/classes/java
On 13/09/2011 5:51 PM, Jing LV wrote:
> I've meet a subtle issue with Timer. As we know, every Timer objects
> spawn a new thread (which is optionally a daemon thread). On VM
> shutdown, there is no way to ensure that the daemon thread terminates
That's exactly the point of daemon threads - they g
Seán Coffey wrote:
Cleaned up testcase (as per suggestions) is in latest webrev :
http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8.2/
Updated test looks fine to me. Minor comment is that I assume the
/timeout=100 in the @run tag isn't needed.
-Alan.
Jing LV wrote:
Hello,
I've meet a subtle issue with Timer. As we know, every Timer objects
spawn a new thread (which is optionally a daemon thread). On VM
shutdown, there is no way to ensure that the daemon thread terminates
(cancel() and purge() only clear the queue). This can lead to non-clean
Hello,
I've meet a subtle issue with Timer. As we know, every Timer objects
spawn a new thread (which is optionally a daemon thread). On VM
shutdown, there is no way to ensure that the daemon thread terminates
(cancel() and purge() only clear the queue). This can lead to non-clean
VM shutdown (ret
16 matches
Mail list logo
