April 2011 - core-libs-dev

hg: jdk7/tl/jdk: 7039369: Limit range of strictfp in FloatingDecimal
by joe.darcy＠oracle.com 26 Apr '11

26 Apr '11

Changeset: 147da2c8b749 Author: darcy Date: 2011-04-26 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/147da2c8b749 7039369: Limit range of strictfp in FloatingDecimal Summary: Additional reviews by sergey.kuksenko(a)oracle.com Reviewed-by: alanb ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! test/java/lang/Double/ParseDouble.java

1 0

hg: jdk7/tl/jdk: 7029383: Refresh of non-client demos
by nils.loodin＠oracle.com 26 Apr '11

26 Apr '11

Changeset: 8b36b1c4bb7f Author: nloodin Date: 2011-04-26 12:49 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b36b1c4bb7f 7029383: Refresh of non-client demos Reviewed-by: mchung, ohair ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java

1 0

hg: jdk7/tl/langtools: 7038363: cast from object to primitive should be for source >= 1.7
by jonathan.gibbons＠oracle.com 25 Apr '11

25 Apr '11

Changeset: 4c5f13798b8d Author: jjg Date: 2011-04-25 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4c5f13798b8d 7038363: cast from object to primitive should be for source >= 1.7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/types/CastObjectToPrimitiveTest.java + test/tools/javac/types/CastObjectToPrimitiveTest.out

1 0

hg: jdk7/tl/langtools: 7039019: test cannot run standalone
by jonathan.gibbons＠oracle.com 25 Apr '11

25 Apr '11

Changeset: fb84cfca28a1 Author: jjg Date: 2011-04-25 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fb84cfca28a1 7039019: test cannot run standalone Reviewed-by: dlsmith ! test/tools/javac/processing/model/TestSymtabItems.java

1 0

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

25 Apr '11

Xueming, the docs look good. On the name of the flag, I have no strong feelings one way or the other. Perhaps between UNICODE_PROPERTIES and UNICODE_CLASSES, I would prefer the second one. The first makes me think of the regular properties like \p{Script=Greek} from RL1.2, not the compat properties from RL1.2a like \w and \s. (I realize that the POSIX-compat stuff overlaps a bit.) One thing you might want to take a look at longer term is whether all 11 properties listed in RL1.2 will be accessible. I don't know whether you have methods in Character for #7 and #8 below; I seem to recall seeing one but not the other. RL1.2 Properties To meet this requirement, an implementation shall provide at least a minimal list of properties, consisting of the following: yes 1 General_Category yes 2 Script yes 3 Alphabetic yes 4 Uppercase yes 5 Lowercase yes 6 White_Space ? 7 Noncharacter_Code_Point ? 8 Default_Ignorable_Code_Point ? 9 ANY yes 10 ASCII ? 11 ASSIGNED RL1.2a Compatibility Properties To meet this requirement, an implementation shall provide the properties listed in Annex C. Compatibility Properties, with the property values as listed there. Such an implementation shall document whether it is using the Standard Recommendation or POSIX-compatible properties. Other things... I've thought a bit about whether it's worth pointing out that \x{h..h.} is the *only* way to (currently?) get non-BMP code points into a bracketed character class, like for example [\x{1D400}-\x{1D419}] to mean MATHEMATICAL BOLD CAPITAL A through MATHEMATICAL BOLD CAPITAL Z. Reasons for not mentioning it include how rarely (I imagine) that users come across it, and also because this is one of those rare places in Java where you can't treat UTF-16 code units separately and get the same results. This matters for interpolation, because you can never build up a character class by using [ ] to surround the two different 16-bit char units that non-BMP codepoints turn into. You always have to use the indirect \x{h..h} instead. This is rather non-obvious. However, after consideration I think it probably not worth risking confusing people by talking about it. I'm just very glad it can now be done. Having to figure out pieces of UTF-16 is no fun. Once the current effort is done and you've had a well-deserved rest, I know you were thinking about \N{NAME} and \X for a future version of the JDK. Both are important, although for quite different reasons. \N{NAME} is important for helping make regex code more maintainable by being self-documenting, since having to putting raw "magic" numbers instead of symbolic names in code is always bad. You'll certainly want to somehow make that available for Strings, too; not sure how to do that. The regex string escapes and the Java String escapes have already diverged, and I don't know how that happened. For example, the rules for octal escapes differ, and the regex engine supports things that Java proper does not; The "\cA" style comes to mind, but I think there are a few others, too. And now there is "\x{h..h}" too; pity Strings don't know that one. \X is important because you really do need access to graphemes. Otherwise it is very difficult to write the equivalent of (?:(?=[aeiou])\X), which assuming NFD, will match a grapheme that start with one of those five letters. More importantly, you have to be able to chunk text by graphemes, and you need to do this even if you don't someday make a way to tie \b to the fancier sense like the ICU (?w) UREGEX_UWORD flag provides. Getting grapheme clusters right is harder than it might appear. A careful reading of UAX#29 is important. There are two kinds of grapheme clusters, either legacy or extended. The extended version is tricky to get right, especially when you don't have access to all the syllable type properties. One problem with the legacy version is that it breaks up things that it shouldn't. We switched to the extended version for the 5.12 release of Perl, as this shows: $ perl5.10.0 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' 0 $ perl5.12.3 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' 1 Which is the way it really needs to be. For the legacy sense, you can always still code that one up more explicitly: $ perl5.12.3 -le 'print "\r\n" =~ /\A\p{Grapheme_Base}\p{Grapheme_Extend}*\z/ ? 1 : 0' 0 But I don't think people often want that version; extended is much better. Giving Java access to the properties needed for either version of grapheme clusters may be a good time to reconsider whether you might wish to redesign how you check whether a code point has any particular Unicode property. There are of course performance issues, but also because the current mechanism does not seem easily extended to support the full complement of Unicode properties (which is a new Level-2 RL). So if you are going to widen those again so you can have the properties at your fingertips that you need to support grapheme clusters, it might be worth thinking whether to refactor now or not. Performance and the size of tables will someday become an issue, if not now. I do know the Unicode docs mention this concern; I also know that we have people rethinking how Perl grants access to properties, because even though we do give you all of them, it could be done more tidily. I haven't thought much about what the non-regex interface to graphemes and such should look like. Besides the ICU stuff, something you might want to take a look at, just to see the sorts of things others are doing in the non-regex grapheme arena, is these two classes: http://search.cpan.org/perldoc?Unicode::GCString http://search.cpan.org/perldoc?Unicode::LineBreak It's Spartan, but it will give you an idea. I couldn't (well, wouldn't *want* to) do East Asian text segmentation without those, which is something I've done a bit of lately. Like all the good 3rd-party Unicode modules in Perl, those two come from Asia. They're often the driving force behind progress in Unicode support. With all those complicated scripts, you can certainly see why, too. Hope this helps! --tom

2 1

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

24 Apr '11

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> To: Tom Christiansen <tchrist(a)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/ j.u.regex.Pattern API: http://cr.openjdk.java.net/~sherman/7039066/Pattern.html Specdiff: http://cr.openjdk.java.net/~sherman/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> 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

1 1

Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties
by Xueming Shen 23 Apr '11

23 Apr '11

Hi This proposal tries to address (1) j.u.regex does not meet Unicode regex's Simple Word Boundaries [1] requirement as Tom pointed out in his email on i18n-dev list [2]. Basically we have 3 problems here. a. ju.regex word boundary construct \b and \B uses Unicode \p{letter} + \p{digit} as the "word" definition when the standard requires the true Unicode \p{Alphabetic} property be used instead. It also neglects two of the specifically required characters: U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER (or the "word" could be \p{alphabetic} + \p{gc=Mark} + \p{digit + \p{gc=Connector_Punctuation}, if follow Annex C). b. j.u.regex's word construct \w and \W are ASCII only version c. It breaks the historical connection between word characters and word boundaries (because of a) and b). For example "élève" is NOT matched by the \b\w+\b pattern) (2) j.u.regex does not meet Unicode regex's Properties requirement [3][5][6][7]. Th main issues are a. Alphabetic: totally missing from the platform, not only regex b. Lowercase, Uppercase and White_Space: Java implementation (via \p{javaMethod} is different compared to Unicode Standard definition. c. j.u.regex's POSIX character classes are ASCII only, when standard has an Unicode version defined at tr#18 Annex C [3] As the solution, I propose to (1) add a flag UNICODE_UNICODE to a) flip the ASCII only predefined character classes (\b \B \w \W \d \D \s \S) and POSIX character classes (\p{alpha}, \p{lower}, \{upper}...) to Unicode version b) enable the UNICODE_CASE (anything Unicode) While ideally we would like to just evolve/upgrade the Java regex from the aged "ascii-only" to unicode (maybe add a OLD_ASCII_ONLY_POSIX as a fallback:-)), like what Perl did. But given the Java's "compatibility" spirit (and the performance concern as well), this is unlikely to happen. (2) add \p{IsBinaryProperty} to explicitly support some important Unicode binary properties, such as \p{IsAlphabetic}, \p{IsIdeographic}, \p{IsPunctuation}...with this j.u.regex can easily access some properties that are either not provided by j.l.Character directly or j.l.Character has a different version (for example the White_Space). (The missing alphabetic, different uppercase/lowercase issue has been/is being addressed at Cr#7037261 [4], any reviewer?) The webrev is at http://cr.openjdk.java.net/~sherman/7039066/webrev/ The corresponding updated api j.u.regex.Pattern API doc is at http://cr.openjdk.java.net/~sherman/7039066/Pattern.html Specdiff result is at http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html I will file the CCC request if the API change proposal in webrev is approved. This is coming in very late so it is possible that it may be held back until Java 8, if it can not make the cutoff for jdk7. -Sherman [1] http://www.unicode.org/reports/tr18/#Simple_Word_Boundaries [2] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000256.html [3] http://www.unicode.org/reports/tr18/#Compatibility_Properties [4] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000370.html [5] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000249.html [6] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000253.html [7] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000254.html

3 3

hg: jdk7/tl/jdk: 6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM
by vincent.x.ryan＠oracle.com 22 Apr '11

22 Apr '11

Changeset: d64f9348c7ca Author: vinnie Date: 2011-04-22 17:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d64f9348c7ca 6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM Reviewed-by: mullan ! make/java/security/Makefile ! make/sun/security/Makefile ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/KeytoolChangeAlias.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh

1 0

hg: jdk7/tl/jdk: 3 new changesets
by keith.mcguigan＠oracle.com 22 Apr '11

22 Apr '11

Changeset: 7cd61feb3ec6 Author: kamg Date: 2011-04-15 10:17 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cd61feb3ec6 6519228: JDWP Spec: need references at capability canRequestMonitorEvents for JDWP 1.6 Monitor* events Summary: Add descriptions in event type table Reviewed-by: ohair, jjh, acorn, dcubed ! make/jpda/jdwp/jdwp.spec Changeset: e56922f50d1c Author: kamg Date: 2011-04-22 04:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e56922f50d1c Merge Changeset: 9cc0045191ed Author: kamg Date: 2011-04-22 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cc0045191ed Merge

1 0

hg: jdk7/tl/jdk: 7038885: Improved bulk operation disclaimers for concurrent collections
by chris.hegarty＠oracle.com 22 Apr '11

22 Apr '11

Changeset: 7c1cdb9c81a6 Author: dl Date: 2011-04-22 16:33 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c1cdb9c81a6 7038885: Improved bulk operation disclaimers for concurrent collections Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java

1 0