June 2014 - core-libs-dev

RFR: 8044855: Add missing @since tag under java.beans.*
by Henry Jen 04 Jun '14

04 Jun '14

Hi, Please review a trivial webrev that provides missing @since tag for elements under java.beans, This version is determined based on javadoc of 1.0.2, 1.1.8 and 1.2.2. http://cr.openjdk.java.net/~henryjen/jdk9/8044855/0/webrev Cheers, Henry

2 1

RFR: JDK-8044727: Problem reading the contents of some zip files
by Xueming Shen 04 Jun '14

04 Jun '14

Hi, Please help review issue: https://bugs.openjdk.java.net/browse/JDK-8044727 webrev: http://cr.openjdk.java.net/~sherman/8044727/webrev/ cause: Regression caused by the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f [http://cr.openjdk.java.net/~sherman/6303183/webrev] in which the new implementation of ZipInoutStream.writeLOC() incorrectly tries to always interpret the ZIP64 extra data, if it "exists", even the size/csize fields of the entry have "normal' size data. The original implementation only does the check (and then setting), if at least one of the sizes (entry size and compressed size) has the "zip64 magic value" (this is what the zip64 spec says/requests the implementation to do). Those "offending" zip files obviously have the extra data with ZIP64 tag (0x0001), but the entry size/csize are "normal"/non-zip64-value. The change is to back to the correct implementation, only check and set the ZIP64 size(s) if the sizes in the zip entry size fields are "zip64 magic value". I'm not adding a regression test, as it will force to check in another "binary" zip file into the repository (the ZipOutputStream does not output a "bogus" extra data with ZIP64 tag, if the sizes do not requires a ZIP64 extra data). I've manually verify the fix against the test case attached in the bug report. Thanks! -Sherman

2 1

RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo
by Henry Jen 04 Jun '14

04 Jun '14

Hi, In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions. The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information. Some public APIs are using @since <STANDARD> <standard version> format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE. There are APIs without @since information, separate webrevs will be coming to complete those information. Bug: https://bugs.openjdk.java.net/browse/JDK-8044740 The webrev can be found at http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev but it's probably easier just look into the raw diff, http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset Cheers, Henry

8 8

RFR (S): JDK-8039916: AnnotatedType.getType() of a Executable parameters may return wrong type
by Joel Borggrén-Franck 04 Jun '14

04 Jun '14

Hi Can I get a review for this small fix for https://bugs.openjdk.java.net/browse/JDK-8039916 Webrev here: http://cr.openjdk.java.net/~jfranck/8039916/webrev.01/ Since this is the second issue like this found recently I created a rather large test to see if there are any more lurking issues. I found one more, see: https://bugs.openjdk.java.net/browse/JDK-8044629 .I need to figure out what the right behavior for the new issue, is so I need to delay that fix. cheers /Joel

3 4

RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately
by Aleksej Efimov 04 Jun '14

04 Jun '14

Hi, Can I have a review for 8032901 bug [1] fix [2]. There is a possible case when 'WaitForMultipleObjects' function can return the WAIT_ABANDONED_0 [3] error value. In such case it's better to release the mutex and return error value. This will prevent other threads to be blocked on abandoned mutex. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8032901 [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ [3] http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).a…

5 14

RFR: JDK-8044725: Bug in zlib 1.2.5 prevents inflation of some gzipped files
by Xueming Shen 04 Jun '14

04 Jun '14

Hi, Please help review the change to upgrade the zlib bundled with jdk/jre from 1.2.5 to 1.2.8. This is mainly to address the bug fix mentioned in 1.2.8's release at zlib.net. "Version 1.2.8 fixes a very rare bug in decompression. All users are encouraged to upgrade immediately..." http://cr.openjdk.java.net/~sherman/8044725/webrev thanks! -Sherman

3 2

RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output
by A. Sundararajan 03 Jun '14

03 Jun '14

Hi, Please review http://cr.openjdk.java.net/~sundar/8044647/ Thanks, -Sundar

4 4

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
by John Rose 03 Jun '14

03 Jun '14

On May 16, 2014, at 4:56 AM, Tobias Hartmann <tobias.hartmann(a)oracle.com> wrote: > Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? Yes, that is how I see it. The fast path is a racy non-volatile read of a safely-published structure. (If safe publication via arrays were broken, java.lang.String would be broken. But the JMM is carefully designed to support safe publication of array elements, and through array elements.) — John

4 7

RFR: JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method
by Alexander Zuev 02 Jun '14

02 Jun '14

Hello, please, review my fix for the issue JDK-8044206: LambdaMetafactory.altMetafactory javadoc refers to wrong method Link to the issue: https://bugs.openjdk.java.net/browse/JDK-8044206 Webrev: http://cr.openjdk.java.net/~kizune/8044206/webrev.00 The fix is trivial, the JavaDoc for the LambdaMetafactory.altMetafactory() stated that it's more advanced version of the more streamlined method and linked itself instead of the method LambdaMetafactory.metafactory() /Alex

2 1

RFR: 8041602 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions
by Mark Sheppard 02 Jun '14

02 Jun '14

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041602/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041602 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8035340 the original changeset didn't apply cleanly and was applied manually http://hg.openjdk.java.net/jdk9/dev/jdk/rev/740ffd98e35a regression tests ran ok and finally please approve backport to jdk8u-dev regards Mark

2 2