hg: jdk7/tl/jdk: 6919132: Regex \P{Lu} selects half of a surrogate pari
Changeset: a39e899aa5dc
Author:sherman
Date: 2010-02-05 00:10 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a39e899aa5dc
6919132: Regex \P{Lu} selects half of a surrogate pari
Summary: To use StartS for complement category/block class
Reviewed-by: martin, okutsu
! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java
Re: hg: jdk7/tl/jdk: 6921740: Eliminate warnings from sun.io converters and allow compiling with JAVAC_MAX_WARNINGS=true
Le 05/02/2010 01:15, Ulf Zibis a écrit : Am 02.02.2010 18:47, schrieb Rémi Forax: Le 02/02/2010 17:26, Ulf Zibis a écrit : Am 02.02.2010 14:30, schrieb Rémi Forax: Le 02/02/2010 14:09, Ulf Zibis a écrit : Hi, in most cases you use the empty diamond operator '' on instantiation, but not for SoftReference: new SoftReferenceCharset(cs) in AbstractCharsetProvider.java Why? SoftReference constructor is SoftReference(T), so there is two ways to infer the type argument. With this code: SoftReferenceCharset ref = new SoftReference(cs); the type argument can be infered from the lhs of the assignation or by the declared type of the parameter (here cs). So you agree with me, that new SoftReference(cs) would suffice ??? No. The code is: cache.put(csn, new SoftReferenceCharset(cs)); It will not compile, because Object will be infered. Diamond doesn't take care about method's parameter types Hm? 1. Why ? (IMO would be resonable) 2. Didn't you say, type argument can be infered by the declared type of the parameter (here cs) ? -Ulf For the whole story see: http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/002393.html Rémi
Re: Math project or subproject
On Sun, Jan 31, 2010 at 9:02 AM, Patrick Wright pdoubl...@gmail.com wrote: In addition, I think that having an open-source micro-benchmarking library for this purpose would be very helpful. It might not be perfect or all-encompassing, but it would allow researchers and tinkerers a base on which to test their own code, and on which to base arguments of improvements to the current libs. In essence, it would be like saying that the OpenJDK is written as it is because it works well in these standard benchmarks, and if someone thinks they have improvements, they have to prove it against the same benchmarks that Sun/Oracle has used for their own decision-making. There is/was a Sun project I mentioned on another JDK thread, Japex (search online) which is a test harness for micro-benchmarking. Perhaps something like this could provide a standard benchmarking, with records of historical results, into which different tests could be plugged. I don't have any reason to prefer Japex over Caliper or another framework; in general I think that a framework that could take care (at least) of isolating the warm-up phase, taking and recording measurements, etc. would be better than people starting from scratch in main() each time they write a benchmark. FWIW, this is a very accurate depiction of our goals for Caliper and the reasons why we're making it. Development has been proceeding in fits and starts (presently: it's throwing a fit), but we intend to keep at it until it has become a very useful tool for you and others who do this kind of work. If you'd like to keep tabs on our development -- possibly even help? (dare I dream?) -- please drop me a line and I'll add you to our mailing list! -- Kevin Bourrillion @ Google internal: http://go/javalibraries external: guava-libraries.googlecode.com
hg: jdk7/tl/jdk: 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+)
Changeset: 7136683a33d2 Author:wetmore Date: 2010-02-05 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7136683a33d2 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+) Reviewed-by: ohair ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java
