April 2011 - core-libs-dev

hg: jdk7/tl/langtools: 7028815: Missing styles for some bulleted items in the new stylesheet
by bhavesh.patel＠sun.com 28 Apr '11

28 Apr '11

Changeset: 5c81ba0eddff Author: bpatel Date: 2011-04-27 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5c81ba0eddff 7028815: Missing styles for some bulleted items in the new stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java

1 0

hg: jdk7/tl/langtools: 7039822: Project Coin: add explicit tests for the lub of an exception parameter
by joe.darcy＠oracle.com 28 Apr '11

28 Apr '11

Changeset: a8f5cad1e6bb Author: darcy Date: 2011-04-27 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a8f5cad1e6bb 7039822: Project Coin: add explicit tests for the lub of an exception parameter Reviewed-by: mcimadamore, jjg + test/tools/javac/multicatch/Neg07.java + test/tools/javac/multicatch/Neg07.out + test/tools/javac/multicatch/Pos10.java

1 0

hg: jdk7/tl/jdk: 2 new changesets
by vincent.x.ryan＠oracle.com 27 Apr '11

27 Apr '11

Changeset: 5a4e2a734f1d Author: vinnie Date: 2011-04-27 20:21 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a4e2a734f1d 6753664: Support SHA256 (and higher) in SunMSCAPI Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/windows/native/sun/security/mscapi/security.cpp + test/sun/security/mscapi/SignUsingSHA2withRSA.java + test/sun/security/mscapi/SignUsingSHA2withRSA.sh Changeset: 7c109d060365 Author: vinnie Date: 2011-04-27 20:24 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c109d060365 Merge

1 0

Review request for 7038565, for a findbugs warning for BatchUpdateException
by Lance Andersen - Oracle 27 Apr '11

27 Apr '11

Hi Folks, I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ Have a great weekend! Regards, lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

5 18

Review : 6546713: Link optional in Collection exception documentation to explanation
by Mike Duigou 27 Apr '11

27 Apr '11

Hello All; Another collections javadoc review request. This change links the "(optional)" notes in on various Collection methods to text which explains why they are not thrown by all collections. I have not applied the change to java.util.concurrent package javadoc. I will leave the JSR 166 maintainers. http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/ Thanks, Mike

5 6

Code review request for 7026898 DriverManager to now use CopyOnWriteArrayList
by Lance Andersen - Oracle 27 Apr '11

27 Apr '11

Hi, I have posted the diffs to DriverManager for review at http://cr.openjdk.java.net/~lancea/7026898/. This change utilizes CopyOnWriteArrayList instead of the Vectors previously used. Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com Oracle is committed to developing practices and products that help protect the environment

7 10

Re: <i18n dev> Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties
by Xueming Shen 27 Apr '11

27 Apr '11

Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. -Sherman On 4/24/2011 9:00 PM, Mark Davis ☕ wrote: > There are pluses and minuses to any of them: UNICODE_SPEC, > UNICODE_PROPERTY, UNICODE_CLASS, UNICODE_PROPERTIES, > or UNICODE_CLASSES, although any would work in a pinch. > > I'd favor a bit the singular over the plural, given the usage. > > The term 'class' is not used much in Unicode, just for two properties > (see below). So someone could possibly think it just meant those two > properties, and it could cause a bit of confusion with 'class' meaning > OO. So for that reason I don't think CLASS(ES) would be optimal. > bc ; Bidi_Class > ccc ; Canonical_Combining_Class > http://unicode.org/Public/UNIDATA/PropertyAliases.txt > > Mark > > /— Il meglio è l’inimico del bene —/ > > > On Sun, Apr 24, 2011 at 11:22, Xueming Shen <xueming.shen(a)oracle.com > <mailto:xueming.shen@oracle.com>> wrote: > > > Two more names, UNICODE_PROPERTIES and UNICODE_CLASSES, are suggested. > > any opinion? > > -Sherman > > > On 4/23/2011 6:50 PM, Xueming Shen wrote: >> Forwarding...forgot to include the list. >> >> -------- Original Message -------- >> Subject: Re: Codereview Request: 7039066 j.u.rgex does not match >> TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties >> Date: Sat, 23 Apr 2011 17:53:42 -0700 >> From: Xueming Shen <xueming.shen(a)oracle.com> >> <mailto:xueming.shen@oracle.com> >> To: Tom Christiansen <tchrist(a)perl.com> <mailto:tchrist@perl.com> >> >> >> >> Mark, Tom, >> >> I agree with Mark that UNICODE_SPEC is a better name than >> UNICODE_CHARSET. We will have to deal with >> the "compatibility" issue Tom mentioned anyway anyway should Java go >> higher level of Unicode Regex support >> someday. New option/flag will have to be introduced to let the developer >> to have the choice, just like what we >> are trying to do with the ASCII only or Unicode version for those classes. >> >> I also agree we should have an embedded flag. was thinking we can add it >> later, for example the JDK8, if we >> can get this one in jdk7, but the Pattern usage in String class is >> persuasive. >> >> The webrev, specdiff and Pattern doc have been updated to use >> UNICODE_SPEC as the flag and (?U) as the >> embedded flag. It might be a little confused, compared to we use (?u) >> for UNICODE_CASE, but feel it might >> feel "nature" to have uppercase "U" for broader Unicode support. >> >> The webrev is at >> http://cr.openjdk.java.net/~sherman/7039066/webrev/ <http://cr.openjdk.java.net/%7Esherman/7039066/webrev/> >> >> j.u.regex.Pattern API: >> http://cr.openjdk.java.net/~sherman/7039066/Pattern.html <http://cr.openjdk.java.net/%7Esherman/7039066/Pattern.html> >> >> Specdiff: >> http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html <http://cr.openjdk.java.net/%7Esherman/7039066/specdiff/diff.html> >> >> Tom, it would be appreciated if you can at lease give the doc update a >> quick scan to see if I miss anything. >> And thanks for the suggestions for the Perl related doc update, I will >> need go through it a little later and address >> it in a separate CR. >> >> Thanks, >> -Sherman >> >> >> On 4/23/2011 10:48 AM, Tom Christiansen wrote: >> > Mark Davis ☕<mark(a)macchiato.com> <mailto:mark@macchiato.com> wrote >> > on Sat, 23 Apr 2011 09:09:55 PDT: >> > >> >> The changes sound good. >> > They sure do, don't they? I'm quite happy about this. I think it is more >> > important to get this in the queue than that it (necessarily) be done for >> > JDK7. That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut >> > makes it attractive now. But if not now, then soon is good enough. >> > >> >> The flag UNICODE_CHARSET will be misleading, since >> >> all of Java uses the Unicode Charset (= encoding). How about: >> >> UNICODE_SPEC >> >> or something that gives that flavor. >> > I hadn't thought of that, but I do see what you mean. The idea is >> > that the semantics of \w etc change to match the Unicode spec in tr18. >> > >> > I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too >> > broad a brush. What then happens when, as I imagine it someday shall, >> > Java gets full support for RL2.3 boundaries, the way with ICU one uses >> > or (?w) or UREGEX_UWORD for? >> > >> > Wouldn't calling something UNICODE_SPEC be too broad? Or should >> > UNICODE_SPEC automatically include not just existing Unicode flags >> > like UNICODE_CASE, but also any UREGEX_UWORD that comes along? >> > If it does, you have back-compat issue, and if it doesn't, you >> > have a misnaming issue. Seems like a bit of a Catch22. >> > >> > The reason I'd suggested UNICODE_CHARSET was because of my own background >> > with the names we use for this within the Perl regex source code (which is >> > itself written in C). I believe that Java doesn't have the same situation >> > as gave rise to it in Perl, and perhaps something else would be clearer. >> > >> > Here's some background for why we felt we had to go that way. To control >> > the behavior of \w and such, when a regex is compiled, a compiled Perl >> > gets exactly one of these states: >> > >> > REGEX_UNICODE_CHARSET >> > REGEX_LOCALE_CHARSET >> > REGEX_ASCII_RESTRICTED_CHARSET >> > REGEX_DEPENDS_CHARSET >> > >> > That state it normally inherits from the surrounding lexical scope, >> > although this can be overridden with /u and /a, or (?u) and (?a), >> > either within the pattern or as a separate pattern-compilation flag. >> > >> > REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the >> > full RL1.2a definitions. Because Perl always does Unicode casemapping -- >> > and full casemapping, too, not just simple -- we didn't need (?u) for what >> > Java uses it for, which is just as an extra flavor of (?i); it doesn't >> > do all that much. >> > >> > (BTW, the old default is *not* some sort of non-Unicode charset >> > semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for >> > code points> 255 and "maybe" so in the 128-255 range.) >> > >> > What we did certainly isn't perfect, but it allows for both backwards >> > compat and future growth. This was because people want(ed) to be able to >> > use regexes on both byte arrays yet also on character strings. Me, I think >> > it's nuts to support this at all, that if you want an input stream in (say) >> > CP1251 or ISO 8859-2, that you simply set that stream's encoding and be >> > done with it: everything turns into characters internally. But there's old >> > byte and locale code out there whose semantics we are loth to change out >> > from under people. Java has the same kind of issue. >> > >> > The reason we ever support anything else is because we got (IMHO nasty) >> > POSIX locales before we got Unicode support, which didn't happen till >> > toward the end of the last millennium. So we're stuck supporting code >> > well more than a decade old, perhaps indefinitely. It's messy, but it >> > is very hard to do anything about that. I think Java shares in that >> > perspective. >> > >> > This corresponds, I think, to Java needing to support pre-Unicode >> > regex semantics on \w and related escapes. If they had started out >> > with it always means the real thing the way ICU did, they wouldn't >> > need both. >> > >> > I wish there were a pragma to control this on a per-lexical-scope basis, >> > but I'm don't enough about the Java compilers internals to begin to know >> > how to go about implementing some thing like that, even as a >> > -XX:+UseUnicodeSemantics CLI switch for that compilation unit. >> > >> > One reason you want this is because the Java String class has these >> > "convenience" methods like matches, replaceAll, etc, that take regexes >> > but do not provide an API that admits Pattern compile flags. If there >> > is no way to embed a (?U) directive or some such, nor any way to pass >> > in a Pattern.UNICODE_something flag. The Java String API could also >> > be broadened through method signature overloading, but for now, you >> > can't do that. >> > >> > No matter what the UNICODE_something gets called, I think there needs to be >> > a corresponding embeddable (?X)-style flag as well. Even if String were >> > broadened, you'd want people to be able to specify *within the regex* that >> > that regex should have full Unicode semantics. After all, they might read >> > the pattern in from a file. That's why (most) Pattern.compile flags need >> > to be able to embedded, too. But you knew that already. :) >> > >> > --tom >> > >

2 4

hg: jdk7/tl/jdk: 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc
by alan.bateman＠oracle.com 27 Apr '11

27 Apr '11

Changeset: a0dde3ff1dfd Author: alanb Date: 2011-04-27 13:46 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0dde3ff1dfd 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc Reviewed-by: dholmes ! make/java/nio/mapfile-linux ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c

1 0

hg: jdk7/tl/jdk: 6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?)
by weijun.wang＠oracle.com 27 Apr '11

27 Apr '11

Changeset: 0e0db3421e8f Author: weijun Date: 2011-04-27 17:11 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e0db3421e8f 6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?) Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java

1 0

Request for review: Optimize common-case UTF8 path for native ZipFile.getEntry calls
by Neil Richards 26 Apr '11

26 Apr '11

Hi, Changeset 1aaeb8fbe705 [1] implemented a good set of enhancements, to allow the zip code to properly support zip files containing names and comments either encoded in non-UTF-8 codesets, or which contain supplementary characters. This support is achieved by doing the character conversion in Java code (using the code in ZipCoder.getBytes()), then feeding the resulting byte[] through to native code. This approach is more costly, both in terms of memory allocation and amount of data copying, than the preceding one, which did the conversion directly into a native byte[] using JNI's 'GetStringUTFRegion', which assumes a codeset of "modified UTF-8". The conversion performed for "modified UTF-8" is the same as that for standard UTF-8 for all codepoints except those for supplementary characters or for the character '\u0000' [2]. As the "common-case" is likely to be dealing with zip files with UTF-8 encoded names and comments containing neither supplementary characters nor '\u0000', the increase in cost of the conversion in this case is unfortunate. By introducing an extra check to determine if a UTF-8 encoded string may be safely converted using "modified UTF-8" (ie. to check that it has not any supplementary codepoints or '\u0000' in it), and using the aforementioned JNI routine to do the conversion if the check succeeds, I've noticed a decent performance improvement can be achieved by catering for this common-case. This benefit is particularly significant for applications which do a lot of rummaging around in zip files, or those involving lots of jar files and/or jar files with lots of entries in them. Please find below a changeset which implements the check I describe above ("isSafeToUseModifiedUTF8"), and uses it to choose whether to call a new modified-UTF8-specific variant of the native getEntry() method ("getEntryByModifiedUTF8"), which makes use of the JNI 'GetStringUTFRegion' method for the conversion. Please let me know if you have and comments, criticism of suggestions on this, Thanks, Neil [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1aaeb8fbe705 [2] http://java.sun.com/developer/technicalArticles/Intl/Supplementary/#Modifie… -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards <neil.richards(a)ngmr.net>, <neil_richards(a)uk.ibm.com> # Date 1303394058 -3600 # Branch ojdk-121 # Node ID e5c8d8da677bce826b6bafc379d67c5d7775e7f6 # Parent 60d3d55dcc9c31a30ced9caa6ef5c0dcd7db031d Summary: Optimize name conversion when it is safe to use modified UTF-8 (common case) Contributed-by: <neil.richards(a)ngmr.net> diff -r 60d3d55dcc9c -r e5c8d8da677b make/java/zip/mapfile-vers --- a/make/java/zip/mapfile-vers Wed Apr 13 16:56:16 2011 -0700 +++ b/make/java/zip/mapfile-vers Thu Apr 21 14:54:18 2011 +0100 @@ -54,6 +54,7 @@ Java_java_util_zip_ZipFile_getCommentBytes; Java_java_util_zip_ZipFile_freeEntry; Java_java_util_zip_ZipFile_getEntry; + Java_java_util_zip_ZipFile_getEntryByModifiedUTF8; Java_java_util_zip_ZipFile_getEntryBytes; Java_java_util_zip_ZipFile_getEntryCrc; Java_java_util_zip_ZipFile_getEntryCSize; diff -r 60d3d55dcc9c -r e5c8d8da677b src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Wed Apr 13 16:56:16 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Thu Apr 21 14:54:18 2011 +0100 @@ -283,6 +283,24 @@ } } + private static boolean isSafeToUseModifiedUTF8(String s) { + final int length = s.length(); + + int codepoint; + // It's okay to step through the string one char at a time, as any + // codepoint encoded to more than one char will be greater or equal to + // Character.MIN_SUPPLEMENTARY_CODE_POINT, and so will have caused this + // method to return 'false'. + for (int i = 0; i < length; i++) { + codepoint = s.codePointAt(i); + if ((0 == codepoint) || + (codepoint >= Character.MIN_SUPPLEMENTARY_CODE_POINT)) { + return false; + } + } + return true; + } + /** * Returns the zip file entry for the specified name, or null * if not found. @@ -298,7 +316,13 @@ long jzentry = 0; synchronized (this) { ensureOpen(); - jzentry = getEntry(jzfile, zc.getBytes(name), true); + // Optimize if 'name' can be converted safely using + // "modified UTF-8" (common case) + if (zc.isUTF8() && isSafeToUseModifiedUTF8(name)) { + jzentry = getEntryByModifiedUTF8(jzfile, name, true); + } else { + jzentry = getEntry(jzfile, zc.getBytes(name), true); + } if (jzentry != 0) { ZipEntry ze = getZipEntry(name, jzentry); freeEntry(jzfile, jzentry); @@ -308,6 +332,9 @@ return null; } + private static native long getEntryByModifiedUTF8(long jzfile, String name, + boolean addSlash); + private static native long getEntry(long jzfile, byte[] name, boolean addSlash); @@ -339,8 +366,15 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); - if (!zc.isUTF8() && (entry.flag & EFS) != 0) { - jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); + if (zc.isUTF8() || ((entry.flag & EFS) != 0)) { + // Optimize if 'entry.name' can be converted safely using + // "modified UTF-8" (common case) + if (isSafeToUseModifiedUTF8(entry.name)) { + jzentry = getEntryByModifiedUTF8(jzfile, entry.name, false); + } else { + jzentry = + getEntry(jzfile, zc.getBytesUTF8(entry.name), false); + } } else { jzentry = getEntry(jzfile, zc.getBytes(entry.name), false); } diff -r 60d3d55dcc9c -r e5c8d8da677b src/share/native/java/util/zip/ZipFile.c --- a/src/share/native/java/util/zip/ZipFile.c Wed Apr 13 16:56:16 2011 -0700 +++ b/src/share/native/java/util/zip/ZipFile.c Thu Apr 21 14:54:18 2011 +0100 @@ -142,11 +142,12 @@ ZIP_Close(jlong_to_ptr(zfile)); } +#define MAXNAME 1024 + JNIEXPORT jlong JNICALL Java_java_util_zip_ZipFile_getEntry(JNIEnv *env, jclass cls, jlong zfile, jbyteArray name, jboolean addSlash) { -#define MAXNAME 1024 jzfile *zip = jlong_to_ptr(zfile); jsize ulen = (*env)->GetArrayLength(env, name); char buf[MAXNAME+2], *path; @@ -170,6 +171,40 @@ } if (path != buf) { free(path); + path = NULL; + } + return ptr_to_jlong(ze); +} + +JNIEXPORT jlong JNICALL +Java_java_util_zip_ZipFile_getEntryByModifiedUTF8(JNIEnv *env, jclass cls, + jlong zfile, jstring name, jboolean addSlash) +{ + jzfile *zip = jlong_to_ptr(zfile); + jsize slen = (*env)->GetStringLength(env, name); + jsize ulen = (*env)->GetStringUTFLength(env, name); + char buf[MAXNAME+2], *path; + jzentry *ze; + + if (ulen > MAXNAME) { + path = malloc(ulen + 2); + if (path == 0) { + JNU_ThrowOutOfMemoryError(env, 0); + return 0; + } + } else { + path = buf; + } + (*env)->GetStringUTFRegion(env, name, 0, slen, path); + path[ulen] = '\0'; + if (addSlash == JNI_FALSE) { + ze = ZIP_GetEntry(zip, path, 0); + } else { + ze = ZIP_GetEntry(zip, path, (jint)ulen); + } + if (path != buf) { + free(path); + path = NULL; } return ptr_to_jlong(ze); }

2 1