Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Looks good Joe. -Chris > On 11 Mar 2016, at 22:28, joe darcy wrote: > > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can directly > include the bug number associated with the test in question, enabling better > reporting. This format should be

Re: RFR: 8054213: Class name repeated in output of Type.toString()

Hi all, bug https://bugs.openjdk.java.net/browse/JDK-8054213 I have reworked previous patch to conform with JLS 13.1 paragraph 1 and also JVMS 4.2.1. For now in case of parametrized types inner type name consists of normal binary name of immediately enclosing type, followed by $, followed by

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Looks fine. On 12.03.16 6:28, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the

RFR: 8054213: Class name repeated in output of Type.toString()

Hi all, Please review this patch. I'm also looking for sponsor for this one. The unexpected duplication of owner type was produced by Method.toString() for static classes and interfaces. Problem is fixed by slightly changing the way of obtaining simple name of static nested type and

Re: JDK 9 build 109 -> Lucene's Ant build works again; still missing Hotspot patches

On 12/03/2016 11:43, Uwe Schindler wrote: : Nevertheless, build 109 does not contain (according to the changelog) fixes for JDK-8150436 (still fails consistently) and JDK-8148786 (our duplicate issue JDK-8150280, happens sometimes). Those patches were committed long ago. What's the reason

JDK 9 build 109 -> Lucene's Ant build works again; still missing Hotspot patches

Hi, I just wanted to inform you that the first Lucene test with build 109 of JDK were working with Ant and Ivy (both on Linux and Windows including whitespace in build directory), so the Multi-Release JAR file fix did not break the build system anymore. Many thanks to Steve Drach and Alan

Re: RFR 9: 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked exception

And just to note that only ofLocalizedTime and ofLocalizedDateTime are affected by this text. The ofLocalizedDate() method doesn't seem to use the time-zone, so the Javadoc should be vaguer. On 12 March 2016 at 09:47, Stephen Colebourne wrote: > I think the new text needs

Re: RFR 9: 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked exception

I think the new text needs should be more specific: The {@code FULL} and {@code LONG} styles typically require a time-zone. When formatting using these styles, a {@code ZoneId} must be available, either by using {@code ZonedDateTime} or {@link DateTimeFormatter#withZone}. (testing shows that the

AW: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hello, Regarding “exceptional”: Speeding up stack-walking can greatly help log frameworks (when they are configured to log the callsite). They hopefully do not use Throwables anymore, but I guess the other variants to get the stack traces of the last few frames on the stack still benefit from