March 2012 - core-libs-dev

hg: jdk8/tl/jaxws: 2 new changesets
by lana.steuck＠oracle.com 14 Mar '12

14 Mar '12

Changeset: 2637318c3fe0 Author: katleman Date: 2012-03-08 20:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2637318c3fe0 Added tag jdk8-b29 for changeset 4897d9d2d048 ! .hgtags Changeset: c65c291660eb Author: lana Date: 2012-03-09 11:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c65c291660eb Merge

1 0

hg: jdk8/tl/jaxp: Added tag jdk8-b29 for changeset 25099a745e1a
by lana.steuck＠oracle.com 14 Mar '12

14 Mar '12

Changeset: 3be30c25a825 Author: katleman Date: 2012-03-08 20:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3be30c25a825 Added tag jdk8-b29 for changeset 25099a745e1a ! .hgtags

1 0

hg: jdk8/tl/hotspot: Added tag jdk8-b29 for changeset b45b5c564098
by lana.steuck＠oracle.com 14 Mar '12

14 Mar '12

Changeset: d61761bf3050 Author: katleman Date: 2012-03-08 20:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d61761bf3050 Added tag jdk8-b29 for changeset b45b5c564098 ! .hgtags

1 0

hg: jdk8/tl/corba: 2 new changesets
by lana.steuck＠oracle.com 14 Mar '12

14 Mar '12

Changeset: e481748a8d74 Author: katleman Date: 2012-03-08 20:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e481748a8d74 Added tag jdk8-b29 for changeset 6117395d4226 ! .hgtags Changeset: 4605f8418bf5 Author: lana Date: 2012-03-09 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4605f8418bf5 Merge

1 0

hg: jdk8/tl: 2 new changesets
by lana.steuck＠oracle.com 14 Mar '12

14 Mar '12

Changeset: eacd6b140c0c Author: katleman Date: 2012-03-08 20:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/eacd6b140c0c Added tag jdk8-b29 for changeset 41460de04258 ! .hgtags Changeset: 6cea54809b51 Author: lana Date: 2012-03-09 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6cea54809b51 Merge

1 0

hg: jdk8/tl/jdk: 7152948: DatagramDispatcher.c should memset msghdr to make it portable to other platforms
by chris.hegarty＠oracle.com 14 Mar '12

14 Mar '12

Changeset: 68efc74309f9 Author: chegar Date: 2012-03-14 15:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68efc74309f9 7152948: DatagramDispatcher.c should memset msghdr to make it portable to other platforms Reviewed-by: alanb, chegar Contributed-by: Shi Jun Zhang <zhangshj(a)linux.vnet.ibm.com> ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c

1 0

CR 7148271 REGESSION with PNG Image loading
by Xueming Shen 14 Mar '12

14 Mar '12

Hi zlib 1.2.0.[4|5] and later have more "rigorous" distance-too-far boundary checks than previous versions. The PNG image file used in this case appears to be one of those "corrupted" files that have incorrect "distance" value in its compressed image data. This "invalid distance value" is exposed in JDK7, in which we upgraded the internal zlib from 1.1.3 to 1.2.3. A google search with "zlib png distance too far" suggests Java is not the only runtime/app that has this particular issue. Two compile options INFLATE_STRICT and INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR have been introduced in 1.2.3.4 to disable the "rigorous" check and permit those invalid distance-too-far streams. In java we are currently not defining any of them (as most of the zlib configuration does). These two options are for different distance-too-far scenarios. The first one appears to be for cases that the compressed data stream permits the distance, but the zlib header restricting the window size does not, which is not our case. In our particular PNG case, the "distance" to look up is outside the window that has valid data. To allow such corrupted zip/png file to "work" as it did in previous (<7) releases, two things need to be done (1)define INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR (2)call the "undocumented" inflateUndermine(strm, 1) after each inflateInit/Reset invocation as in webrev http://cr.openjdk.java.net/~sherman/7148271/webrev While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by default the j.u.zip.Inflater/PNGImageReader rejects such files (by throwing a zip exception, as the current JDK7 does) and to tolerate such files only with some -D flag, for example -Djava.util.zip.InflateAllowInvalidDistance. This definitely will be inconvenient for those who like the PNGImageReader to just work as it did in previous releases, but appears to be a more reasonable for me. Opinion? -Sherman

3 4

hg: jdk8/tl/jdk: 7150368: javac should include basic ability to generate native headers
by jonathan.gibbons＠oracle.com 13 Mar '12

13 Mar '12

Changeset: 361480e36b44 Author: jjg Date: 2012-03-13 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/361480e36b44 7150368: javac should include basic ability to generate native headers Reviewed-by: mcimadamore, darcy, ohrstrom ! make/docs/CORE_PKGS.gmk

1 0

hg: jdk8/tl/langtools: 7150368: javac should include basic ability to generate native headers
by jonathan.gibbons＠oracle.com 13 Mar '12

13 Mar '12

Changeset: b14d9583ce92 Author: jjg Date: 2012-03-13 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b14d9583ce92 7150368: javac should include basic ability to generate native headers Reviewed-by: mcimadamore, darcy, ohrstrom ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/javax/tools/StandardLocation.java + src/share/classes/javax/tools/annotation/GenerateNativeHeader.java ! test/tools/javac/diags/CheckResourceKeys.java + test/tools/javac/nativeHeaders/NativeHeaderTest.java + test/tools/javac/nativeHeaders/javahComparison/CompareTest.java + test/tools/javac/nativeHeaders/javahComparison/TestClass1.java + test/tools/javac/nativeHeaders/javahComparison/TestClass2.java + test/tools/javac/nativeHeaders/javahComparison/TestClass3.java

1 0

RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result
by Mike Duigou 13 Mar '12

13 Mar '12

Hello all; Currently Collections.sort() refuses to sort the lists which result from calling Collections.singletonList(). This makes some sense because the singleton lists are immutable but they are also alway sorted. This patch allows Collections.sort() to be used with empty and singleton lists of all types. A short circuit return is provided for lists of length 0 and 1 as they are already sorted. WEBREV: http://cr.openjdk.java.net/~mduigou/7065380/0/webrev/ For the unit test ignore the diffs and view the "New" file--webrev doesn't understand "hg copy". Thanks, Mike

5 12