hg: jdk8/tl/jdk: 3 new changesets

Changeset: cd56de5896b4 Author:aefimov Date: 2013-11-15 15:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd56de5896b4 8027848: The ZoneInfoFile doesn't honor future GMT offset changes Reviewed-by: sherman, coffeys ! src/share/classes/sun/util/calendar/ZoneInfoFile.java

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

We've synced our staging repository yesterday with the latest jdk8-b117 and I noticed that change 8025985: com.sun.management.OSMBeanFactory should not be public moved the file src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c to

Different error decoding Shift-JIS sequence in JDK8

Apologies if this is not the correct place to post this, bit i18n seemed more focused on languages and localization than the mechanics of transcoding. I have noticed a behavioral difference in JDK8 decoding a two-byte Shift-JIS sequence. Specifically, JDK8 appears to report malformed input for

ISO-8859-16 charset/decoder/encoder

Again, apologies if this is not the right list. OpenJDK does not currently contain support for encoding/decoding ISO-8859-16. A JRuby user recently reported that they needed this encoding. So, I implemented it. Here's a link to the charset/decoder/encoder in JRuby's repository:

RFR 8028516 Java doc error in Int/Long/Double/Stream.peek

Hi, https://bugs.openjdk.java.net/browse/JDK-8028516 An attendee of the Devoxx lambda hackathon spotted some doc bugs in code samples of the stream peek methods. I updated those samples to be stand alone samples and verified they compile. Paul. diff -r 4bc37b6c4133

hg: jdk8/tl/jdk: 8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute

Changeset: 0775f4f6532a Author:jfranck Date: 2013-11-22 11:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0775f4f6532a 8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute Reviewed-by: darcy

Re: RFR 8028516 Java doc error in Int/Long/Double/Stream.peek

Look good to me Paul. -Chris On 22/11/13 11:24, Paul Sandoz wrote: Hi, https://bugs.openjdk.java.net/browse/JDK-8028516 An attendee of the Devoxx lambda hackathon spotted some doc bugs in code samples of the stream peek methods. I updated those samples to be stand alone samples and

Re: Different error decoding Shift-JIS sequence in JDK8

On 22/11/2013 11:02, Charles Oliver Nutter wrote: Apologies if this is not the correct place to post this, bit i18n seemed more focused on languages and localization than the mechanics of transcoding. I have noticed a behavioral difference in JDK8 decoding a two-byte Shift-JIS sequence.

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 21/11/2013 15:54, Volker Simonis wrote: : But actually I've just realized that it is not need at all, because 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be probably called a feature of the new file layout:) So I'll simply change it to: 48 ifeq

Re: RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute

Thanks for the review Joe cheers /Joel On 2013-11-21, Joe Darcy wrote: Hi Joel, Looks fine; thanks, -Joe On 11/21/2013 11:50 AM, Joel Borggrén-Franck wrote: Hi Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

Hi Alan, so I'll rename 'initLocalAddrTable()' into 'platformInit()' and move the call to 'aix_close_init' to a AIX-specific version of 'platformInit()' in net_util_md.c as discussed. I'll post a final webrev once I got the comments from the AWT/2D guys. As far as I understood, you've now

Re: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)

The reason it's three slashes is that empty string is legal in place of localhost, file://host/path therefore becomes file:///path. And the reason the test was failing was that JAXP unit tests use: getClass().getResource(filename).getPath() or getFile() that returns it in a format, on

RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

Updated request. This is for a bug that it deferred by compilers, but runtime really wants it fixed because they are working in the same area and don't like it at all. In particular, they want it committed to hotspot-rt ASAP (don't want to wait for the multiweek turnaround) and thus the diffs and

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

David, Thank you so much for finding a way to do this. We do think this is important to get in for 8. And thank you for a way to check the hotspot changes in without waiting for the jdk changes. Code looks good. Couple of minor comments: 1. universe.cpp - when the hotspot change gets in and

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

On 2013-11-22, at 2:56 PM, Karen Kinnear karen.kinn...@oracle.com wrote: David, Thank you so much for finding a way to do this. We do think this is important to get in for 8. And thank you for a way to check the hotspot changes in without waiting for the jdk changes. Code looks good.

BigInteger Burnikel-Ziegler division algorithm crossover heuristic

Hello, We've been doing fairly extensive micro-benchmark testing of the effect of adjusting the various algorithm crossover thresholds in BigInteger (cf. https://bugs.openjdk.java.net/browse/JDK-8022181). There'll be another post on that particular topic in the near future. This testing did

Re: Map.merge Javadoc is confusing

On 22/11/2013 5:02 AM, Louis Wasserman wrote: While I agree that case should be specified, I'm not certain I follow why that's what's going on here. The weird condition is that if oldValue is null, not value; oldValue is the old result of map.get(key). The Javadoc seems not just unspecified,

Re: Map.merge Javadoc is confusing

On 11/21/2013 06:33 PM, David Holmes wrote: On 22/11/2013 5:02 AM, Louis Wasserman wrote: While I agree that case should be specified, I'm not certain I follow why that's what's going on here. The weird condition is that if oldValue is null, not value; oldValue is the old result of

RFR: 8029055: Map.merge @implDoc is incorrect. (was: Map.merge Javadoc is confusing)

We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. I've posted a webrev here: http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ There is an identical change in ConcurrentMap's merge(). Mike On Nov 22 2013, at 16:01 , Henry Jen henry@oracle.com wrote:

Re: RFR: 8029055: Map.merge @implDoc is incorrect. (was: Map.merge Javadoc is confusing)

+1 (Not a reviewer). Cheers, Henry On Fri 22 Nov 2013 04:25:50 PM PST, Mike Duigou wrote: We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. I've posted a webrev here: http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ There is an identical change in

hg: jdk8/tl/langtools: 8028739: javac generates incorrect descriptor for MethodHandle::invoke

Changeset: 4fa835472e3c Author:rfield Date: 2013-11-22 17:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4fa835472e3c 8028739: javac generates incorrect descriptor for MethodHandle::invoke Summary: introduce special handling for signature polymorphic methods

Re: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors

Hello Mike and Paul, Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at http://cr.openjdk.java.net/~darcy/8006572.4/ Two numerical aspects of the change are different in this iteration: * when two running compensated