February 2012 - core-libs-dev

hg: jdk8/tl/langtools: 7142086: performance problem in Check.checkOverrideClashes(...)
by maurizio.cimadamore＠oracle.com 14 Feb '12

14 Feb '12

Changeset: 84b61130cbed Author: mcimadamore Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84b61130cbed 7142086: performance problem in Check.checkOverrideClashes(...) Summary: Code in Check.checkOverrideClashes() causes too many calls to MethodSymbol.overrides Reviewed-by: jjg Contributed-by: jan.lahoda(a)oracle.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/7142086/T7142086.java

1 0

hg: jdk8/tl/jdk: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc
by vincent.x.ryan＠oracle.com 14 Feb '12

14 Feb '12

Changeset: f62077973f9b Author: vinnie Date: 2012-02-14 11:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f62077973f9b 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/ec.sh

1 0

Re: Warning Fixes from LJC Hack Session
by Michael Barker 14 Feb '12

14 Feb '12

> I see Rémi has suggested a slice & dice but I think that's a bit too much > work for the changes involved. Instead I would suggest a simple split, send > the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else to > core-libs-dev. Attached is the patch that contains "everthing else" from LJC warning fixes hack session. Mike.

4 6

hg: jdk8/tl/langtools: 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...)
by jim.holmlund＠sun.com 14 Feb '12

14 Feb '12

Changeset: 237198ef45f5 Author: jjh Date: 2012-02-13 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/237198ef45f5 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/T7142672/AnnoProcessor.java + test/tools/javac/T7142672/Bug.java + test/tools/javac/T7142672/Test2.java + test/tools/javac/T7142672/Test3.java

1 0

Codereview request for 4153167: separate between ANSI and OEM code pages on Windows
by Xueming Shen 13 Feb '12

13 Feb '12

Hi This is a long standing Windows codepage support issue on Java platform (we probably have 20 bug/rfes filed for this particular issue and closed as the dup of 4153167). Windows supports two sets of codepages, ANSI (Windows) codepage and OEM (IBM) codepage. Windows uses ANSI/Windows codepage almost "everywhere" except in its dos/command prompt window, which uses OEM codepage. For example, on a normal English Windows, the default Windows codepage isCp1252 <http://msdn.microsoft.com/en-us/goglobal/cc305145> (west European Latin) and the OEM codepage used in its dos/command prompt however is Cp437 <http://msdn.microsoft.com/en-us/goglobal/cc305156> (you can use chcp command to check/change the "active" codepage used in your dos/coomand prompt). These two obviously have different mapping for certain code points, for example those umlaut characters. J2SE runtime chooses the ANSI/Windows codepage as its default charset for its i/o character reading/writing, graphic text display, etc. including System.out&err. This causes problem when the ANSI code page and OEM codepage are not "compatible" and you happen to need to write those "in-compatible" characters to the dos/command prompt, as show in the following test case String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), true ); ps.println("ps.cp437: " + umlaut); System.out.println("sys.out : " + umlaut); System.err.println("sys.err : " + umlaut); You will see the umlauts get displayed correctly from PrintWriter with explicit Cp437 encoding setting, but garbled from system.out and err (because both the System.out & err use the default charset Cp1252, which is also used for all necessary Unicode <-> Windows encoding conversion for that particular vm instance). For years, we have been debating whether or not we should and how to fix this issue, do we want to have two "default charset" for i/o. In jdk6, we have provided a java.io.Console class that specifically uses OEM codepage when running on Windows' dos/command prompt. However, the feedback is that people still want the System.out/err to work correctly with the dos/command prompt, when the OEM codepage used is not "compatible" with the default Windows codepage. The proposed change here is to use OEM codepage for System.out/err when the vm is started without its std out/err is redirected to something else, such as a file (make sure to only use OME for the dos/command prompt), if vm's std out/err is redirected, then continue to use the default charset (file.encoding) for the System.out/err. I believe this approach solves the problem without breaking any existing assumption/use scenario. The webrev is at http://cr.openjdk.java.net/~sherman/4153167/webrev Here is a simple"manual" test case. public class HelloWorld { public static void main(String[] args) throws Exception { String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; System.out.println("file.encoding =" + System.getProperty("file.encoding")); System.out.println("stdout.encoding=" + System.getProperty("sun.stdout.encoding")); System.out.println("stderr.encoding=" + System.getProperty("sun.stderr.encoding")); System.out.println("-----------------------"); PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), true ); ps.println("ps.cp437: " + umlaut); System.out.println("sys.out : " + umlaut); System.err.println("sys.err : " + umlaut); Console con = System.console(); if (con != null) con.printf("console : %s%n", umlaut); } } -Sherman

5 13

hg: jdk8/tl/jdk: 2 new changesets
by vincent.x.ryan＠oracle.com 13 Feb '12

13 Feb '12

Changeset: 3554f175341a Author: vinnie Date: 2012-02-13 14:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3554f175341a 7142339: PKCS7.java is needlessly creating SHA1PRNG SecureRandom instances when timestamping is not done Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/pkcs/PKCS7.java Changeset: 59bd472746d6 Author: vinnie Date: 2012-02-13 14:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59bd472746d6 Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java

1 0

Re: Easy-to-fix javadoc warning
by Chris Hegarty 13 Feb '12

13 Feb '12

Thanks for reporting this Jon. I filed CR 7145043: "HttpServerProvider.java:81: warning - @code("httpServerProvider") is an unknown tag" You see quite a few of these type of RuntimePermission links through out the core area. The intent is to link to RuntimePermission and show the appropriate String arg "target name". The simplest fix is to add a space after the @code tag. This generates the required javadoc, "RuntimePermission("httpServerProvider")", similar to how it appears in System.getenv [1]. src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java @@ -76,7 +76,7 @@ public abstract class HttpServerProvider * * @throws SecurityException * If a security manager has been installed and it denies - * {@link RuntimePermission}{@code("httpServerProvider")} + * {@link RuntimePermission}{@code ("httpServerProvider")} */ protected HttpServerProvider() { SecurityManager sm = System.getSecurityManager(); Thanks, -Chris. [1] http://download.java.net/jdk8/docs/api/java/lang/System.html#getenv%28java.…

1 0

hg: jdk8/tl/jdk: 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc.
by stuart.marks＠oracle.com 13 Feb '12

13 Feb '12

Changeset: 445ada5e6b4a Author: smarks Date: 2012-02-12 21:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Reviewed-by: alanb, chegar, lancea, smarks Contributed-by: Mani Sarkar <sadhak001(a)gmail.com>, Michael Barker <mikeb01(a)gmail.com>, Carl Jokl <carl.jokl(a)gmail.com>, Dinuk Weerasinghe <dinuksw(a)yahoo.com>, Markus Stoy <markus.stoy(a)timgroup.com>, Tom Anderson <tom.anderson(a)timgroup.com> ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java

1 0

hg: jdk8/tl/langtools: 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests
by jonathan.gibbons＠oracle.com 13 Feb '12

13 Feb '12

Changeset: cd5ca700da4c Author: jjg Date: 2012-02-12 16:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd5ca700da4c 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests Reviewed-by: jjg Contributed-by: jan.valenta(a)oracle.com ! make/build.xml

1 0

Easy-to-fix javadoc warning
by Jonathan Gibbons 12 Feb '12

12 Feb '12

Someone in the core-libs team should look at fixing this trivial javadoc warning. The replacement should presumably be {@code httpServerProvider} -- Jon # Packages (httpserver.packages): # com.sun.net.httpserver # com.sun.net.httpserver.spi /opt/jdk/1.7.0/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx612m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javadoc.jar:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javac.jar:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/doclets.jar" -jar /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javadoc.jar -bootclasspath /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/classes -d /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/docs/jre/api/net/httpserver/spec \ @/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/tmp/docs/doctmp/httpserver.options @/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/tmp/docs/doctmp/httpserver.packages *../../src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java:81: warning - @code("httpServerProvider") is an unknown tag.* 1 warning

1 0