From dougfelt at google.com Mon Mar 2 13:12:23 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Mon, 02 Mar 2009 21:12:23 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 123 new changesets Message-ID: <20090302213614.C2E78E5B5@hg.openjdk.java.net> Changeset: 527b426497a2 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/527b426497a2 Added tag jdk7-b44 for changeset d8eb2738db6b ! .hgtags Changeset: 997c6403bf2e Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/997c6403bf2e Added tag jdk7-b45 for changeset 527b426497a2 ! .hgtags Changeset: 13d7e2477737 Author: sherman Date: 2009-01-13 09:21 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/13d7e2477737 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream Summary: To use ZipFile for jar "t" and "x" to boost performance Reviewed-by: martin, alanb ! src/share/classes/sun/tools/jar/Main.java Changeset: 8c1c6e11204b Author: chegar Date: 2009-01-14 17:17 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8c1c6e11204b 6755782: It is not clear how DatagramSocket deals with broadcast enabling/disabling Reviewed-by: jccollet ! src/share/classes/java/net/DatagramSocket.java Changeset: 7f6969c09075 Author: darcy Date: 2009-01-14 16:23 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7f6969c09075 6792545: Typo in java.util.Collection JavaDoc 6655123: Incorrect ref to The Art of Computer Programming in doc for java.util.Random Summary: Fix a pair of typos. Reviewed-by: jjg ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Random.java Changeset: 9260d9bd0843 Author: weijun Date: 2009-01-19 18:49 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/9260d9bd0843 6793475: krb5.ini not found on some Windows Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/windows/native/sun/security/krb5/WindowsDirectory.c Changeset: 1f751a9f7052 Author: mchung Date: 2009-01-20 13:02 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/1f751a9f7052 6793429: Use compiled properties instead of plain properties for resource file Summary: Rename the variables in Resources.gmk to make compiled properties more explicit Reviewed-by: naoto, yhuang ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/common/internal/Resources.gmk ! make/sun/launcher/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/serialver/Makefile Changeset: 42f8dea1b865 Author: mchung Date: 2009-01-20 13:04 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/42f8dea1b865 6769976: (fc) FileChannelImpl.isAMappedBufferField not used Summary: Remove the FileChannelImpl.isAMappedBufferField field Reviewed-by: alanb ! src/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: 7fa0a7a3c080 Author: mchung Date: 2009-01-20 16:16 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7fa0a7a3c080 Merge Changeset: 63f8707112be Author: sherman Date: 2009-01-22 20:29 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/63f8707112be 6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima Summary: Correct the wrong calculation of "precision" in certain circumstances. Reviewed-by: darcy, alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java ! test/java/util/Formatter/genBasic.sh Changeset: cb641d17bbb3 Author: darcy Date: 2009-01-23 10:37 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/cb641d17bbb3 6604864: Double.valueOf(String) does not specify behaviour for overflow and underflow Reviewed-by: emcmanus ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java Changeset: 175b6adf65b3 Author: tbell Date: 2009-01-24 16:35 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/175b6adf65b3 Merge Changeset: f3ad2ee4600b Author: darcy Date: 2009-01-26 19:49 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f3ad2ee4600b 6601457: Move wrapper class tests from closed to open 6601458: Move java.math tests from closed to open 6740185: Move java/lang/annotations tests to open 6759433: Move Math and StrictMath regression tests from closed to open Summary: Move some more regression tests to the open Reviewed-by: jjg + test/java/lang/Boolean/Factory.java + test/java/lang/Boolean/GetBoolean.java + test/java/lang/Boolean/MakeBooleanComparable.java + test/java/lang/Boolean/ParseBoolean.java + test/java/lang/Byte/Decode.java + test/java/lang/Double/BitwiseConversion.java + test/java/lang/Double/Constants.java + test/java/lang/Double/Extrema.java + test/java/lang/Double/NaNInfinityParsing.java + test/java/lang/Double/ParseDouble.java + test/java/lang/Double/ParseHexFloatingPoint.java + test/java/lang/Double/ToHexString.java + test/java/lang/Float/BitwiseConversion.java + test/java/lang/Float/Constants.java + test/java/lang/Float/Extrema.java + test/java/lang/Float/NaNInfinityParsing.java + test/java/lang/Float/ParseFloat.java + test/java/lang/Integer/BitTwiddle.java + test/java/lang/Integer/Decode.java + test/java/lang/Integer/GetInteger.java + test/java/lang/Integer/ParsingTest.java + test/java/lang/Long/BitTwiddle.java + test/java/lang/Long/Decode.java + test/java/lang/Long/GetLong.java + test/java/lang/Long/ParsingTest.java + test/java/lang/Math/AbsPositiveZero.java + test/java/lang/Math/Atan2Tests.java + test/java/lang/Math/CubeRootTests.java + test/java/lang/Math/Expm1Tests.java + test/java/lang/Math/HyperbolicTests.java + test/java/lang/Math/HypotTests.java + test/java/lang/Math/IeeeRecommendedTests.java + test/java/lang/Math/Log10Tests.java + test/java/lang/Math/Log1pTests.java + test/java/lang/Math/MinMax.java + test/java/lang/Math/PowTests.java + test/java/lang/Math/Rint.java + test/java/lang/Math/TanTests.java + test/java/lang/Math/Tests.java + test/java/lang/Short/ByteSwap.java + test/java/lang/Short/Decode.java + test/java/lang/StrictMath/CubeRootTests.java + test/java/lang/StrictMath/Expm1Tests.java + test/java/lang/StrictMath/HyperbolicTests.java + test/java/lang/StrictMath/HypotTests.java + test/java/lang/StrictMath/Log10Tests.java + test/java/lang/StrictMath/Log1pTests.java + test/java/lang/StrictMath/Tests.java + test/java/lang/ToString.java + test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java + test/java/lang/annotation/Missing/A.java + test/java/lang/annotation/Missing/B.java + test/java/lang/annotation/Missing/C.java + test/java/lang/annotation/Missing/D.java + test/java/lang/annotation/Missing/Marker.java + test/java/lang/annotation/Missing/Missing.java + test/java/lang/annotation/Missing/MissingTest.java + test/java/lang/annotation/Missing/MissingWrapper.java + test/java/lang/annotation/PackageMain.java + test/java/lang/annotation/RecursiveAnnotation.java + test/java/lang/annotation/UnitTest.java + test/java/lang/annotation/loaderLeak/A.java + test/java/lang/annotation/loaderLeak/B.java + test/java/lang/annotation/loaderLeak/C.java + test/java/lang/annotation/loaderLeak/LoaderLeak.sh + test/java/lang/annotation/loaderLeak/Main.java + test/java/lang/annotation/package-info.java + test/java/math/BigDecimal/AddTests.java + test/java/math/BigDecimal/CompareToTests.java + test/java/math/BigDecimal/Constructor.java + test/java/math/BigDecimal/DivideTests.java + test/java/math/BigDecimal/FloatDoubleValueTests.java + test/java/math/BigDecimal/IntegralDivisionTests.java + test/java/math/BigDecimal/NegateTests.java + test/java/math/BigDecimal/PowTests.java + test/java/math/BigDecimal/RoundingTests.java + test/java/math/BigDecimal/ScaleByPowerOfTenTests.java + test/java/math/BigDecimal/SerializationTests.java + test/java/math/BigDecimal/StringConstructor.java + test/java/math/BigDecimal/StrippingZerosTest.java + test/java/math/BigDecimal/ToPlainStringTests.java + test/java/math/BigDecimal/ZeroScalingTests.java + test/java/math/BigInteger/BigIntegerTest.java + test/java/math/BigInteger/ModPow.java + test/java/math/BigInteger/ModPow65537.java + test/java/math/BigInteger/ModPowPowersof2.java + test/java/math/BigInteger/OperatorNpeTests.java + test/java/math/BigInteger/ProbablePrime.java + test/java/math/BigInteger/StringConstructor.java + test/java/math/BigInteger/UnicodeConstructor.java + test/java/math/RoundingMode/RoundingModeTests.java Changeset: 2113813eda62 Author: tbell Date: 2009-01-29 21:46 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2113813eda62 Merge Changeset: 443db0030323 Author: peytoia Date: 2008-10-02 15:54 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/443db0030323 6645263: (cal) Calendar throw java.lang.IllegalArgumentException: WEEK_OF_MONTH Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug6645263.java Changeset: 7f4488e9ba24 Author: peytoia Date: 2008-10-03 15:54 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7f4488e9ba24 6683975: [fmt-da] Regression: Java 6 returns English DateFormatPatterns for Thai locale Reviewed-by: okutsu ! src/share/classes/sun/text/resources/FormatData_th.java + test/java/text/Format/DateFormat/Bug6683975.java Changeset: f71879c0999f Author: naoto Date: 2008-10-06 17:16 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f71879c0999f 6706382: jdk/test/java/util/Locale/data/deflocale.sol10 has incorrect legal notice Reviewed-by: okutsu ! test/java/util/Locale/data/deflocale.sol10 Changeset: a9be64f0ad3e Author: peytoia Date: 2008-10-07 18:25 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/a9be64f0ad3e 6756569: (tz) Support tzdata2008g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica Changeset: 7560426ed283 Author: rkennke Date: 2008-10-15 15:55 +0200 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7560426ed283 6759311: RepaintManager casts Tookit to SunToolkit without instanceof check Summary: Check type of Toolkit before casting. Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 244f62312fec Author: peytoia Date: 2008-10-16 14:00 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/244f62312fec 6758988: (tz) Support tzdata2008h Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab Changeset: 8ea49fa4c2f7 Author: peytoia Date: 2008-10-17 13:34 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8ea49fa4c2f7 6759521: Move Bidi test programs from closed to open. Reviewed-by: okutsu + test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/BidiSurrogateTest.java Changeset: 3bc97f84a8aa Author: lana Date: 2008-10-17 15:01 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/3bc97f84a8aa Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/javavm/include/typedefs_md.h - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c - src/windows/javavm/include/typedefs_md.h Changeset: f67599e0ee33 Author: peytoia Date: 2008-10-30 13:12 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f67599e0ee33 6764308: (tz) Support tzdata2008i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f8461a705330 Author: rupashka Date: 2008-11-17 17:36 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f8461a705330 6771030: Code improvement and warnings removing from the com.sun.java.swing.plaf.gtk package Summary: Removed unnecessary castings and other warnings Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Changeset: 6c5781fc3818 Author: peytoia Date: 2008-11-18 13:58 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6c5781fc3818 6769873: Regression test java/text/Date/DateFormat/Bug6683975.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug6683975.java Changeset: bdfe33408ed8 Author: peytoia Date: 2008-11-18 15:59 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/bdfe33408ed8 6772646: Regression test java/text/Date/DateFormat/Bug4823811.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug4823811.java Changeset: 63e684c4ed2f Author: rupashka Date: 2008-11-25 16:42 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/63e684c4ed2f 6698013: JFileChooser can no longer navigate non-local file systems. Summary: ShellFolder is used only if possible Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java + test/javax/swing/JFileChooser/6698013/bug6698013.html + test/javax/swing/JFileChooser/6698013/bug6698013.java Changeset: be2b6b030a79 Author: rupashka Date: 2008-11-26 19:08 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/be2b6b030a79 6560349: REGRESSION :folder having ".lnk" in the name can not be opened by 5.0 and later versions Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 8b842701af50 Author: rupashka Date: 2008-11-26 19:38 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8b842701af50 6776856: Code with useShellFolder field shuold be simplify Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 5784f5dfe3ac Author: rupashka Date: 2008-11-27 17:55 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/5784f5dfe3ac 6776095: Code improvement and warnings removing from swing packages Reviewed-by: malenkov Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/undo/CompoundEdit.java Changeset: 50a9a4db3500 Author: malenkov Date: 2008-12-22 17:42 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/50a9a4db3500 4864117: RFE: Make XMLDecoder API more reusable Reviewed-by: peterz, loneid - src/share/classes/com/sun/beans/ObjectHandler.java + src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java + src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java + src/share/classes/com/sun/beans/decoder/ByteElementHandler.java + src/share/classes/com/sun/beans/decoder/CharElementHandler.java + src/share/classes/com/sun/beans/decoder/ClassElementHandler.java + src/share/classes/com/sun/beans/decoder/DocumentHandler.java + src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java + src/share/classes/com/sun/beans/decoder/ElementHandler.java + src/share/classes/com/sun/beans/decoder/FalseElementHandler.java + src/share/classes/com/sun/beans/decoder/FieldElementHandler.java + src/share/classes/com/sun/beans/decoder/FloatElementHandler.java + src/share/classes/com/sun/beans/decoder/IntElementHandler.java + src/share/classes/com/sun/beans/decoder/JavaElementHandler.java + src/share/classes/com/sun/beans/decoder/LongElementHandler.java + src/share/classes/com/sun/beans/decoder/MethodElementHandler.java + src/share/classes/com/sun/beans/decoder/NewElementHandler.java + src/share/classes/com/sun/beans/decoder/NullElementHandler.java + src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java + src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java + src/share/classes/com/sun/beans/decoder/ShortElementHandler.java + src/share/classes/com/sun/beans/decoder/StringElementHandler.java + src/share/classes/com/sun/beans/decoder/TrueElementHandler.java + src/share/classes/com/sun/beans/decoder/ValueObject.java + src/share/classes/com/sun/beans/decoder/ValueObjectImpl.java + src/share/classes/com/sun/beans/decoder/VarElementHandler.java + src/share/classes/com/sun/beans/decoder/VoidElementHandler.java + src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ClassFinder.java + src/share/classes/com/sun/beans/finder/ConstructorFinder.java + src/share/classes/com/sun/beans/finder/FieldFinder.java + src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/com/sun/beans/finder/PrimitiveTypeMap.java + src/share/classes/com/sun/beans/finder/PrimitiveWrapperMap.java + src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/java/beans/XMLDecoder/Test4864117.java ! test/java/beans/XMLDecoder/Test6341798.java + test/java/beans/XMLDecoder/spec/AbstractTest.java + test/java/beans/XMLDecoder/spec/TestArray.java + test/java/beans/XMLDecoder/spec/TestBoolean.java + test/java/beans/XMLDecoder/spec/TestByte.java + test/java/beans/XMLDecoder/spec/TestChar.java + test/java/beans/XMLDecoder/spec/TestClass.java + test/java/beans/XMLDecoder/spec/TestDouble.java + test/java/beans/XMLDecoder/spec/TestFalse.java + test/java/beans/XMLDecoder/spec/TestField.java + test/java/beans/XMLDecoder/spec/TestFloat.java + test/java/beans/XMLDecoder/spec/TestInt.java + test/java/beans/XMLDecoder/spec/TestJava.java + test/java/beans/XMLDecoder/spec/TestLong.java + test/java/beans/XMLDecoder/spec/TestMethod.java + test/java/beans/XMLDecoder/spec/TestNew.java + test/java/beans/XMLDecoder/spec/TestNull.java + test/java/beans/XMLDecoder/spec/TestObject.java + test/java/beans/XMLDecoder/spec/TestProperty.java + test/java/beans/XMLDecoder/spec/TestShort.java + test/java/beans/XMLDecoder/spec/TestString.java + test/java/beans/XMLDecoder/spec/TestTrue.java + test/java/beans/XMLDecoder/spec/TestVar.java Changeset: 2b8a0d8b5cbb Author: malenkov Date: 2008-12-25 20:43 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2b8a0d8b5cbb 6736248: EnumEditor bug. Class check incorrect Reviewed-by: rupashka, alexp ! src/share/classes/sun/beans/editors/EnumEditor.java + test/java/beans/PropertyEditor/TestEnumSubclass.java + test/java/beans/PropertyEditor/TestEnumSubclassJava.java + test/java/beans/PropertyEditor/TestEnumSubclassNull.java + test/java/beans/PropertyEditor/TestEnumSubclassValue.java Changeset: b06c29386f63 Author: amenkov Date: 2009-01-19 20:11 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b06c29386f63 6702956: OpenJDK: replace encumbered code (software synthesizer) 6717691: Update Gervill with post 1.0 fixes 6740210: Update Gervill with more post 1.0 fixes 6748247: Further update Gervill with still more post 1.0 fixes 6748251: Apply IcedTea midi sound patch 6758986: Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads Reviewed-by: ohair, darcy ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/javax/sound/Makefile - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java + src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java + src/share/classes/com/sun/media/sound/AudioFloatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatInputStream.java + src/share/classes/com/sun/media/sound/AudioSynthesizer.java + src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java + src/share/classes/com/sun/media/sound/DLSInfo.java + src/share/classes/com/sun/media/sound/DLSInstrument.java + src/share/classes/com/sun/media/sound/DLSModulator.java + src/share/classes/com/sun/media/sound/DLSRegion.java + src/share/classes/com/sun/media/sound/DLSSample.java + src/share/classes/com/sun/media/sound/DLSSampleLoop.java + src/share/classes/com/sun/media/sound/DLSSampleOptions.java + src/share/classes/com/sun/media/sound/DLSSoundbank.java + src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + src/share/classes/com/sun/media/sound/EmergencySoundbank.java + src/share/classes/com/sun/media/sound/FFT.java + src/share/classes/com/sun/media/sound/InvalidDataException.java + src/share/classes/com/sun/media/sound/InvalidFormatException.java + src/share/classes/com/sun/media/sound/JARSoundbankReader.java + src/share/classes/com/sun/media/sound/ModelAbstractChannelMixer.java + src/share/classes/com/sun/media/sound/ModelAbstractOscillator.java + src/share/classes/com/sun/media/sound/ModelByteBuffer.java + src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java + src/share/classes/com/sun/media/sound/ModelChannelMixer.java + src/share/classes/com/sun/media/sound/ModelConnectionBlock.java + src/share/classes/com/sun/media/sound/ModelDestination.java + src/share/classes/com/sun/media/sound/ModelDirectedPlayer.java + src/share/classes/com/sun/media/sound/ModelDirector.java + src/share/classes/com/sun/media/sound/ModelIdentifier.java + src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java + src/share/classes/com/sun/media/sound/ModelMappedInstrument.java + src/share/classes/com/sun/media/sound/ModelOscillator.java + src/share/classes/com/sun/media/sound/ModelOscillatorStream.java + src/share/classes/com/sun/media/sound/ModelPatch.java + src/share/classes/com/sun/media/sound/ModelPerformer.java + src/share/classes/com/sun/media/sound/ModelSource.java + src/share/classes/com/sun/media/sound/ModelStandardDirector.java + src/share/classes/com/sun/media/sound/ModelStandardTransform.java + src/share/classes/com/sun/media/sound/ModelTransform.java + src/share/classes/com/sun/media/sound/ModelWavetable.java ! src/share/classes/com/sun/media/sound/Platform.java + src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java + src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java + src/share/classes/com/sun/media/sound/RIFFReader.java + src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java + src/share/classes/com/sun/media/sound/SF2GlobalRegion.java + src/share/classes/com/sun/media/sound/SF2Instrument.java + src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java + src/share/classes/com/sun/media/sound/SF2Layer.java + src/share/classes/com/sun/media/sound/SF2LayerRegion.java + src/share/classes/com/sun/media/sound/SF2Modulator.java + src/share/classes/com/sun/media/sound/SF2Region.java + src/share/classes/com/sun/media/sound/SF2Sample.java + src/share/classes/com/sun/media/sound/SF2Soundbank.java + src/share/classes/com/sun/media/sound/SF2SoundbankReader.java + src/share/classes/com/sun/media/sound/SimpleInstrument.java + src/share/classes/com/sun/media/sound/SimpleSoundbank.java + src/share/classes/com/sun/media/sound/SoftAbstractResampler.java + src/share/classes/com/sun/media/sound/SoftAudioBuffer.java + src/share/classes/com/sun/media/sound/SoftAudioProcessor.java + src/share/classes/com/sun/media/sound/SoftAudioPusher.java + src/share/classes/com/sun/media/sound/SoftChannel.java + src/share/classes/com/sun/media/sound/SoftChannelProxy.java + src/share/classes/com/sun/media/sound/SoftChorus.java + src/share/classes/com/sun/media/sound/SoftControl.java + src/share/classes/com/sun/media/sound/SoftCubicResampler.java + src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java + src/share/classes/com/sun/media/sound/SoftFilter.java + src/share/classes/com/sun/media/sound/SoftInstrument.java + src/share/classes/com/sun/media/sound/SoftJitterCorrector.java + src/share/classes/com/sun/media/sound/SoftLanczosResampler.java + src/share/classes/com/sun/media/sound/SoftLimiter.java + src/share/classes/com/sun/media/sound/SoftLinearResampler.java + src/share/classes/com/sun/media/sound/SoftLinearResampler2.java + src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + src/share/classes/com/sun/media/sound/SoftMainMixer.java + src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/share/classes/com/sun/media/sound/SoftMixingClip.java + src/share/classes/com/sun/media/sound/SoftMixingDataLine.java + src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java + src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + src/share/classes/com/sun/media/sound/SoftPerformer.java + src/share/classes/com/sun/media/sound/SoftPointResampler.java + src/share/classes/com/sun/media/sound/SoftProcess.java + src/share/classes/com/sun/media/sound/SoftProvider.java + src/share/classes/com/sun/media/sound/SoftReceiver.java + src/share/classes/com/sun/media/sound/SoftResampler.java + src/share/classes/com/sun/media/sound/SoftResamplerStreamer.java + src/share/classes/com/sun/media/sound/SoftReverb.java + src/share/classes/com/sun/media/sound/SoftShortMessage.java + src/share/classes/com/sun/media/sound/SoftSincResampler.java + src/share/classes/com/sun/media/sound/SoftSynthesizer.java + src/share/classes/com/sun/media/sound/SoftTuning.java + src/share/classes/com/sun/media/sound/SoftVoice.java + src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiDeviceProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.SoundbankReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.AudioFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.MixerProvider - src/share/lib/audio/soundbank.gm + test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/ding.dls + test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java + test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java + test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java + test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java + test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java + test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java + test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java + test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java + test/javax/sound/midi/Gervill/ModelPerformer/SetName.java + test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java + test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java + test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java + test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/ding.sf2 + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java + test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java + test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java + test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java + test/javax/sound/midi/Gervill/SoftChannel/Controller.java + test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java + test/javax/sound/midi/Gervill/SoftChannel/Mono.java + test/javax/sound/midi/Gervill/SoftChannel/Mute.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java + test/javax/sound/midi/Gervill/SoftChannel/Omni.java + test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java + test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java + test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftChannel/Solo.java + test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java + test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java + test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java + test/javax/sound/midi/Gervill/SoftReceiver/Close.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java + test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ding.sf2 + test/javax/sound/midi/Gervill/SoftSynthesizer/expresso.mid + test/javax/sound/midi/Gervill/SoftTuning/GetName.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java + test/javax/sound/midi/Gervill/SoftTuning/Load1.java + test/javax/sound/midi/Gervill/SoftTuning/Load2.java + test/javax/sound/midi/Gervill/SoftTuning/Load4.java + test/javax/sound/midi/Gervill/SoftTuning/Load5.java + test/javax/sound/midi/Gervill/SoftTuning/Load6.java + test/javax/sound/midi/Gervill/SoftTuning/Load7.java + test/javax/sound/midi/Gervill/SoftTuning/Load8.java + test/javax/sound/midi/Gervill/SoftTuning/Load9.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java Changeset: cda097df492f Author: peterz Date: 2009-01-21 21:30 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/cda097df492f 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Summary: Fallback mechanism changed to use symbolic name instead of icon. Reviewed-by: igor, rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: cf591ddc3456 Author: naoto Date: 2009-01-21 13:58 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/cf591ddc3456 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin 6786276: Locale.getISOCountries() still contains country code "CS" Reviewed-by: okutsu ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData Changeset: f650e6e22c16 Author: malenkov Date: 2009-01-23 18:31 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f650e6e22c16 4222508: JColorChooser ignores setEnabled() function call Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test4222508.html + test/javax/swing/JColorChooser/Test4222508.java Changeset: d75ae3f11e01 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/d75ae3f11e01 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e02f2d591cd5 Author: malenkov Date: 2009-01-29 15:34 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/e02f2d591cd5 6788531: java.beans.Statement imposes excessive access control Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/Statement.java + test/java/beans/EventHandler/Test6788531.java + test/java/beans/Statement/Test6788531.java Changeset: ff6633279632 Author: rupashka Date: 2009-01-29 19:06 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ff6633279632 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794836/bug6794836.java Changeset: 1f6ff90d9692 Author: lana Date: 2009-01-29 09:25 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/1f6ff90d9692 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/share/lib/audio/soundbank.gm Changeset: 4b03e27a4409 Author: lana Date: 2009-02-03 22:02 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/4b03e27a4409 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: b4ac413b1f12 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b4ac413b1f12 Added tag jdk7-b46 for changeset 4b03e27a4409 ! .hgtags Changeset: 2ab03c2f814b Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2ab03c2f814b Added tag jdk7-b47 for changeset b4ac413b1f12 ! .hgtags Changeset: 53d9259661c3 Author: jccollet Date: 2009-01-27 11:36 +0100 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/53d9259661c3 6790677: java.net.HttpCookie.parse(String) should ignore unrecognized attributes, RFC2965 Summary: Changed code not to throw an exception on unknown attributes Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: 6eac3829cb41 Author: martin Date: 2009-01-27 15:04 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6eac3829cb41 6797480: Remove synchronization bottleneck in logger Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/Logger.java Changeset: c2d2185a79dd Author: darcy Date: 2009-01-28 10:30 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/c2d2185a79dd 6704655: Test test/java/lang/reflect/Generics/Probe.java fails under OpenJDK Reviewed-by: ksrini ! test/java/lang/reflect/Generics/Probe.java Changeset: 1ebbc958f06a Author: darcy Date: 2009-01-28 12:46 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/1ebbc958f06a 6719182: update legal notice in java/lang/instrument/package.html Reviewed-by: jjh ! src/share/classes/java/lang/instrument/package.html Changeset: 6607850bd7fc Author: martin Date: 2009-01-28 14:13 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6607850bd7fc 6798822: (process) Non-portable use of isdigit in src/solaris/native/java/lang/UNIXProcess_md.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 7241bd422542 Author: darcy Date: 2009-01-29 09:04 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7241bd422542 6239194: Object.hashCode() should reference System.identityHashCode() Reviewed-by: emcmanus ! src/share/classes/java/lang/Object.java Changeset: ff9ad99b63cc Author: darcy Date: 2009-01-29 13:04 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ff9ad99b63cc 6327048: Enum javadoc could link to JLS 6653154: Exception message for bad Enum.valueOf has spurious "class" Reviewed-by: emcmanus ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/annotation/Annotation.java + test/java/lang/Enum/ValueOf.java Changeset: 483e5c97d438 Author: darcy Date: 2009-01-30 12:40 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/483e5c97d438 6799343: (fmt) java.util.Formatter uses plainlink instead of linkplain Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java Changeset: d6881542bfef Author: michaelm Date: 2009-01-30 22:05 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/d6881542bfef 4167874: URL-downloaded jar files can consume all available file descriptors Summary: added close method to URLClassLoader Reviewed-by: alanb ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/README + test/java/net/URLClassLoader/closetest/build.sh + test/java/net/URLClassLoader/closetest/serverRoot/Test.java + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass1.java + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass1.java Changeset: 0a05a2632a81 Author: michaelm Date: 2009-01-30 22:27 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/0a05a2632a81 Merge Changeset: 948c504d6ef7 Author: darcy Date: 2009-01-30 15:09 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/948c504d6ef7 6799462: Minor typo (wrong word) in JavaDoc for InputStream.read(byte[] b) method Reviewed-by: sherman, martin ! src/share/classes/java/io/InputStream.java Changeset: f9cf49b7b248 Author: tbell Date: 2009-01-30 23:27 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f9cf49b7b248 Merge Changeset: 886a56291f1c Author: tbell Date: 2009-02-05 09:24 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/886a56291f1c Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: 6c5d04d1eff4 Author: jccollet Date: 2009-02-02 16:50 +0100 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6c5d04d1eff4 6791927: Wrong Locale in HttpCookie::expiryDate2DeltaSeconds Summary: Force Locale.US when parsing the cookie expiration date. Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java + test/java/net/CookieHandler/B6791927.java Changeset: dbb82636df41 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/dbb82636df41 6552334: Enable DNS in Kerberos by default Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! test/sun/security/krb5/DnsFallback.java Changeset: ca32af4c0ea5 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ca32af4c0ea5 6785456: Read Kerberos setting from Windows environment variables Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 050da121df16 Author: darcy Date: 2009-02-03 16:29 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/050da121df16 6548433: (enum spec) java.lang.Enum docs should explain about values() and valueOf(String) Reviewed-by: martin ! src/share/classes/java/lang/Enum.java Changeset: a96a1f0edeeb Author: xuelei Date: 2009-02-04 19:10 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/a96a1f0edeeb 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Summary: make the test robust Reviewed-by: weijun ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 61ee91f965ac Author: jccollet Date: 2009-02-04 14:15 +0100 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/61ee91f965ac 6585546: Please update API doc for java.net.CookieManager Summary: Trivial doc updates Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java Changeset: c87205c0e215 Author: tbell Date: 2009-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/c87205c0e215 Merge Changeset: 2753acfbf013 Author: tbell Date: 2009-02-06 09:43 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2753acfbf013 Merge Changeset: 14681728d6af Author: tbell Date: 2009-02-17 09:06 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/14681728d6af Merge Changeset: 75755e92430c Author: art Date: 2008-08-26 13:09 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/75755e92430c 6585765: RFE: Remove Unicows-related code from AWT 6733976: VS2008 errors compiling AWT files - explicit casts need to be added 6728735: VS2008 errors compiling UnicowsLoader.h and fatal error in awtmsg.h Summary: Unicows-related and Win95/98/Me-related code is removed Reviewed-by: uta, tdv ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/jawt/make.depend ! make/sun/splashscreen/Makefile ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/GDIHashtable.cpp ! src/windows/native/sun/windows/GDIHashtable.h ! src/windows/native/sun/windows/ShellFolder2.cpp - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Color.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Cursor.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h ! src/windows/native/sun/windows/awt_List.cpp - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h ! src/windows/native/sun/windows/awt_MenuItem.cpp - src/windows/native/sun/windows/awt_Multimon.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Palette.cpp ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_TrayIcon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h ! src/windows/native/sun/windows/awt_Win32GraphicsConfig.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/jawt.cpp Changeset: 95a618c79382 Author: art Date: 2008-08-26 16:31 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/95a618c79382 6741364: Some input method problems after the fix for 6585765 Summary: the fix for 6585765 is corrected Reviewed-by: uta ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h Changeset: 39c8e06919a9 Author: art Date: 2008-09-01 17:41 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/39c8e06919a9 6707023: Chenese Characters in JTextPane Cause Pane to Hang Summary: input method events are dispatched to correct AppContext Reviewed-by: naoto, yan ! src/windows/classes/sun/awt/windows/WInputMethod.java Changeset: b942efbc1c72 Author: dav Date: 2008-09-04 17:20 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b942efbc1c72 6738181: api/java_awt/Toolkit/index.html#GetAWTEventListeners Fails with:empty array returned unexpectedly Summary: redirect getAWTEventListeners(long l) from Headless to underlying toolkit. Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java + test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java Changeset: f0ce5b54bd90 Author: dav Date: 2008-09-04 17:24 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f0ce5b54bd90 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 31a7769b5fd1 Author: martin Date: 2008-09-08 17:26 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/31a7769b5fd1 6744609: Disable MMX support when building libpng library Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony, art ! make/sun/splashscreen/Makefile Changeset: fd13d8cce933 Author: dcherepanov Date: 2008-09-10 15:02 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/fd13d8cce933 6743433: IM candidate window is not shown until window is deactivated and reactivated again Summary: OpenCandidateWindow procedure should directly call ::DefWindowProc Reviewed-by: art ! src/windows/native/sun/windows/awt_Component.cpp Changeset: b0c557c745e8 Author: art Date: 2008-09-11 10:38 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b0c557c745e8 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers Reviewed-by: anthony, dav ! src/share/classes/java/awt/EventDispatchThread.java + test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java Changeset: 3b9a288d7ddb Author: dav Date: 2008-09-16 12:17 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/3b9a288d7ddb 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons Summary: implementation of the more mouse buttons support Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/awt/awt_Robot.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java + test/java/awt/Robot/ManualInstructions/ManualInstructions.java + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java Changeset: 7e0533679ea1 Author: dav Date: 2008-09-29 14:54 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7e0533679ea1 6746212: Broken MouseEvents for TrayIcon Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 672290c883fd Author: rkennke Date: 2008-09-29 20:16 +0200 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/672290c883fd 6749920: Cleanup AWT peer interfaces Summary: Remove duplicate and obsolete methods in the AWT peer interfaces. Reviewed-by: art, dav ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 485e803c2d5a Author: dav Date: 2008-10-03 10:33 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/485e803c2d5a 6755110: Solaris build has corrupted with extra mouse buttons RFE Reviewed-by: yan ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 5482ef16fe78 Author: yan Date: 2008-10-06 16:45 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/5482ef16fe78 5100701: Toolkit.getLockingKeyState() does not work on XToolkit, but works on Motif Summary: Does not work on Motif but works on XToolkit now; implemented using XQueryPointer. Reviewed-by: anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: ce224a356eb8 Author: dav Date: 2008-10-07 16:34 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ce224a356eb8 6750288: Regression after 6315717. ArrayIndexOutOfBoundsException. Reviewed-by: dcherepanov, denis ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 724eb9cbd3bb Author: dav Date: 2008-10-07 16:43 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/724eb9cbd3bb Merge ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: aed796ac3788 Author: dav Date: 2008-10-08 12:50 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/aed796ac3788 5076635: Double click speed is not honored in KDE linux Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java Changeset: 346127532313 Author: dav Date: 2008-10-08 13:01 +0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/346127532313 Merge - make/java/nio/spp.sh - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 0c515369b48b Author: lana Date: 2008-10-20 19:07 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/0c515369b48b Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README ! make/sun/awt/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java ! src/share/classes/java/awt/EventDispatchThread.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/awt_TextArea.cpp - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 7406833af6e4 Author: art Date: 2008-10-28 17:06 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7406833af6e4 6758673: WeakReference leak in Window.ownedWindowList Summary: WindowDisposerRecord parent field is correctly initialized Reviewed-by: dav, ant ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 9daa41eca0d9 Author: art Date: 2008-11-26 16:25 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/9daa41eca0d9 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Reviewed-by: dav, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: d5bf2dd61ed5 Author: art Date: 2008-12-19 16:04 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/d5bf2dd61ed5 6773985: OutOfMemory (PermGen space) under Linux / Firefox when switching bw. applets Summary: XEmbedClientHelper is uninstalled when its embedded frame is disposed. Reviewed-by: dcherepanov, ant ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java Changeset: 63d087cacbf9 Author: rkennke Date: 2009-01-13 20:04 +0100 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/63d087cacbf9 6792515: Specify awt peer's API Summary: Document AWT peer API. Reviewed-by: art, dav ! src/share/classes/java/awt/peer/ButtonPeer.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/DialogPeer.java ! src/share/classes/java/awt/peer/FileDialogPeer.java ! src/share/classes/java/awt/peer/FontPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/LabelPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuBarPeer.java ! src/share/classes/java/awt/peer/MenuComponentPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/MenuPeer.java ! src/share/classes/java/awt/peer/MouseInfoPeer.java ! src/share/classes/java/awt/peer/PanelPeer.java ! src/share/classes/java/awt/peer/PopupMenuPeer.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/java/awt/peer/ScrollPanePeer.java ! src/share/classes/java/awt/peer/ScrollbarPeer.java ! src/share/classes/java/awt/peer/SystemTrayPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/TrayIconPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 127e3269ee1f Author: bae Date: 2009-01-20 19:51 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/127e3269ee1f 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Reviewed-by: dav, uta ! src/windows/native/sun/windows/awt_DataTransferer.cpp Changeset: 9fa2e56c8a30 Author: art Date: 2009-01-29 14:58 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/9fa2e56c8a30 6721088: Bad window size calculation after using pack() Reviewed-by: anthony Contributed-by: Omair Majid ! src/solaris/classes/sun/awt/X11/WindowDimensions.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: f36e9200cb85 Author: anthony Date: 2009-02-04 11:58 +0300 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f36e9200cb85 6797195: Forward-port enhancements for hw/lw mixing from 6u12 to 7 Reviewed-by: art, dcherepanov ! make/sun/awt/Makefile ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows + src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JRootPane.java + src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Mixing/HWDisappear.java + test/java/awt/Mixing/JButtonInGlassPane.java + test/java/awt/Mixing/LWComboBox.java + test/java/awt/Mixing/MixingOnShrinkingHWButton.java + test/java/awt/Mixing/NonOpaqueInternalFrame.java ! test/java/awt/Mixing/OpaqueTest.java ! test/java/awt/Mixing/OverlappingButtons.java Changeset: 8b96fb2d0c3a Author: lana Date: 2009-02-10 12:26 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8b96fb2d0c3a Merge ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/EventDispatchThread.java - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 5fbd9ea7def1 Author: lana Date: 2009-02-18 10:05 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/5fbd9ea7def1 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 8311105ea7a3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8311105ea7a3 Added tag jdk7-b48 for changeset 5fbd9ea7def1 ! .hgtags Changeset: 383d6bebfba6 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/383d6bebfba6 Added tag jdk7-b49 for changeset 8311105ea7a3 ! .hgtags Changeset: 40ce81649cd6 Author: poonam Date: 2009-02-10 03:26 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/40ce81649cd6 6755621: Include SA binaries into Windows JDK Summary: These changes will enable inclusion of sa-jdi.jar and sawindbg.dll into Windows JDK bundle. Reviewed-by: never, jjh, alanb ! make/common/Defs-windows.gmk Changeset: 043dfafc41a5 Author: chegar Date: 2009-02-11 13:16 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/043dfafc41a5 6799040: Portability issues in src/solaris/native/java/net/Inet4AddressImpl.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: f06f30b29f36 Author: alanb Date: 2009-02-15 12:25 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f06f30b29f36 6781363: New I/O: Update socket-channel API to jsr203/nio2-b99 4313887: New I/O: Improved filesystem interface 4607272: New I/O: Support asynchronous I/O Reviewed-by: sherman, chegar ! make/docs/CORE_PKGS.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/java/nio/Exportedfiles.gmk ! make/java/nio/FILES_c.gmk ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/mksample/nio/Makefile + make/mksample/nio/file/Makefile + src/share/classes/com/sun/nio/file/ExtendedCopyOption.java + src/share/classes/com/sun/nio/file/ExtendedOpenOption.java + src/share/classes/com/sun/nio/file/ExtendedWatchEventModifier.java + src/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/net/StandardProtocolFamily.java ! src/share/classes/java/net/StandardSocketOption.java + src/share/classes/java/nio/channels/AsynchronousByteChannel.java + src/share/classes/java/nio/channels/AsynchronousChannel.java + src/share/classes/java/nio/channels/AsynchronousChannelGroup.java + src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java + src/share/classes/java/nio/channels/AsynchronousFileChannel.java + src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java + src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java + src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java + src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/exceptions ! src/share/classes/java/nio/channels/package-info.java + src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/channels/spi/package.html + src/share/classes/java/nio/file/AccessDeniedException.java + src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java + src/share/classes/java/nio/file/ClosedDirectoryStreamException.java + src/share/classes/java/nio/file/ClosedFileSystemException.java + src/share/classes/java/nio/file/ClosedWatchServiceException.java + src/share/classes/java/nio/file/CopyOption.java + src/share/classes/java/nio/file/DirectoryNotEmptyException.java + src/share/classes/java/nio/file/DirectoryStream.java + src/share/classes/java/nio/file/DirectoryStreamFilters.java + src/share/classes/java/nio/file/FileAction.java + src/share/classes/java/nio/file/FileAlreadyExistsException.java + src/share/classes/java/nio/file/FileRef.java + src/share/classes/java/nio/file/FileStore.java + src/share/classes/java/nio/file/FileSystem.java + src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java + src/share/classes/java/nio/file/FileSystemException.java + src/share/classes/java/nio/file/FileSystemNotFoundException.java + src/share/classes/java/nio/file/FileSystems.java + src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/java/nio/file/FileVisitOption.java + src/share/classes/java/nio/file/FileVisitResult.java + src/share/classes/java/nio/file/FileVisitor.java + src/share/classes/java/nio/file/Files.java + src/share/classes/java/nio/file/InvalidPathException.java + src/share/classes/java/nio/file/LinkOption.java + src/share/classes/java/nio/file/LinkPermission.java + src/share/classes/java/nio/file/NoSuchFileException.java + src/share/classes/java/nio/file/NotDirectoryException.java + src/share/classes/java/nio/file/NotLinkException.java + src/share/classes/java/nio/file/OpenOption.java + src/share/classes/java/nio/file/Path.java + src/share/classes/java/nio/file/PathMatcher.java + src/share/classes/java/nio/file/Paths.java + src/share/classes/java/nio/file/ProviderMismatchException.java + src/share/classes/java/nio/file/ProviderNotFoundException.java + src/share/classes/java/nio/file/ReadOnlyFileSystemException.java + src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/SimpleFileVisitor.java + src/share/classes/java/nio/file/StandardCopyOption.java + src/share/classes/java/nio/file/StandardOpenOption.java + src/share/classes/java/nio/file/StandardWatchEventKind.java + src/share/classes/java/nio/file/WatchEvent.java + src/share/classes/java/nio/file/WatchKey.java + src/share/classes/java/nio/file/WatchService.java + src/share/classes/java/nio/file/Watchable.java + src/share/classes/java/nio/file/attribute/AclEntry.java + src/share/classes/java/nio/file/attribute/AclEntryFlag.java + src/share/classes/java/nio/file/attribute/AclEntryPermission.java + src/share/classes/java/nio/file/attribute/AclEntryType.java + src/share/classes/java/nio/file/attribute/AclFileAttributeView.java + src/share/classes/java/nio/file/attribute/AttributeView.java + src/share/classes/java/nio/file/attribute/Attributes.java + src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java + src/share/classes/java/nio/file/attribute/BasicFileAttributes.java + src/share/classes/java/nio/file/attribute/DosFileAttributeView.java + src/share/classes/java/nio/file/attribute/DosFileAttributes.java + src/share/classes/java/nio/file/attribute/FileAttribute.java + src/share/classes/java/nio/file/attribute/FileAttributeView.java + src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java + src/share/classes/java/nio/file/attribute/GroupPrincipal.java + src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java + src/share/classes/java/nio/file/attribute/PosixFileAttributes.java + src/share/classes/java/nio/file/attribute/PosixFilePermission.java + src/share/classes/java/nio/file/attribute/PosixFilePermissions.java + src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java + src/share/classes/java/nio/file/attribute/UserPrincipal.java + src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java + src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java + src/share/classes/java/nio/file/attribute/package-info.java + src/share/classes/java/nio/file/package-info.java + src/share/classes/java/nio/file/spi/AbstractPath.java + src/share/classes/java/nio/file/spi/FileSystemProvider.java + src/share/classes/java/nio/file/spi/FileTypeDetector.java + src/share/classes/java/nio/file/spi/package-info.java ! src/share/classes/java/util/Scanner.java + src/share/classes/sun/nio/ch/AbstractFuture.java + src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java + src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java + src/share/classes/sun/nio/ch/Cancellable.java + src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java + src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/FileLockImpl.java + src/share/classes/sun/nio/ch/FileLockTable.java + src/share/classes/sun/nio/ch/Groupable.java ! src/share/classes/sun/nio/ch/IOUtil.java + src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/MembershipKeyImpl.java ! src/share/classes/sun/nio/ch/MembershipRegistry.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/OptionKey.java + src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java + src/share/classes/sun/nio/ch/ThreadPool.java ! src/share/classes/sun/nio/ch/Util.java + src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java + src/share/classes/sun/nio/fs/AbstractPoller.java + src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractWatchKey.java + src/share/classes/sun/nio/fs/AbstractWatchService.java + src/share/classes/sun/nio/fs/Cancellable.java + src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java + src/share/classes/sun/nio/fs/Globs.java + src/share/classes/sun/nio/fs/MimeType.java + src/share/classes/sun/nio/fs/NativeBuffer.java + src/share/classes/sun/nio/fs/NativeBuffers.java + src/share/classes/sun/nio/fs/PollingWatchService.java + src/share/classes/sun/nio/fs/Reflect.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c + src/share/sample/nio/file/AclEdit.java + src/share/sample/nio/file/Chmod.java + src/share/sample/nio/file/Copy.java + src/share/sample/nio/file/DiskUsage.java + src/share/sample/nio/file/FileType.java + src/share/sample/nio/file/WatchDir.java + src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java + src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java + src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java - src/solaris/classes/sun/nio/ch/FileDispatcher.java + src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java + src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java + src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SocketDispatcher.java + src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java + src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java + src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java + src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxFileStore.java + src/solaris/classes/sun/nio/fs/LinuxFileSystem.java + src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java + src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java + src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxWatchService.java + src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisFileStore.java + src/solaris/classes/sun/nio/fs/SolarisFileSystem.java + src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java + src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java + src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisWatchService.java + src/solaris/classes/sun/nio/fs/UnixChannelFactory.java + src/solaris/classes/sun/nio/fs/UnixCopyFile.java + src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixException.java + src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java + src/solaris/classes/sun/nio/fs/UnixFileAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileKey.java + src/solaris/classes/sun/nio/fs/UnixFileModeAttribute.java + src/solaris/classes/sun/nio/fs/UnixFileStore.java + src/solaris/classes/sun/nio/fs/UnixFileStoreAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileSystem.java + src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/classes/sun/nio/fs/UnixMountEntry.java + src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java + src/solaris/classes/sun/nio/fs/UnixPath.java + src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixUriUtils.java + src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java + src/solaris/native/sun/nio/ch/EPoll.c + src/solaris/native/sun/nio/ch/EPollPort.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c - src/solaris/native/sun/nio/ch/FileDispatcher.c + src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/SocketDispatcher.c + src/solaris/native/sun/nio/ch/SolarisEventPort.c + src/solaris/native/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.c + src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c + src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c + src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c + src/solaris/native/sun/nio/fs/LinuxWatchService.c + src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c + src/solaris/native/sun/nio/fs/SolarisWatchService.c + src/solaris/native/sun/nio/fs/UnixCopyFile.c + src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c + src/solaris/native/sun/nio/fs/genSolarisConstants.c + src/solaris/native/sun/nio/fs/genUnixConstants.c + src/windows/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java - src/windows/classes/sun/nio/ch/FileDispatcher.java + src/windows/classes/sun/nio/ch/FileDispatcherImpl.java + src/windows/classes/sun/nio/ch/Iocp.java + src/windows/classes/sun/nio/ch/PendingIoCache.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java + src/windows/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/windows/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java + src/windows/classes/sun/nio/fs/WindowsAclFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsChannelFactory.java + src/windows/classes/sun/nio/fs/WindowsConstants.java + src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java + src/windows/classes/sun/nio/fs/WindowsException.java + src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + src/windows/classes/sun/nio/fs/WindowsFileAttributes.java + src/windows/classes/sun/nio/fs/WindowsFileCopy.java + src/windows/classes/sun/nio/fs/WindowsFileStore.java + src/windows/classes/sun/nio/fs/WindowsFileSystem.java + src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java + src/windows/classes/sun/nio/fs/WindowsLinkSupport.java + src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java + src/windows/classes/sun/nio/fs/WindowsPath.java + src/windows/classes/sun/nio/fs/WindowsPathParser.java + src/windows/classes/sun/nio/fs/WindowsPathType.java + src/windows/classes/sun/nio/fs/WindowsSecurity.java + src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java + src/windows/classes/sun/nio/fs/WindowsUriSupport.java + src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsUserPrincipals.java + src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/ch/FileChannelImpl.c - src/windows/native/sun/nio/ch/FileDispatcher.c + src/windows/native/sun/nio/ch/FileDispatcherImpl.c + src/windows/native/sun/nio/ch/Iocp.c + src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c + src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java + test/java/nio/channels/AsynchronousChannelGroup/Attack.java + test/java/nio/channels/AsynchronousChannelGroup/BadProperties.java + test/java/nio/channels/AsynchronousChannelGroup/Basic.java + test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java + test/java/nio/channels/AsynchronousChannelGroup/Identity.java + test/java/nio/channels/AsynchronousChannelGroup/PrivilegedThreadFactory.java + test/java/nio/channels/AsynchronousChannelGroup/Restart.java + test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java + test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh + test/java/nio/channels/AsynchronousDatagramChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java + test/java/nio/channels/AsynchronousFileChannel/Lock.java + test/java/nio/channels/AsynchronousFileChannel/MyThreadFactory.java + test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java + test/java/nio/channels/AsynchronousServerSocketChannel/WithSecurityManager.java + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.allow + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.deny + test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/Leaky.java + test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/etc/NetworkChannelTests.java + test/java/nio/channels/spi/AsynchronousChannelProvider/CheckProvider.java + test/java/nio/channels/spi/AsynchronousChannelProvider/META-INF/services/java.nio.channels.spi.AsynchronousChannelProvider + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java + test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh + test/java/nio/file/DirectoryStream/Basic.java + test/java/nio/file/DirectoryStream/Filters.java + test/java/nio/file/DirectoryStream/SecureDS.java + test/java/nio/file/FileStore/Basic.java + test/java/nio/file/FileSystem/Basic.java + test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SimpleFileTypeDetector.java + test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TerminateWalk.java + test/java/nio/file/Files/content_type.sh + test/java/nio/file/Files/walk_file_tree.sh + test/java/nio/file/Path/CopyAndMove.java + test/java/nio/file/Path/DeleteOnClose.java + test/java/nio/file/Path/InterruptCopy.java + test/java/nio/file/Path/Links.java + test/java/nio/file/Path/Misc.java + test/java/nio/file/Path/PathOps.java + test/java/nio/file/Path/SBC.java + test/java/nio/file/Path/TemporaryFiles.java + test/java/nio/file/Path/UriImportExport.java + test/java/nio/file/Path/delete_on_close.sh + test/java/nio/file/Path/temporary_files.sh + test/java/nio/file/PathMatcher/Basic.java + test/java/nio/file/TestUtil.java + test/java/nio/file/WatchService/Basic.java + test/java/nio/file/WatchService/FileTreeModifier.java + test/java/nio/file/WatchService/SensitivityModifier.java + test/java/nio/file/WatchService/WithSecurityManager.java + test/java/nio/file/WatchService/denyAll.policy + test/java/nio/file/WatchService/grantDirAndOneLevel.policy + test/java/nio/file/WatchService/grantDirAndTree.policy + test/java/nio/file/WatchService/grantDirOnly.policy + test/java/nio/file/attribute/AclFileAttributeView/Basic.java + test/java/nio/file/attribute/Attributes/Basic.java + test/java/nio/file/attribute/BasicFileAttributeView/Basic.java + test/java/nio/file/attribute/DosFileAttributeView/Basic.java + test/java/nio/file/attribute/FileStoreAttributeView/Basic.java + test/java/nio/file/attribute/PosixFileAttributeView/Basic.java + test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java + test/java/nio/file/spi/SetDefaultProvider.java + test/java/nio/file/spi/TestProvider.java Changeset: f8a9a7aff362 Author: chegar Date: 2009-02-16 17:19 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f8a9a7aff362 6800805: java.net.NetworkInterface.getNetworkInterfaces() does not list IPv6 network interfaces correctly Reviewed-by: jccollet ! src/solaris/native/java/net/NetworkInterface.c Changeset: 1109646be6f6 Author: tbell Date: 2009-02-19 18:04 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/1109646be6f6 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: a144afafb6fe Author: xuelei Date: 2009-02-20 12:50 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/a144afafb6fe 4918870: Examine session cache implementation (sun.misc.Cache) Summary: replace sun.misc.Cache with sun.security.util.Cache Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: 6bdbb2f5c763 Author: xuelei Date: 2009-02-20 13:05 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6bdbb2f5c763 6697270: Inputstream dosent behave correct Summary: do not try to read zero byte from a InputStream, and do always return immediately for zero byte reading in a InputStream implementation. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java Changeset: 7443278199cb Author: tbell Date: 2009-02-20 10:53 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7443278199cb Merge Changeset: 9b1bc2e28518 Author: weijun Date: 2009-02-23 10:03 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/9b1bc2e28518 6535697: keytool can be more flexible on format of PEM-encoded X.509 certificates Reviewed-by: vinnie ! src/share/classes/sun/security/provider/X509Factory.java ! test/java/security/cert/CertificateFactory/BadX509CertData.java + test/java/security/cert/CertificateFactory/openssl/OpenSSLCert.java + test/java/security/cert/CertificateFactory/openssl/open + test/java/security/cert/CertificateFactory/openssl/pem Changeset: 33bc32405045 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/33bc32405045 6789935: cross-realm capath search error Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Realm.java + test/sun/security/krb5/ParseCAPaths.java + test/sun/security/krb5/krb5-capaths.conf Changeset: ec98d5f9b338 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ec98d5f9b338 6804045: DerValue does not accept empty OCTET STRING Reviewed-by: xuelei ! src/share/classes/sun/security/util/DerValue.java + test/sun/security/util/DerValue/EmptyValue.java Changeset: 8edcd68fb6ac Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8edcd68fb6ac 6803376: BasicConstraintsExtension does not encode when (ca==false && pathLen<0) Reviewed-by: xuelei ! src/share/classes/sun/security/x509/BasicConstraintsExtension.java + test/sun/security/x509/Extensions/BCNull.java Changeset: 90ab7b4891e3 Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/90ab7b4891e3 6780416: New keytool commands/options: -gencert, -printcertreq, -ext Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/x509/AccessDescription.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/classes/sun/security/x509/AuthorityKeyIdentifierExtension.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java ! src/share/classes/sun/security/x509/OIDMap.java + src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/autotest.sh + test/sun/security/tools/keytool/standard.sh Changeset: 2a7c1a997102 Author: xuelei Date: 2009-02-23 17:32 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2a7c1a997102 5067458: Loopback SSLSocketImpl createSocket is throwing an exception Summary: A null hostname should be regarded as a loopback address. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java Changeset: 0f4497002345 Author: chegar Date: 2009-02-23 10:36 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/0f4497002345 6806649: synchronization bottleneck when constructing Thread subclasses Summary: Replace subclass audits synchronization with ConcurrentHashMap with weakly referenced Class keys Reviewed-by: peterjones, dholmes, martin ! src/share/classes/java/lang/Thread.java Changeset: 27e1141d436c Author: sherman Date: 2009-02-23 21:06 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/27e1141d436c 6350801: Add support for named (instead of numbered) capture groups in regular expression 6676425: Opensource unit/regression tests for java.util.regex Summary: Added "named capturing group" into regex. Moved most of reg/unit tests to openjdk. Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/BMPTestCases.txt + test/java/util/regex/RegExTest.java + test/java/util/regex/SupplementaryTestCases.txt + test/java/util/regex/TestCases.txt Changeset: 910f9cceb0f8 Author: alanb Date: 2009-02-24 09:11 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/910f9cceb0f8 6808647: (file) Paths.get("C:").newDirectoryStream() iterates over Path elements with additional slash [win] 6808648: (file) Files.walkFileTree should obtain file attributes during iteration [win] Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/sun/nio/fs/BasicFileAttributesHolder.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/file/DirectoryStream/DriveLetter.java Changeset: c7f39995fcf4 Author: alanb Date: 2009-02-24 11:31 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/c7f39995fcf4 6809132: (file) Javadoc style and consistency issues Reviewed-by: vinnie Contributed-by: cquinn at google.com ! src/share/classes/java/nio/file/AccessDeniedException.java ! src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java ! src/share/classes/java/nio/file/DirectoryNotEmptyException.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/DirectoryStreamFilters.java ! src/share/classes/java/nio/file/FileAction.java ! src/share/classes/java/nio/file/FileAlreadyExistsException.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java ! src/share/classes/java/nio/file/FileSystemException.java ! src/share/classes/java/nio/file/FileSystemNotFoundException.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/InvalidPathException.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/NoSuchFileException.java ! src/share/classes/java/nio/file/NotDirectoryException.java ! src/share/classes/java/nio/file/NotLinkException.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/ProviderMismatchException.java ! src/share/classes/java/nio/file/ProviderNotFoundException.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java ! src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java ! src/share/classes/java/nio/file/package-info.java Changeset: abe5e7125bd3 Author: alanb Date: 2009-02-24 11:33 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/abe5e7125bd3 Merge Changeset: dc237aecf7cf Author: kevinw Date: 2009-02-24 14:22 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/dc237aecf7cf 6599383: Unable to open zip files more than 2GB in size Reviewed-by: alanb ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h + test/java/util/zip/ZipFile/LargeZipFile.java Changeset: 59e76cdc647a Author: tbell Date: 2009-02-27 10:53 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/59e76cdc647a Merge Changeset: 58ba2cd5a250 Author: alanb Date: 2009-03-01 14:44 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/58ba2cd5a250 6811578: genSolarisConstants.c should not require kernel patch to compile on Solaris 10 Reviewed-by: tbell ! src/solaris/native/sun/nio/fs/genSolarisConstants.c Changeset: 002c2acebd2e Author: dougfelt Date: 2009-03-02 12:49 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/002c2acebd2e Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: adb5cbfd4d56 Author: dougfelt Date: 2009-02-23 16:42 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/adb5cbfd4d56 Automated merge with http://hg.openjdk.java.net/jdk7/jdk7/jdk/ Changeset: 422bb685176e Author: dougfelt Date: 2009-02-25 15:18 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/422bb685176e Collect all test errors before reporting failure. ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 2da0c15dfa98 Author: dougfelt Date: 2009-03-02 11:19 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2da0c15dfa98 initial icu implementation + src/share/classes/java/util/InvalidLocaleIdentifierException.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/spi/LocaleNameProvider.java + src/share/classes/sun/util/locale/AsciiUtil.java + src/share/classes/sun/util/locale/BaseLocale.java + src/share/classes/sun/util/locale/InternalLocaleBuilder.java + src/share/classes/sun/util/locale/LanguageTag.java + src/share/classes/sun/util/locale/LocaleExtensions.java + src/share/classes/sun/util/locale/LocaleObjectCache.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/icuLocales.txt Changeset: 98bb0afa1925 Author: dougfelt Date: 2009-03-02 11:22 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/98bb0afa1925 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: 94da517e6127 Author: dougfelt Date: 2009-03-02 12:33 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/94da517e6127 update locale test framework to not call System.exit by default ! test/java/util/Locale/LocaleTestFmwk.java Changeset: 606d00d2a98c Author: dougfelt Date: 2009-03-02 13:07 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/606d00d2a98c Summary: initial locale-enhancement implementation based on ICU Reviewed-by: dougfelt From dougfelt at google.com Tue Mar 3 11:49:55 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Tue, 03 Mar 2009 19:49:55 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Add API tests for new Locale and all LocaleBuilder APIs. Message-ID: <20090303195018.17370E698@hg.openjdk.java.net> Changeset: 79c1aeac7baf Author: dougfelt Date: 2009-03-03 11:47 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/79c1aeac7baf Add API tests for new Locale and all LocaleBuilder APIs. Details of some tests are provisional. ! test/java/util/Locale/LocaleEnhanceTest.java From dougfelt at google.com Tue Mar 3 12:08:49 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Tue, 03 Mar 2009 20:08:49 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 2 new changesets Message-ID: <20090303200914.27D07E69D@hg.openjdk.java.net> Changeset: 8a5a5da8b344 Author: dougfelt Date: 2009-03-03 12:01 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8a5a5da8b344 Move locale identifier exception out of api. - src/share/classes/java/util/InvalidLocaleIdentifierException.java + src/share/classes/sun/util/locale/InvalidLocaleIdentifierException.java Changeset: f614ef4cdeb8 Author: dougfelt Date: 2009-03-03 12:03 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f614ef4cdeb8 Update files that use InvalidLocaleIdentifierException to use new location. ! src/share/classes/sun/util/locale/InvalidLocaleIdentifierException.java ! src/share/classes/sun/util/locale/LanguageTag.java From y.umaoka at gmail.com Tue Mar 3 13:18:12 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 16:18:12 -0500 Subject: [loc-en-dev] [Fwd: Updated JavaDoc] In-Reply-To: <49AD96C4.1090209@gmail.com> References: <49AD7B30.5060707@gmail.com> <30b660a20903031205n571e68c1u5611fe9e23791ac3@mail.gmail.com> <49AD96C4.1090209@gmail.com> Message-ID: <49AD9E94.6070700@gmail.com> Forwarding additional comments from Mark Davis below - ------------------------ More comments: getDisplayName public java.lang.String *getDisplayName*(Locale inLocale) Returns a name for the locale that is appropriate for display to the user. This will be the values returned by getDisplayLanguage(), getDisplayCountry(), and getDisplayVariant() assembled into a single string. The display name will have one of the following forms: language (country, variant) language (country) language (variant) country (variant) language country variant => The display name will typically have one of the following forms. However, localized versions may have combined names (eg "American English") or used other punctuation or ordering. setLocale public Locale.LocaleBuilder *setLocale*(Locale loc) New API Sets the locale to this builder. *Parameters:* |loc| - the locale Sets the locale in this builder. Replaces all fields: thus new LocaleBuilder().setLocale(loc).create().equals(loc). In general, "Sets the X to this builder. " should be "Sets the X field in this builder. " Mark On Tue, Mar 3, 2009 at 12:44, Yoshito Umaoka > wrote: Thanks for your comments. If you do not have any objections, I'll forward your note to the OpenJDK list. Mark Davis wrote: Because a |Locale| object is just an identifier for a region, no validity check is performed when you construct a |Locale|. Add text indicating that it is strongly recommended that only valid Unicode locale idenfiers be used in constructing locales. |static java.lang.String[]| |*getISOCountries *()| Returns a list of all 2-letter country codes defined in ISO 3166. |static java.lang.String[]| |*getISOLanguages *()| Returns a list of all 2-letter language codes defined in ISO 639. Deprecate these. Note in the text that while the original purpose of these was to supply the components used in forming Locales, the standard definition has moved beyond them. Ideally, we would add also: getBCP47BaseLanguages getBCP47Scripts getBCP47Regions getBCP47Variants but the OpenJDK group may not buy off on that. We could discuss it, however. SIMPLIFIED_CHINESE public static final Locale *SIMPLIFIED_CHINESE* Useful constant for language. ------------------------------------------------------------------------ TRADITIONAL_CHINESE public static final Locale *TRADITIONAL_CHINESE* Useful constant for language. Add notes that more properly speaking, these should be zh_Hans and zh_Hant. However, for backwards compatibility these can continue to be used. (I assume that the locale lookup is being changed to make these essentially equal in lookup.) Update the language in various places, eg: Returns the language code for this locale, which will either be the empty string or a lowercase ISO 639 code. => Returns the language code for this locale, which should either be the empty string or a Unicode region identifier code. [Note, that language was always in conflict with the class description, which had no absolute requirements on the code.] getPrivateUse public java.lang.String *getPrivateUse*() New API Returns the private use code for this locale. I don't understand this. New API Returns a locale for the specified language tag string. If the specified language tag contains any invalid subtags, the first invalid subtag and all following subtags are ignored. Ignoring is dangerous... If it is ill-formed, it should raise an exception. More later. Mark On Tue, Mar 3, 2009 at 10:47, Yoshito Umaoka >> wrote: Hi Mark, If you have chance, please take a quick look for the proposed API changes in the links below. Doug and I are trying to refine the details and provide better API documentation, but we do not expect any major changes from here. (We are considering to add several APIs - boolean Locale#isEquivalentTo(Locale), LocaleBuilder#removeExtensions...) If you have any comments, please post your comments directly to locale-enhancement-dev at openjdk.java.net >. Thanks, Yoshito -------- Original Message -------- Subject: Updated JavaDoc Date: Fri, 27 Feb 2009 11:59:08 -0500 From: Yoshito Umaoka >> To: locale-enhancement-dev at openjdk.java.net > http://sites.google.com/site/openjdklocale/apis I updated the JavaDoc based on things found during the implementation and some inputs from Doug. - Locale.LocaleExtension / Locale.LocaleKeywords are gone. - Setters in LocaleBuilder no longer throw an exception for a malformed input. - LocaleBuilder#create() - ignore malformed fields. - LocaleBuilder#createStrict() - return null when any malformed fields are found. -Yoshito -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090303/c1405464/attachment.html From y.umaoka at gmail.com Tue Mar 3 13:22:57 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 16:22:57 -0500 Subject: [loc-en-dev] [Fwd: Updated JavaDoc] In-Reply-To: <49AD7B30.5060707@gmail.com> References: <49AD7B30.5060707@gmail.com> Message-ID: <49AD9FB1.9090609@gmail.com> Fowarding the message from Mark Davis below - ------------------------- Because a |Locale| object is just an identifier for a region, no validity check is performed when you construct a |Locale|. Add text indicating that it is strongly recommended that only valid Unicode locale idenfiers be used in constructing locales. |static java.lang.String[]| |*getISOCountries *()| Returns a list of all 2-letter country codes defined in ISO 3166. |static java.lang.String[]| |*getISOLanguages *()| Returns a list of all 2-letter language codes defined in ISO 639. Deprecate these. Note in the text that while the original purpose of these was to supply the components used in forming Locales, the standard definition has moved beyond them. Ideally, we would add also: getBCP47BaseLanguages getBCP47Scripts getBCP47Regions getBCP47Variants but the OpenJDK group may not buy off on that. We could discuss it, however. SIMPLIFIED_CHINESE public static final Locale *SIMPLIFIED_CHINESE* Useful constant for language. ------------------------------------------------------------------------ TRADITIONAL_CHINESE public static final Locale *TRADITIONAL_CHINESE* Useful constant for language. Add notes that more properly speaking, these should be zh_Hans and zh_Hant. However, for backwards compatibility these can continue to be used. (I assume that the locale lookup is being changed to make these essentially equal in lookup.) Update the language in various places, eg: Returns the language code for this locale, which will either be the empty string or a lowercase ISO 639 code. => Returns the language code for this locale, which should either be the empty string or a Unicode region identifier code. [Note, that language was always in conflict with the class description, which had no absolute requirements on the code.] getPrivateUse public java.lang.String *getPrivateUse*() New API Returns the private use code for this locale. I don't understand this. New API Returns a locale for the specified language tag string. If the specified language tag contains any invalid subtags, the first invalid subtag and all following subtags are ignored. Ignoring is dangerous... If it is ill-formed, it should raise an exception. More later. Mark On Tue, Mar 3, 2009 at 10:47, Yoshito Umaoka > wrote: Hi Mark, If you have chance, please take a quick look for the proposed API changes in the links below. Doug and I are trying to refine the details and provide better API documentation, but we do not expect any major changes from here. (We are considering to add several APIs - boolean Locale#isEquivalentTo(Locale), LocaleBuilder#removeExtensions...) If you have any comments, please post your comments directly to locale-enhancement-dev at openjdk.java.net . Thanks, Yoshito -------- Original Message -------- Subject: Updated JavaDoc Date: Fri, 27 Feb 2009 11:59:08 -0500 From: Yoshito Umaoka > To: locale-enhancement-dev at openjdk.java.net http://sites.google.com/site/openjdklocale/apis I updated the JavaDoc based on things found during the implementation and some inputs from Doug. - Locale.LocaleExtension / Locale.LocaleKeywords are gone. - Setters in LocaleBuilder no longer throw an exception for a malformed input. - LocaleBuilder#create() - ignore malformed fields. - LocaleBuilder#createStrict() - return null when any malformed fields are found. -Yoshito -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090303/adff6555/attachment.html From y.umaoka at gmail.com Tue Mar 3 13:45:07 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 16:45:07 -0500 Subject: [loc-en-dev] [Fwd: Updated JavaDoc] In-Reply-To: <49AD9FB1.9090609@gmail.com> References: <49AD7B30.5060707@gmail.com> <49AD9FB1.9090609@gmail.com> Message-ID: <49ADA4E3.6090305@gmail.com> Yoshito's comment in this color. > Fowarding the message from Mark Davis below - > ------------------------- > > Because a |Locale| object is just an identifier for a region, no > validity check is performed when you construct a |Locale|. > > Add text indicating that it is strongly recommended that only valid > Unicode locale idenfiers be used in constructing locales. I propose to explain about well-formed Locale and arbitrary Locale in the JavaDoc for the class. We definitely need to explain what was will be changed in JDK7. > > > |static java.lang.String[]| |*getISOCountries > *()| > > Returns a list of all 2-letter country codes defined in ISO > 3166. > |static java.lang.String[]| |*getISOLanguages > *()| > > Returns a list of all 2-letter language codes defined in ISO > 639. > > > Deprecate these. Note in the text that while the original purpose of > these was to supply the components used in forming Locales, the > standard definition has moved beyond them. > > Ideally, we would add also: > getBCP47BaseLanguages > getBCP47Scripts > getBCP47Regions > getBCP47Variants > but the OpenJDK group may not buy off on that. We could discuss it, > however. > I do not think these existing methods should be deprecated. As Mark pointed out, the standard definition has moved beyond them, but it does not mean you cannot use a code returned by getISOCountries or getISOLanguages for a Locale. We just go beyond them. getBCP47xxxx might be useful (although I do not like the names), but I think it's optional for now. > > SIMPLIFIED_CHINESE > > public static final Locale *SIMPLIFIED_CHINESE* > > Useful constant for language. > > ------------------------------------------------------------------------ > > > TRADITIONAL_CHINESE > > public static final Locale *TRADITIONAL_CHINESE* > Useful constant for language. > > Add notes that more properly speaking, these should be zh_Hans and > zh_Hant. However, for backwards compatibility these can continue to be > used. (I assume that the locale lookup is being changed to make these > essentially equal in lookup.) > > Update the language in various places, eg: > > Returns the language code for this locale, which will either be the > empty string or a lowercase ISO 639 code. > => Returns the language code for this locale, which should either be > the empty string or a Unicode region identifier code. > I agree that the description must be updated. (I did not touch existing JavaDoc for this time, but I know we'll need to do so) > [Note, that language was always in conflict with the class > description, which had no absolute requirements on the code.] > > > getPrivateUse > > public java.lang.String *getPrivateUse*() > > New API Returns the private use code for this locale. > I don't understand this. > I'd like to make Locale to duplicate BCP47 langtag (defined by the BNF, not Language-Tag) in Locale. Of course, "privateuse" field is probably not used practically, but we want this for supporting canonical roundtrip between Locale and BCP47 language tag. The valid syntax for BCP47 "privateuse" differs from singleton extension values. So I prefer to handle "privateuse" field separated from other BCP47 singleton extensions. > > New API Returns a locale for the specified language tag string. If the > specified language tag contains any invalid subtags, the first invalid > subtag and all following subtags are ignored. > > Ignoring is dangerous... If it is ill-formed, it should raise an > exception. > I agree that we need "strict" version of Locale#forLanguageTag. But at the same time, we also need "easy" version and this is the easy version. I expect most people just use this version, rather than doing their own error handling. > More later. > > > Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090303/1e574096/attachment.html From y.umaoka at gmail.com Tue Mar 3 13:56:47 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 16:56:47 -0500 Subject: [loc-en-dev] [Fwd: Updated JavaDoc] In-Reply-To: <49AD9E94.6070700@gmail.com> References: <49AD7B30.5060707@gmail.com> <30b660a20903031205n571e68c1u5611fe9e23791ac3@mail.gmail.com> <49AD96C4.1090209@gmail.com> <49AD9E94.6070700@gmail.com> Message-ID: <49ADA79F.9080806@gmail.com> Yoshito's comments in this color. > Forwarding additional comments from Mark Davis below - > ------------------------ > > More comments: > > > getDisplayName > > public java.lang.String *getDisplayName*(Locale inLocale) > > Returns a name for the locale that is appropriate for display to > the user. This will be the values returned by > getDisplayLanguage(), getDisplayCountry(), and getDisplayVariant() > assembled into a single string. The display name will have one of > the following forms: > > language (country, variant) > > language (country) > > language (variant) > > country (variant) > > language > > country > > variant > > => The display name will typically have one of the following forms. > However, localized versions may have combined names (eg "American > English") or used other punctuation or ordering. > The immediate requirement for now is to decide how to add script information if available (or not?). We probably revisit generic display format pattern issue after JDK7. > > setLocale > > public Locale.LocaleBuilder *setLocale*(Locale loc) > > New API Sets the locale to this builder. > > *Parameters:* > |loc| - the locale > > > Sets the locale in this builder. Replaces all fields: thus new > LocaleBuilder().setLocale(loc).create().equals(loc). > > In general, "Sets the X to this builder. " should be "Sets the X field > in this builder. " > We still have a design question open for this method. If the given Locale has any fields which do not meet the BCP47 syntax requirement, we have several options - 1. Leave it as is. If you call createStrict() later and the field was not overridden by another setXXX call, return null (error). 2. Ignore fields which do not support the BCP47 syntax requirement. As the result, createStrict() does not produce any errors. The malformed field is simply ignored. 3. Do canonical mapping first in setLocale call, then if the syntactical issue still remains, 1 or 2 above. For example, new LocaleBuilder.setLocale(new Locale("ja", "JP", "JP")).createStrict() returns locale ja_JP for option 1, null for option 2, ja_JP_ca_japanese for 3. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090303/5456693d/attachment.html From dougfelt at google.com Tue Mar 3 13:56:51 2009 From: dougfelt at google.com (Doug Felt) Date: Tue, 3 Mar 2009 13:56:51 -0800 Subject: [loc-en-dev] [Fwd: Updated JavaDoc] In-Reply-To: <49ADA4E3.6090305@gmail.com> References: <49AD7B30.5060707@gmail.com> <49AD9FB1.9090609@gmail.com> <49ADA4E3.6090305@gmail.com> Message-ID: <146f39a80903031356r2643f686l4b88bd1dec248d8a@mail.gmail.com> I'm going to revise and edit the javadoc comments, so we don't worry for now about particulars of wording, just the overall semantics. The tests express my understanding (as of this morning) of the semantics of the APIs. It would help to review them. I'll write the javadocs based on them but probably won't finish before the meeting this afternoon. Doug On Tue, Mar 3, 2009 at 1:45 PM, Yoshito Umaoka wrote: > Yoshito's comment in this color. > > Fowarding the message from Mark Davis below - > ------------------------- > > Because a Locale object is just an identifier for a region, no validity > check is performed when you construct a Locale. > > Add text indicating that it is strongly recommended that only valid Unicode > locale idenfiers be used in constructing locales. > > I propose to explain about well-formed Locale and arbitrary Locale in the > JavaDoc for the class. We definitely need to explain what was will be > changed in JDK7. > > > > static java.lang.String[] *getISOCountries > *() > Returns a list of all 2-letter country codes defined in ISO 3166. > static java.lang.String[] *getISOLanguages > *() > Returns a list of all 2-letter language codes defined in ISO 639. > Deprecate these. Note in the text that while the original purpose of these > was to supply the components used in forming Locales, the standard > definition has moved beyond them. > > Ideally, we would add also: > getBCP47BaseLanguages > getBCP47Scripts > getBCP47Regions > getBCP47Variants > but the OpenJDK group may not buy off on that. We could discuss it, > however. > > I do not think these existing methods should be deprecated. As Mark > pointed out, the standard definition has moved beyond them, but it does not > mean you cannot use a code returned by getISOCountries or getISOLanguages > for a Locale. We just go beyond them. > > getBCP47xxxx might be useful (although I do not like the names), but I > think it's optional for now. > > SIMPLIFIED_CHINESE > > public static final Locale *SIMPLIFIED_CHINESE* > > Useful constant for language. > ------------------------------ > TRADITIONAL_CHINESE > > public static final Locale *TRADITIONAL_CHINESE* > > Useful constant for language. > > Add notes that more properly speaking, these should be zh_Hans and zh_Hant. > However, for backwards compatibility these can continue to be used. (I > assume that the locale lookup is being changed to make these essentially > equal in lookup.) > > Update the language in various places, eg: > > Returns the language code for this locale, which will either be the empty > string or a lowercase ISO 639 code. > => Returns the language code for this locale, which should either be the > empty string or a Unicode region identifier code. > > I agree that the description must be updated. (I did not touch existing > JavaDoc for this time, but I know we'll need to do so) > > [Note, that language was always in conflict with the class description, > which had no absolute requirements on the code.] > > getPrivateUse > > public java.lang.String *getPrivateUse*() > > New API Returns the private use code for this locale. I don't understand > this. > > I'd like to make Locale to duplicate BCP47 langtag (defined by the BNF, not > Language-Tag) in Locale. Of course, "privateuse" field is probably not used > practically, but we want this for supporting canonical roundtrip between > Locale and BCP47 language tag. The valid syntax for BCP47 "privateuse" > differs from singleton extension values. So I prefer to handle "privateuse" > field separated from other BCP47 singleton extensions. > > > New API Returns a locale for the specified language tag string. If the > specified language tag contains any invalid subtags, the first invalid > subtag and all following subtags are ignored. > > Ignoring is dangerous... If it is ill-formed, it should raise an exception. > > I agree that we need "strict" version of Locale#forLanguageTag. But at > the same time, we also need "easy" version and this is the easy version. I > expect most people just use this version, rather than doing their own error > handling. > > More later. > > > Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090303/39081df3/attachment.html From dougfelt at google.com Tue Mar 3 14:02:41 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Tue, 03 Mar 2009 22:02:41 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Fix Locale.java for move of InvalidLocaleIdentifierException. Message-ID: <20090303220254.82EA0E6B1@hg.openjdk.java.net> Changeset: 8b4f28f4e948 Author: dougfelt Date: 2009-03-03 13:12 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8b4f28f4e948 Fix Locale.java for move of InvalidLocaleIdentifierException. ! src/share/classes/java/util/Locale.java From Masayoshi.Okutsu at Sun.COM Tue Mar 3 14:49:28 2009 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Wed, 04 Mar 2009 07:49:28 +0900 Subject: [loc-en-dev] Locale builder class name Message-ID: <49ADB3F8.4040200@sun.com> I still prefer the nested class name to be Builder (not LocaleBuilder) as I stated in January. Locale.LocaleBuilder is redundant. Thanks, Masayoshi From dougfelt at google.com Tue Mar 3 16:05:29 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Wed, 04 Mar 2009 00:05:29 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Update/revise javadoc for Locale and LocaleBuilder. Message-ID: <20090304000542.3AE27E706@hg.openjdk.java.net> Changeset: 8b74bb94dc4a Author: dougfelt Date: 2009-03-03 16:01 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8b74bb94dc4a Update/revise javadoc for Locale and LocaleBuilder. Add/change a few test cases. ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java From y.umaoka at gmail.com Tue Mar 3 18:11:44 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 21:11:44 -0500 Subject: [loc-en-dev] Locale builder class name In-Reply-To: <49ADB3F8.4040200@sun.com> References: <49ADB3F8.4040200@sun.com> Message-ID: <49ADE360.1020201@gmail.com> I missed your comment. Yes, I agree that Locale.LocaleBuilder is redundant. If other folks have no objections, I'll update the proposal. Masayoshi Okutsu wrote: > I still prefer the nested class name to be Builder (not LocaleBuilder) > as I stated in January. Locale.LocaleBuilder is redundant. > > Thanks, > Masayoshi > > -Yoshito From dougfelt at google.com Tue Mar 3 16:25:09 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Wed, 04 Mar 2009 00:25:09 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Javadoc: replace 'valid' with 'well-formed' and 'invalid' with 'ill-formed'. Message-ID: <20090304002521.7A81EE711@hg.openjdk.java.net> Changeset: 21a81a043a76 Author: dougfelt Date: 2009-03-03 16:23 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/21a81a043a76 Javadoc: replace 'valid' with 'well-formed' and 'invalid' with 'ill-formed'. ! src/share/classes/java/util/Locale.java From y.umaoka at gmail.com Tue Mar 3 19:07:40 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 03 Mar 2009 22:07:40 -0500 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag Message-ID: <49ADF07C.7040207@gmail.com> We discussed about error handling behavior in the locale builder and the factory method Locale#forLanguageTag in the project conference call today. Doug summarized the current consensus below - Builder: - throw a runtime exception (for well managed inputs, caller does not require try-catch) on setters if ill-formed (including setLocale with a locale that has no canonical BCP47 form) - remove createStrict() - add setLanguageTag (and throw a runtime exception if ill-formed) - throw null pointer exception for all null arguments. setXXX is still used for clear the target internal field, but must use empty string "" for the purpose. Locale.forLanguageTag - throw null pointer exception for null argument - continue supporting lenient behavior (no exception throw) I think we probably do not need a dedicated class for the exception - probably just use IllegalArgumentException for Builder#setXXX. (It might be too ambiguous for setLanguageTag, but for other cases, syntax check should be pretty simple, so call should be able to figure out the error before hand) If anyone has any alternative proposal, please respond to this message. -Yoshito From y.umaoka at gmail.com Wed Mar 4 12:34:21 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Wed, 04 Mar 2009 20:34:21 +0000 Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_JDK7_Locale_API_ch?= =?windows-1252?q?ange_review_=40_Tue_Mar_10_7=3A30pm_=96_9pm_=28lo?= =?windows-1252?q?cale-enhancement-dev=40openjdk=2Ejava=2Enet=29?= Message-ID: <00163645923c002000046450fa54@google.com> locale-enhancement-dev at openjdk.java.net, you are invited to Title: JDK7 Locale API change review Time: Tue Mar 10 7:30pm ? 9pm (Timezone: Eastern Time) Where: Teleconference Calendar: locale-enhancement-dev at openjdk.java.net Owner/Creator: y.umaoka at gmail.com Description: I'm scheduling this extra conference call in addition to the bi-weekly regular call for reviewing all of Locale API changes to be proposed for JDK7. Yoshito and Doug will complete proposals (including some additions/modifications from the current proposal) before this call. We'll keep the API doc in the project site updated and communicate all modifications with you in the project ML. Toll free from the US and Canada: (877)421-0033 International dialing: +1(770)615-1250 Toll free from Japan (KDD): 00531-11-3180 Toll free from Japan (Cable&Wireless): 0066-33-801263 Toll free from Japan (Softbank): 0044-22-112668 Toll free from Japan (NTT): 0034-800-900155 Other country dial-ins available on request Passcode: 662122# You can view this event at http://www.google.com/calendar/event?action=VIEW&eid=bGNsdmtsbjhqODl2cWE2a3BxbzZtYzlqNmMgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tNDYxNTAzZDBlYmZjZjJjMGI3NzgwNWY5NGNlZjE1ZWRlODhhMzllNA&ctz=America%2FNew_York&hl=en You are receiving this courtesy email at the account locale-enhancement-dev at openjdk.java.net because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at http://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090304/009b3bdb/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1879 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090304/009b3bdb/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1918 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090304/009b3bdb/attachment-0001.bin From y.umaoka at gmail.com Wed Mar 4 20:36:30 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Wed, 04 Mar 2009 23:36:30 -0500 Subject: [loc-en-dev] [Fwd: Error handling in LocaleBuilder and forLanguageTag] Message-ID: <49AF56CE.8090809@gmail.com> Hi folks, I updated the implementation as mentioned in the previous post below. Doug is going to merge this revision to the repository tomorrow. I've updated the proposed API page - http://sites.google.com/site/openjdklocale/apis - with the updated Locale.java. Thanks, Yoshito -------- Original Message -------- Subject: Error handling in LocaleBuilder and forLanguageTag Date: Tue, 03 Mar 2009 22:07:40 -0500 From: Yoshito Umaoka To: locale-enhancement-dev at openjdk.java.net We discussed about error handling behavior in the locale builder and the factory method Locale#forLanguageTag in the project conference call today. Doug summarized the current consensus below - Builder: - throw a runtime exception (for well managed inputs, caller does not require try-catch) on setters if ill-formed (including setLocale with a locale that has no canonical BCP47 form) - remove createStrict() - add setLanguageTag (and throw a runtime exception if ill-formed) - throw null pointer exception for all null arguments. setXXX is still used for clear the target internal field, but must use empty string "" for the purpose. Locale.forLanguageTag - throw null pointer exception for null argument - continue supporting lenient behavior (no exception throw) I think we probably do not need a dedicated class for the exception - probably just use IllegalArgumentException for Builder#setXXX. (It might be too ambiguous for setLanguageTag, but for other cases, syntax check should be pretty simple, so call should be able to figure out the error before hand) If anyone has any alternative proposal, please respond to this message. -Yoshito From y.umaoka at gmail.com Wed Mar 4 21:04:29 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 05 Mar 2009 00:04:29 -0500 Subject: [loc-en-dev] Variant display name Message-ID: <49AF5D5D.3010204@gmail.com> Hi all, While I was investing what to do for Locale display name, I realized there are 3 kinds of variants have its own name in JDK. %%EURO=Euro %%B=Bokm\u00e5l %%NY=Nynorsk However, this page - http://java.sun.com/javase/6/docs/technotes/guides/intl/locale.doc.html - does not contain any supported locales with variant EURO and B. I have several questions here. 1. I think EURO was used long time ago to distinguish the use of legacy domestic currency from Euro in European locales. But for now, we no longer have any locales supporting both legacy and Euro. I think it's OK to leave it there, but do we need any special handling required for locale canonicalization/or checking equality? 2. I think B is also obsolete. Language code "no" is treated as "Norwegian Bokmal" for now. Can we simply ignore the semantics of variant B in general? 3. The supported locale list contains ja_JP_JP / th_TH_TH. These locales are canonicalized to ja_JP_u_ca_japanese / th_TH_u_nu_thai by the new design. Luckily we do not have any display names assigned to them. For now, I did not propose to add locale keyword key/type display name support (ICU supports this), because we are not sure how much JDK i18n service supports them in JDK7 time frame. For display name purpose, can we simply continue to use variant code JP/TH for now? -Yoshito From y.umaoka at gmail.com Wed Mar 4 21:36:12 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 05 Mar 2009 00:36:12 -0500 Subject: [loc-en-dev] Locale Display Name with script Message-ID: <49AF64CC.8010408@gmail.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090305/491af9d4/attachment.html From Naoto.Sato at Sun.COM Thu Mar 5 10:21:14 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Thu, 05 Mar 2009 10:21:14 -0800 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag In-Reply-To: <49ADF07C.7040207@gmail.com> References: <49ADF07C.7040207@gmail.com> Message-ID: <49B0181A.3050008@Sun.COM> Folks, I have two comments as follows: - Locale.forLanguageTag(): Please describe how the lenient behavior works in the spec. This should not be implementation dependent. - What happens with Builder.setLanguageTag(), if some other setXXX()s are previously called and they conflict? Are they reset strictly to setLanguageTag(), or superset tag is created, or an exception? Naoto Yoshito Umaoka wrote: > We discussed about error handling behavior in the locale builder and the > factory method Locale#forLanguageTag in the project conference call > today. Doug summarized the current consensus below - > > Builder: > - throw a runtime exception (for well managed inputs, caller does not > require try-catch) on setters if ill-formed (including setLocale with a > locale that has no canonical BCP47 form) > - remove createStrict() > - add setLanguageTag (and throw a runtime exception if ill-formed) > - throw null pointer exception for all null arguments. setXXX is still > used for clear the target internal field, but must use empty string "" > for the purpose. > > Locale.forLanguageTag > - throw null pointer exception for null argument > - continue supporting lenient behavior (no exception throw) > > I think we probably do not need a dedicated class for the exception - > probably just use IllegalArgumentException for Builder#setXXX. (It > might be too ambiguous for setLanguageTag, but for other cases, syntax > check should be pretty simple, so call should be able to figure out the > error before hand) > > If anyone has any alternative proposal, please respond to this message. > > -Yoshito -- Naoto Sato From y.umaoka at gmail.com Thu Mar 5 10:40:10 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 05 Mar 2009 13:40:10 -0500 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag In-Reply-To: <49B0181A.3050008@Sun.COM> References: <49ADF07C.7040207@gmail.com> <49B0181A.3050008@Sun.COM> Message-ID: <49B01C8A.4020500@gmail.com> Naoto Sato wrote: > Folks, > > I have two comments as follows: > > - Locale.forLanguageTag(): Please describe how the lenient behavior > works in the spec. This should not be implementation dependent. * Returns a locale for the specified language tag string. If the * specified language tag contains any non-well-formed subtags, the first * such subtag and all following subtags are ignored. This is the current JavaDoc description. I think we'll just refer BCP47 for subtag validation. Or, put the current BCP47 langtag BNF here. I actually think we should update the API doc for Locale class and explain the relationship with BCP47 language tag / what is well-formed/ill-formed and etc. > > - What happens with Builder.setLanguageTag(), if some other setXXX()s > are previously called and they conflict? Are they reset strictly to > setLanguageTag(), or superset tag is created, or an exception? Builder#setLocale and setLanguageTag will overwrite all fields. For example, new Builder().setRegion("US").setLanguageTag("en").create() will return Locale en, not en_US. -Yoshito From dougfelt at google.com Thu Mar 5 11:36:17 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Thu, 05 Mar 2009 19:36:17 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 2 new changesets Message-ID: <20090305193651.51ED3E80B@hg.openjdk.java.net> Changeset: 9889650855f0 Author: dougfelt Date: 2009-03-05 09:09 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/9889650855f0 Start converting tests to new API. ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 874fa1a55377 Author: dougfelt Date: 2009-03-05 11:33 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/874fa1a55377 Update API as agreed during last meeting, revise tests. ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/BaseLocale.java ! src/share/classes/sun/util/locale/InternalLocaleBuilder.java ! src/share/classes/sun/util/locale/InvalidLocaleIdentifierException.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/LocaleExtensions.java ! test/java/util/Locale/LocaleEnhanceTest.java From dougfelt at google.com Thu Mar 5 12:55:46 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Thu, 05 Mar 2009 20:55:46 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: remove tabs Message-ID: <20090305205559.76A2FE823@hg.openjdk.java.net> Changeset: d24b88783708 Author: dougfelt Date: 2009-03-05 12:53 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/d24b88783708 remove tabs ! test/java/util/Locale/LocaleEnhanceTest.java From Naoto.Sato at Sun.COM Thu Mar 5 14:43:51 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Thu, 05 Mar 2009 14:43:51 -0800 Subject: [loc-en-dev] [Fwd: Request for comments: JDK 7 Development Process] Message-ID: <49B055A7.6060003@Sun.COM> Folks, Sorry if you have already received this (btw, I'd encourage all of you to subscribe to jdk7-dev alias), but attached is the JDK7 development process proposal. According to it, the first step to include the locale-enh feature is to write a Feature Proposal and submit it to jdk7-dev list for review. Thanks, -- Naoto Sato -------------- next part -------------- An embedded message was scrubbed... From: Mark Reinhold Subject: Request for comments: JDK 7 Development Process Date: Thu, 26 Feb 2009 14:12:25 -0800 Size: 5344 Url: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090305/2591455d/attachment.mht From y.umaoka at gmail.com Thu Mar 5 15:03:21 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 05 Mar 2009 18:03:21 -0500 Subject: [loc-en-dev] [Fwd: Request for comments: JDK 7 Development Process] In-Reply-To: <49B055A7.6060003@Sun.COM> References: <49B055A7.6060003@Sun.COM> Message-ID: <49B05A39.8070207@gmail.com> Naoto Sato wrote: > Folks, > > Sorry if you have already received this (btw, I'd encourage all of you > to subscribe to jdk7-dev alias), but attached is the JDK7 development > process proposal. According to it, the first step to include the > locale-enh feature is to write a Feature Proposal and submit it to > jdk7-dev list for review. > > Thanks, > > ------------------------------------------------------------------------ > > Subject: > Request for comments: JDK 7 Development Process > From: > Mark Reinhold > Date: > Thu, 26 Feb 2009 14:12:25 -0800 > To: > jdk7-dev at openjdk.java.net > > To: > jdk7-dev at openjdk.java.net > > > I've posted a (partial) first draft, here: > > http://cr.openjdk.java.net/~mr/jdk7-dev-process.html > > This draft covers teams, schedule structure, and the proposal > and review process for features. Still to come are sections > on how to document code/API/specification changes and on the > process for reviewing such changes (i.e., the redesign of > Sun's internal CCC process). > > Comments welcome! > > - Mark > Thanks Sato-san, I understand the process had changed. Do we have any JDK schedule documents open for everyone? We're discussing that we need to submit CCC in mid-March to integrate the locale changes to JDK7. I guess we should post the feature proposal as soon as possible, then design proposal follows, then final review. So.. 1. Submitting feature proposal in this week. 2. Once the feature proposal is approved, we'll submit design proposal - mid March? 3. Once the design proposal is approved and the implementation is ready to go, we'll submit a request for final review - the beginning for April? Is my understanding correct? Thanks, Yoshito From Naoto.Sato at Sun.COM Thu Mar 5 15:18:50 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Thu, 05 Mar 2009 15:18:50 -0800 Subject: [loc-en-dev] [Fwd: Request for comments: JDK 7 Development Process] In-Reply-To: <49B05A39.8070207@gmail.com> References: <49B055A7.6060003@Sun.COM> <49B05A39.8070207@gmail.com> Message-ID: <49B05DDA.7040900@Sun.COM> I think your understanding is correct. To be honest, we don't have any extra information within Sun regarding the JDK7 schedule. Naoto Yoshito Umaoka wrote: > Naoto Sato wrote: >> Folks, >> >> Sorry if you have already received this (btw, I'd encourage all of you >> to subscribe to jdk7-dev alias), but attached is the JDK7 development >> process proposal. According to it, the first step to include the >> locale-enh feature is to write a Feature Proposal and submit it to >> jdk7-dev list for review. >> >> Thanks, >> >> ------------------------------------------------------------------------ >> >> Subject: >> Request for comments: JDK 7 Development Process >> From: >> Mark Reinhold >> Date: >> Thu, 26 Feb 2009 14:12:25 -0800 >> To: >> jdk7-dev at openjdk.java.net >> >> To: >> jdk7-dev at openjdk.java.net >> >> >> I've posted a (partial) first draft, here: >> >> http://cr.openjdk.java.net/~mr/jdk7-dev-process.html >> >> This draft covers teams, schedule structure, and the proposal >> and review process for features. Still to come are sections >> on how to document code/API/specification changes and on the >> process for reviewing such changes (i.e., the redesign of >> Sun's internal CCC process). >> >> Comments welcome! >> >> - Mark >> > Thanks Sato-san, > > I understand the process had changed. Do we have any JDK schedule > documents open for everyone? We're discussing that we need to submit > CCC in mid-March to integrate the locale changes to JDK7. I guess we > should post the feature proposal as soon as possible, then design > proposal follows, then final review. So.. > > 1. Submitting feature proposal in this week. > 2. Once the feature proposal is approved, we'll submit design proposal - > mid March? > 3. Once the design proposal is approved and the implementation is ready > to go, we'll submit a request for final review - the beginning for April? > > Is my understanding correct? > > Thanks, > Yoshito -- Naoto Sato From dougfelt at google.com Thu Mar 5 18:20:38 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Fri, 06 Mar 2009 02:20:38 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Add tests for immutability of sets returned by builder. Message-ID: <20090306022056.42C1BE868@hg.openjdk.java.net> Changeset: 3d77c17573cd Author: dougfelt Date: 2009-03-05 18:18 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/3d77c17573cd Add tests for immutability of sets returned by builder. Minor javadoc changes: - removed NullPointerException comments, these are generally not commented as it's always assumed null parameeters are illegal unless documented otherwise. - revised '@exception' back to '@throw', which is the preferred of the two synonomyous tags. - some language clarification ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java From dougfelt at google.com Thu Mar 5 18:24:16 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Fri, 06 Mar 2009 02:24:16 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: arrgh, remove tabs Message-ID: <20090306022432.1C9D4E871@hg.openjdk.java.net> Changeset: e7571db8ec85 Author: dougfelt Date: 2009-03-05 18:21 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/e7571db8ec85 arrgh, remove tabs ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java From dougfelt at google.com Thu Mar 5 18:45:40 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Fri, 06 Mar 2009 02:45:40 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Clean up javadoc a bit more. Message-ID: <20090306024559.EAE61E888@hg.openjdk.java.net> Changeset: d4762607250e Author: dougfelt Date: 2009-03-05 18:43 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/d4762607250e Clean up javadoc a bit more. ! src/share/classes/java/util/Locale.java From erack at sun.com Fri Mar 6 05:28:01 2009 From: erack at sun.com (Eike Rathke) Date: Fri, 6 Mar 2009 14:28:01 +0100 Subject: [loc-en-dev] Recommendation for language tags in old Locale Message-ID: <20090306132801.GL22880@x22-so4.germany.sun.com> Hi, I browsed http://sites.google.com/site/openjdklocale/ and this mailing list, maybe I overlooked it. Are there recommendations for how to stuff a language tag into the old Locale using 3 fields Language/Country/Variant? e.g., I could imagine that a script belongs more to a language than a country, thus sr-Latn-RS could be transported as 'sr_Latn' in Language, and 'RS' in Country as usual. What about dialects? Should they go into Variant? Thanks Eike -- OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090306/86863fe2/attachment.bin From Naoto.Sato at Sun.COM Fri Mar 6 09:39:50 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 06 Mar 2009 09:39:50 -0800 Subject: [loc-en-dev] Variant display name In-Reply-To: <49AF5D5D.3010204@gmail.com> References: <49AF5D5D.3010204@gmail.com> Message-ID: <49B15FE6.1040306@Sun.COM> IIRC, those are just for "display names" for those variants. I think we should just keep the current behavior, especially we should *not* regard the obsolete ones and current ones as equal when checking the equality of the locales. Thanks, Naoto Yoshito Umaoka wrote: > Hi all, > > While I was investing what to do for Locale display name, I realized > there are 3 kinds of variants have its own name in JDK. > > %%EURO=Euro > %%B=Bokm\u00e5l > %%NY=Nynorsk > > However, this page - > http://java.sun.com/javase/6/docs/technotes/guides/intl/locale.doc.html > - does not contain any supported locales with variant EURO and B. I > have several questions here. > > 1. I think EURO was used long time ago to distinguish the use of legacy > domestic currency from Euro in European locales. But for now, we no > longer have any locales supporting both legacy and Euro. I think it's > OK to leave it there, but do we need any special handling required for > locale canonicalization/or checking equality? > > 2. I think B is also obsolete. Language code "no" is treated as > "Norwegian Bokmal" for now. Can we simply ignore the semantics of > variant B in general? > > 3. The supported locale list contains ja_JP_JP / th_TH_TH. These > locales are canonicalized to ja_JP_u_ca_japanese / th_TH_u_nu_thai by > the new design. Luckily we do not have any display names assigned to > them. For now, I did not propose to add locale keyword key/type display > name support (ICU supports this), because we are not sure how much JDK > i18n service supports them in JDK7 time frame. For display name > purpose, can we simply continue to use variant code JP/TH for now? > > -Yoshito -- Naoto Sato From Naoto.Sato at Sun.COM Fri Mar 6 09:48:32 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 06 Mar 2009 09:48:32 -0800 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag In-Reply-To: <49B01C8A.4020500@gmail.com> References: <49ADF07C.7040207@gmail.com> <49B0181A.3050008@Sun.COM> <49B01C8A.4020500@gmail.com> Message-ID: <49B161F0.5030105@Sun.COM> Sorry, but the current link to 'forLanguageTag()' in the following page is broken: http://sites.google.com/site/openjdklocale/apis/locale Thus I asked the first question. Naoto Yoshito Umaoka wrote: > Naoto Sato wrote: >> Folks, >> >> I have two comments as follows: >> >> - Locale.forLanguageTag(): Please describe how the lenient behavior >> works in the spec. This should not be implementation dependent. > > * Returns a locale for the specified language tag string. If the > * specified language tag contains any non-well-formed subtags, the > first > * such subtag and all following subtags are ignored. > > This is the current JavaDoc description. I think we'll just refer BCP47 > for subtag validation. Or, put the current BCP47 langtag BNF here. I > actually think we should update the API doc for Locale class and explain > the relationship with BCP47 language tag / what is > well-formed/ill-formed and etc. > >> >> - What happens with Builder.setLanguageTag(), if some other setXXX()s >> are previously called and they conflict? Are they reset strictly to >> setLanguageTag(), or superset tag is created, or an exception? > Builder#setLocale and setLanguageTag will overwrite all fields. For > example, > > new Builder().setRegion("US").setLanguageTag("en").create() > > will return Locale en, not en_US. > > -Yoshito -- Naoto Sato From Naoto.Sato at Sun.COM Fri Mar 6 09:51:39 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 06 Mar 2009 09:51:39 -0800 Subject: [loc-en-dev] Locale Display Name with script In-Reply-To: <49AF64CC.8010408@gmail.com> References: <49AF64CC.8010408@gmail.com> Message-ID: <49B162AB.4030208@Sun.COM> I vote for the simpler ones for now. We could change display names after JDK7. BTW, the last paragraph reminds me of a question: do we allow Locale instance creation through the factory method or the builder, without "language"? In BCP47, it is mandatory, otherwise you cannot tell the first two letter code is language or region. I may have asked this question before, but cannot remember the answer. Naoto Yoshito Umaoka wrote: > Below is the current specification of Locale#getDisplayName. >> >> >> getDisplayName >> >> public final java.lang.String *getDisplayName*() >> >> Returns a name for the locale that is appropriate for display to >> the user. This will be the values returned by >> getDisplayLanguage(), getDisplayCountry(), and getDisplayVariant() >> assembled into a single string. The display name will have one of >> the following forms: >> >> language (country, variant) >> >> language (country) >> >> language (variant) >> >> country (variant) >> >> language >> >> country >> >> variant >> >> depending on which fields are specified in the locale. If the >> language, country, and variant fields are all empty, this function >> returns the empty string. >> > A couple days ago, Mark Davis suggested that we may need to make up a > display name not just by concatenating individual fields' display > names. For example, en_US may be displayed as "American English". I'm > not fully supporting this idea for the specific example he raised, but > when we think about script support, we may want to look at two examples > - Simplified Chinese and Traditional Chinese. I want to extend the > existing pattern based display name generation for this reason, but at > the same time, it requires some design changes in LocaleNameProvider. > > Locale display name could be supported via custom LocaleNameProvider > implementation. For now, the contract is that LocaleNameProvider > implementation returns a display name of individual field when JDK does > not have the translation. But Locale#getDisplayName is formatting them > based on the rule described above. Technically, we could add a new API > in LocaleNameProvider which handles a locale name as a whole (e.g. > getDisplayLocale(Locale loc, Locale inLoc)). > > In longer term, we should consider better way to handle this. But I do > not think we can do much for JDK7. So my current proposal is simply add > script display name based on the current rule (with minor extension). > More specfically - > > language (script, country, varinat) > language (script, country) > language (script) > language (country, variant) > language (country) > language (variant) > language > script (country, variant) > script (country) > script (variant) > script > country (variant) > country > variant > > Practically, script without language does not make much sense. We could > prevent such locale instance is created through the builder, but I'm not > sure we really need to do this. I prefer to keep it simple (allows > script only locales). Do you have any preferences? > > -Yoshito > > -- Naoto Sato From y.umaoka at gmail.com Fri Mar 6 10:05:36 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 06 Mar 2009 13:05:36 -0500 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag In-Reply-To: <49B161F0.5030105@Sun.COM> References: <49ADF07C.7040207@gmail.com> <49B0181A.3050008@Sun.COM> <49B01C8A.4020500@gmail.com> <49B161F0.5030105@Sun.COM> Message-ID: <49B165F0.1050805@gmail.com> Naoto Sato wrote: > Sorry, but the current link to 'forLanguageTag()' in the following > page is broken: > > http://sites.google.com/site/openjdklocale/apis/locale > > Thus I asked the first question. I cannot find any good way to put JavaDoc html file to the google site. So I copied the html contents and pasted to the google site document, which broke the link. I'll find out better way to handle this. For now, please scroll down to each method. Thanks, Yoshito From dougfelt at google.com Fri Mar 6 10:18:39 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 6 Mar 2009 10:18:39 -0800 Subject: [loc-en-dev] Locale Display Name with script In-Reply-To: <49B162AB.4030208@Sun.COM> References: <49AF64CC.8010408@gmail.com> <49B162AB.4030208@Sun.COM> Message-ID: <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> The builder defaults language to 'und' Doug On Fri, Mar 6, 2009 at 9:51 AM, Naoto Sato wrote: > I vote for the simpler ones for now. We could change display names after > JDK7. > > BTW, the last paragraph reminds me of a question: do we allow Locale > instance creation through the factory method or the builder, without > "language"? In BCP47, it is mandatory, otherwise you cannot tell the first > two letter code is language or region. I may have asked this question > before, but cannot remember the answer. > > Naoto > > > Yoshito Umaoka wrote: > >> Below is the current specification of Locale#getDisplayName. >> >>> >>> >>> getDisplayName >>> >>> public final java.lang.String *getDisplayName*() >>> >>> Returns a name for the locale that is appropriate for display to >>> the user. This will be the values returned by >>> getDisplayLanguage(), getDisplayCountry(), and getDisplayVariant() >>> assembled into a single string. The display name will have one of >>> the following forms: >>> >>> language (country, variant) >>> >>> language (country) >>> >>> language (variant) >>> >>> country (variant) >>> >>> language >>> >>> country >>> >>> variant >>> >>> depending on which fields are specified in the locale. If the >>> language, country, and variant fields are all empty, this function >>> returns the empty string. >>> >> A couple days ago, Mark Davis suggested that we may need to make up a >> display name not just by concatenating individual fields' display names. >> For example, en_US may be displayed as "American English". I'm not fully >> supporting this idea for the specific example he raised, but when we think >> about script support, we may want to look at two examples - Simplified >> Chinese and Traditional Chinese. I want to extend the existing pattern >> based display name generation for this reason, but at the same time, it >> requires some design changes in LocaleNameProvider. >> >> Locale display name could be supported via custom LocaleNameProvider >> implementation. For now, the contract is that LocaleNameProvider >> implementation returns a display name of individual field when JDK does not >> have the translation. But Locale#getDisplayName is formatting them based on >> the rule described above. Technically, we could add a new API in >> LocaleNameProvider which handles a locale name as a whole (e.g. >> getDisplayLocale(Locale loc, Locale inLoc)). >> >> In longer term, we should consider better way to handle this. But I do >> not think we can do much for JDK7. So my current proposal is simply add >> script display name based on the current rule (with minor extension). More >> specfically - >> >> language (script, country, varinat) >> language (script, country) >> language (script) >> language (country, variant) >> language (country) >> language (variant) >> language >> script (country, variant) >> script (country) >> script (variant) >> script >> country (variant) >> country >> variant >> >> Practically, script without language does not make much sense. We could >> prevent such locale instance is created through the builder, but I'm not >> sure we really need to do this. I prefer to keep it simple (allows script >> only locales). Do you have any preferences? >> >> -Yoshito >> >> >> > > -- > Naoto Sato > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090306/d46a442f/attachment.html From Naoto.Sato at Sun.COM Fri Mar 6 10:27:19 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 06 Mar 2009 10:27:19 -0800 Subject: [loc-en-dev] Locale Display Name with script In-Reply-To: <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> References: <49AF64CC.8010408@gmail.com> <49B162AB.4030208@Sun.COM> <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> Message-ID: <49B16B07.3040206@Sun.COM> Ah, yes. Thank you. Naoto Doug Felt wrote: > The builder defaults language to 'und' > > Doug > > On Fri, Mar 6, 2009 at 9:51 AM, Naoto Sato > wrote: > > I vote for the simpler ones for now. We could change display names > after JDK7. > > BTW, the last paragraph reminds me of a question: do we allow Locale > instance creation through the factory method or the builder, without > "language"? In BCP47, it is mandatory, otherwise you cannot tell > the first two letter code is language or region. I may have asked > this question before, but cannot remember the answer. > > Naoto > > > Yoshito Umaoka wrote: > > Below is the current specification of Locale#getDisplayName. > > > > getDisplayName > > public final java.lang.String *getDisplayName*() > > Returns a name for the locale that is appropriate for > display to > the user. This will be the values returned by > getDisplayLanguage(), getDisplayCountry(), and > getDisplayVariant() > assembled into a single string. The display name will > have one of > the following forms: > > language (country, variant) > > language (country) > > language (variant) > > country (variant) > > language > > country > > variant > > depending on which fields are specified in the locale. If the > language, country, and variant fields are all empty, this > function > returns the empty string. > > A couple days ago, Mark Davis suggested that we may need to make > up a display name not just by concatenating individual fields' > display names. For example, en_US may be displayed as "American > English". I'm not fully supporting this idea for the specific > example he raised, but when we think about script support, we > may want to look at two examples - Simplified Chinese and > Traditional Chinese. I want to extend the existing pattern > based display name generation for this reason, but at the same > time, it requires some design changes in LocaleNameProvider. > > Locale display name could be supported via custom > LocaleNameProvider implementation. For now, the contract is > that LocaleNameProvider implementation returns a display name of > individual field when JDK does not have the translation. But > Locale#getDisplayName is formatting them based on the rule > described above. Technically, we could add a new API in > LocaleNameProvider which handles a locale name as a whole (e.g. > getDisplayLocale(Locale loc, Locale inLoc)). > > In longer term, we should consider better way to handle this. > But I do not think we can do much for JDK7. So my current > proposal is simply add script display name based on the current > rule (with minor extension). More specfically - > > language (script, country, varinat) > language (script, country) > language (script) > language (country, variant) > language (country) > language (variant) > language > script (country, variant) > script (country) > script (variant) > script > country (variant) > country > variant > > Practically, script without language does not make much sense. > We could prevent such locale instance is created through the > builder, but I'm not sure we really need to do this. I prefer > to keep it simple (allows script only locales). Do you have any > preferences? > > -Yoshito > > > > > -- > Naoto Sato > > -- Naoto Sato From y.umaoka at gmail.com Fri Mar 6 10:30:13 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 06 Mar 2009 13:30:13 -0500 Subject: [loc-en-dev] Locale Display Name with script In-Reply-To: <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> References: <49AF64CC.8010408@gmail.com> <49B162AB.4030208@Sun.COM> <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> Message-ID: <49B16BB5.7000702@gmail.com> Doug Felt wrote: > The builder defaults language to 'und' > Hmmm.. I think I should clarify this.. Builder defaults language to empty string, but when you convert it to a language tag, "und" is used. For example, Locale loc = new Builder().setRegion("US").create(); String locStr = loc.toString(); String langtag = loc.toLanguageTag(); In this code, locStr -> _US langtag -> und-us If we want to avoid this, one possible option is to mandate non-empty language in Builder#create(). But, we cannot use IllegalArgumentException here obviously! -Yoshito From dougfelt at google.com Fri Mar 6 10:30:31 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 6 Mar 2009 10:30:31 -0800 Subject: [loc-en-dev] Error handling in LocaleBuilder and forLanguageTag In-Reply-To: <49B165F0.1050805@gmail.com> References: <49ADF07C.7040207@gmail.com> <49B0181A.3050008@Sun.COM> <49B01C8A.4020500@gmail.com> <49B161F0.5030105@Sun.COM> <49B165F0.1050805@gmail.com> Message-ID: <146f39a80903061030h330ea60ax735754d1c9ceab00@mail.gmail.com> This time, I caused the problem... I updated the docs last night but haven't found a good way to use google sites with the javadoc generated by the tool. I need to see if there's a way to convince the tool create links appropriate to the sites environment. On Fri, Mar 6, 2009 at 10:05 AM, Yoshito Umaoka wrote: > Naoto Sato wrote: > >> Sorry, but the current link to 'forLanguageTag()' in the following page is >> broken: >> >> http://sites.google.com/site/openjdklocale/apis/locale >> >> Thus I asked the first question. >> > I cannot find any good way to put JavaDoc html file to the google site. So > I copied the html contents and pasted to the google site document, which > broke the link. I'll find out better way to handle this. For now, please > scroll down to each method. > > Thanks, > Yoshito > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090306/1269a5c9/attachment.html From Naoto.Sato at Sun.COM Fri Mar 6 10:33:27 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 06 Mar 2009 10:33:27 -0800 Subject: [loc-en-dev] Recommendation for language tags in old Locale In-Reply-To: <20090306132801.GL22880@x22-so4.germany.sun.com> References: <20090306132801.GL22880@x22-so4.germany.sun.com> Message-ID: <49B16C77.4010509@Sun.COM> Hi Eike, I don't think there is any recommendation, but I believe that the language tags should only be dealt with the proposed new factory method or builder. Otherwise, unexpected/unwanted issues would arise. Thanks, Naoto Eike Rathke wrote: > Hi, > > I browsed http://sites.google.com/site/openjdklocale/ and this mailing > list, maybe I overlooked it. Are there recommendations for how to stuff > a language tag into the old Locale using 3 fields Language/Country/Variant? > > e.g., I could imagine that a script belongs more to a language than > a country, thus sr-Latn-RS could be transported as 'sr_Latn' in > Language, and 'RS' in Country as usual. What about dialects? Should they > go into Variant? > > Thanks > Eike > -- Naoto Sato From dougfelt at google.com Fri Mar 6 10:42:51 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 6 Mar 2009 10:42:51 -0800 Subject: [loc-en-dev] Locale Display Name with script In-Reply-To: <49B16BB5.7000702@gmail.com> References: <49AF64CC.8010408@gmail.com> <49B162AB.4030208@Sun.COM> <146f39a80903061018t28fc94cfg7f26e14cce28b988@mail.gmail.com> <49B16BB5.7000702@gmail.com> Message-ID: <146f39a80903061042u3a8578b4heb3d900964989932@mail.gmail.com> Yes, sorry about being imprecise. That's one of the ways in which this is a Locale builder and not a 'BCP 47 langtag builder'. Thanks for the clarification Yoshito. Doug On Fri, Mar 6, 2009 at 10:30 AM, Yoshito Umaoka wrote: > Doug Felt wrote: > >> The builder defaults language to 'und' >> >> Hmmm.. I think I should clarify this.. > Builder defaults language to empty string, but when you convert it to a > language tag, "und" is used. For example, > > Locale loc = new Builder().setRegion("US").create(); > String locStr = loc.toString(); > String langtag = loc.toLanguageTag(); > > > In this code, > > locStr -> _US > langtag -> und-us > > If we want to avoid this, one possible option is to mandate non-empty > language in Builder#create(). But, we cannot use IllegalArgumentException > here obviously! > > -Yoshito > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090306/d4e0eb12/attachment.html From y.umaoka at gmail.com Fri Mar 6 10:50:45 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 06 Mar 2009 13:50:45 -0500 Subject: [loc-en-dev] Recommendation for language tags in old Locale In-Reply-To: <20090306132801.GL22880@x22-so4.germany.sun.com> References: <20090306132801.GL22880@x22-so4.germany.sun.com> Message-ID: <49B17085.3030600@gmail.com> Eike Rathke wrote: > Hi, > > I browsed http://sites.google.com/site/openjdklocale/ and this mailing > list, maybe I overlooked it. Are there recommendations for how to stuff > a language tag into the old Locale using 3 fields Language/Country/Variant? > > e.g., I could imagine that a script belongs more to a language than > a country, thus sr-Latn-RS could be transported as 'sr_Latn' in > Language, and 'RS' in Country as usual. What about dialects? Should they > go into Variant? > > Thanks > Eike > In the past, some folks try to distinguish a language from a locale and some other folks thinks it is not worth making clear distinction. We do not have any agreed consensus yet. But, not matter you think language tag cannot be used for cultural preferences (locale), it can be used for decide the default cultural preference set (for example, see w3c i18n article - http://www.w3.org/International/questions/qa-accept-lang-locales) The language tag - "sr-Latn-RS" - indicate Serbian written in Latin script used by Serbia and Montenegro. If we try to interpret this as a locale id, it means cultural preferences using Serbian written in Latin used by Serbia and Montenegro for localizable names AND cultural conventions (such as calendar system, currency, measurement units...) commonly used in Serbia and Montenegro. Java Locale is an identifier for locale. So "sr_Latn" and "sr_Latn_RS" could result different behaviors in some Java locale services. In BCP47, if you need to distinguish a dialect from another, registering the dialect as a variant would be the right approach. In Locale, it is mapped to variant field. -Yoshito From dougfelt at google.com Fri Mar 6 14:02:09 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Fri, 06 Mar 2009 22:02:09 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Class javadoc changes to add overview of new APIs, in progress. Message-ID: <20090306220228.93146E99B@hg.openjdk.java.net> Changeset: c9b1335f4476 Author: dougfelt Date: 2009-03-06 13:59 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/c9b1335f4476 Class javadoc changes to add overview of new APIs, in progress. ! src/share/classes/java/util/Locale.java From y.umaoka at gmail.com Sun Mar 8 19:00:26 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Sun, 08 Mar 2009 22:00:26 -0400 Subject: [loc-en-dev] Norwegian resource bundle lookup Message-ID: <49B4783A.8080503@gmail.com> A couple of months ago, Masayoshi posted a counter proposal for Norwegian lookup order below. > The *_NO look-up sequences should be consistent with the no and nb > ones. So > the sequences should be: > > no_NO -> nb_NO -> no -> nb > no_NO_NY -> nn_NO -> no_NO -> nn -> no > nn_NO -> no_NO_NY -> nn -> no > nb_NO -> no_NO -> nb -> no For Norwegian cases, we also need to consider what kind of things done by Java users with the current JDK. First of all, new Locale ("nb", "NO") or new Locale ("nn", "NO") is legal and works as you expect even with JDK 6. Because Web browsers already sending Accept-Language "nb", "nb-no", "nn", "nn-no", such Locales are created by the standard J2EE implementation. Application developers have several design options to handle them as they want. One solution is obviously providing bundles using language code "nb" and "nn" in addition to "no" (I also saw such implementation in a product). JDK documentation clearly stated that a language of locale ID "no_NO" is Norwegian Bokm?l. Also, Norwegian Bokm?l is more widely used in Norway, so Java bundles no_NO in existing Java applications are most likely contain Norwegian Bokm?l contents. In Java, a language of locale ID "no_NO_NY" is Norwegian Nyrnorsk. If we can replace it with "nn_NO", it would be nice, but we cannot do this for backward compatibility reasons. Masayoshi's counter proposal for lookup order starting no_NO_NY is below - no_NO_NY -> nn_NO -> no_NO -> nn -> no I do not see any problems with the second candidate - nn_NO, because no_NO_NY was in JDK for locale Norwegian (Nynorsk) - Norway. "nn_NO" is the most appropriate representation if we can forget about the backward compatibility support. However, the third candidate "no_NO" looks problematic. As I described above, the current JDK documentation clearly states no_NO is for Norwegian (Bokm?l) - Norway. And many folks actually expect no_NO contains Norwegian Bokm?l contents. I think Masayoshi assumed that people who uses language code "nn" for Norweigan Nyrnosk always uses "nb" for Norwegian (Bokm?l). But I do not think this is not true as I explained above. If we interpret no_NO_NY is an alias of nn_NO, the lookup order should be below - nn_NO_NY -> nn_NO -> nn However, above list breaks the backward compatibility. In Java 6, if you start with no_NO_NY, no_NO and no are included in the lookup path. So we need to put them in the candidate list. For these reasons, I believe the right order, which fully support the people's expectation is below - nn_NO_NY -> nn_NO -> nn -> no_NO -> no When you start from nn_NO, Masayoshi's proposal looks OK, but I think inserting no_NO before no is better for consistency with the case starting with no_NO_NY. (In other words, we interpret no_NO_NY and nn_NO are equivalent) nn_NO -> no_NO_NY -> nn -> no (Masayoshi) nn_NO -> no_NO_NY -> nn -> no_NO -> no (Yoshito) For the case starting from no_NO/nb_NO, the order of no and nb does not matter practically. I still prefer "nb" always comes before "no" (because "nb" is more specific), but I do not see any impacts to existing applications. We also need to consider when language only locale "no", "nb" or "nn" is requested. Norwegian locales with country code does lookup between "no" and "nb"/"nn", I think we may want to do the similar thing also for language only locales. More specifically - no -> nb nb -> no nn -> no The first one is "default specific language" fallback for a macro language. The second and third are "macro language" fallback for a specific language belongs to the macro language. The initial design draft sorted out all the characteristics of things to be considered in systematical manner. But such design require data (macro language and specific language mappings) which we do not want to maintain in JDK (for stability reasons). Technically, such handling can be done by overriding ResourceBundle.Control and implements your own getCandidateLocales, so I think we exclude this from JDK 7 proposal. -Yoshito From y.umaoka at gmail.com Sun Mar 8 19:55:47 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Sun, 08 Mar 2009 22:55:47 -0400 Subject: [loc-en-dev] A ISO639 3-letter code which has a 2-letter code Message-ID: <49B48533.9040505@gmail.com> The current JavaDoc for Locale constructors defines the language parameter is lowercase two-letter ISO-639 code. The actual implementation convert the language code string to lowercase, but it does not check the length nor it's a valid ISO639.1 language code. So you can use any arbitrary string as a language. For supporting BCP47 language tag, we should update the description and explain that valid BCP47 langtag can be used, also in the existing constructor. (This change itself does not introduce any implementation changes.. just documentation.) The Locale constructor maps input language code "he" to "iw" for stability reason. No matter you use "he" or "iw" as language code, Locale#getLanguage() returns "iw" for Hebrew language. This implementation is tricky, but it also prevent two canonically equivalent Locales are created via APIs. Now, we need to figure out what to do with ISO639 3-letter language codes which have ISO639.1 2-letter codes. For example, English has ISO639.1 code "en" as well as ISO639.2/639.3 code "eng". BCP47 itself prohibit a 3 letter code is used for a language if it has 2-letter version. I think there are several possible options for this problem. In Locale constructors - 1. Do nothing. Locale constructors do not check if an input 3-letter language code has a 2-letter version. 2. Map. Locale constructors map 3-letter language code if there is 2-letter version available. In Builder#setLanguage 1. Do nothing. Builder only checks if the given language code is well-formed (2*8ALPHA) 2. Map. Builder maps 3-letter language code if there is 2-letter version available. 3. Invalidate. Builder check if the input 3-letter language code has a 2-letter version and throws an exception if exists. In Locale#toLanguageTag 1. Do nothing. toLanguageTag() only checks if the given language code is well-formed (2*8ALPHA) 2. Map. toLanguageTag() maps 3-letter language code if there is 2-letter version available. I think 3-to-2 mapping in ISO639 is practically frozen. If this is true, we do not have any concerns for the mapping. I prefer to prevent such canonically equivalent Locales are created (that is, do the mapping when a Locale is created by constructors and builders). Builder is a new API, so we can do whatever we want. But without making this change in the constructors, it does not make sense. If we can ignore the behavior change, I prefer to do the mapping in the locale constructors - more specifically - new Locale("eng").getLanguage() changes from "en" to "eng". (How much do we need to care about backward compatibility? The use of 3-letter code in Locale constructor was illegal. Even there are applications setting 3-letter language code in Locale, I think they have no reasons to use 3-letter codes if there are 2-letter correspondings...) If this behavior change in Locale constructors is not acceptable, I prefer to do nothing everywhere. In this case, JDK just tream "en_US" and "eng_US" as different Locales and toLanguageTag produces illegal BCP47 tags. Any suggestions? -Yoshito From y.umaoka at gmail.com Sun Mar 8 20:10:37 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Sun, 08 Mar 2009 23:10:37 -0400 Subject: [loc-en-dev] Removing Locale#getPrivateUse / Builder#setPrivateUse from the proposed APIs Message-ID: <49B488AD.10105@gmail.com> Hi folks, Doug and I had a long discussion last week. As the result, we agreed to remove these methods and make private use as a part of "extensions" and use Locale#getExtension('x') to access the value / Builder#setExtension('x', privateuseVal) to set the value. The original question was whether Locale#getPrivateUse should return null or empty string. I'm attaching the note below - > Doug Felt wrote: >> It doesn't matter what the implementation does internally, it matters >> what the user sees. I still believe it makes sense to return empty >> string for the 'base locale' fields and null for everything else. >> Either that, or return the empty string / empty set everywhere >> instead of null. >> I don't find the putative distinction between private use and >> extensions persuasive. I don't think users will find this >> distinction as clear as you do. >> >> Doug >> >> On Thu, Mar 5, 2009 at 8:10 PM, Yoshito Umaoka > > wrote: >> >> Hi Doug, >> >> Last time we discussed about this, I agreed to change it to return >> null instead of the empty string. Now I feel it's not what I >> want, because we changed the semantics of null argument in >> Builder#setXXX. You pointed out that the behavior is consistent >> with getExtension. But it differs from private use, because >> getExtension is paired with getExtensionKeys. Like what I'm doing >> in the implementation code with Builder, when you set entire >> contents of a given intput locale, I call setXXX(loc.getXXX()) for >> all fields other than extensions. For extensions, I call >> getExtensionKeys first to see if any extensions are available (I'm >> doing null check here), then call getExtension for each key (in >> this case, I do not need to check null, because it's always >> there..). So, obviously, I do different operation for extensions >> only. >> >> -Yoshito >> >> > OK. I see there are two interpretations. > > 1. BCP47 extensions are technically unordered map. It also defines > canonical representation, but it does not disallow extension 'b' comes > before extension 'a'. On the other hand, private use must be always > the last subtags and slightly relaxed syntactical requirement. When > you directly map the design concept to Locale class, extensions and > private use are separated. > > 2. The java.util.Locale extensions are simply providing optional > fields. Each field has its name and value. Private use is a special > type of field, which is not reserved by anyone. In this case, > information stored in LocaleExtension in the current implementation > are single plain map. > > > My current design proposal is based on the 1st interpretation. I > wanted to match the BCP47 language tag structure in java.util.Locale. > I thought it is better for Java user to understand what these new > items are trying to achieve. > > Your comments seems to base on the 2nd interpretation. If we design > like this way, we do not need Locale#getPrivateUse. Instead, we > probably want to define - public static final char PRIVATEUSE = 'x' > and Locale#getExtensions(PRIVATEUSE) to access the BCP47 private use > corresponding. > > Mark also questioned what Locale#getPrivateUse for. I'm start feeling > the distinction between BCP47 extensions and privateuse in Locale > method. Having the independent method just helps some users who > understand BCP47 structure to get the better insight. But at the same > time, for those 'advanced' users, they should be able to understand > why it is handled as an extension in Locale (as the 2nd interpretation). > > So, here is what I want to do. I'll remove Locale#getPrivateUse() / > Builder#setPrivateUse(String). Instead, I'll add 'public static final > char PRIVATEUSE = 'x'; ' in Locale and use > getExtension/Builder#setExtension to get/set the field. Do you have > any objections to this approach? > > Thanks, > Yoshito I've already updated the locale copy of Locale.java and other classes and will update the proposed API doc on Monday. If you have any objections, please post your response. Thanks, Yoshito From dougfelt at google.com Mon Mar 9 18:03:40 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Tue, 10 Mar 2009 01:03:40 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 3 new changesets Message-ID: <20090310010425.7843CEB13@hg.openjdk.java.net> Changeset: 494d2d4443b0 Author: dougfelt Date: 2009-03-09 16:18 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/494d2d4443b0 Updates from Yoshito (removed private use API, fixed some bugs). Updated tests to match API and implementation changes. ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/BaseLocale.java ! src/share/classes/sun/util/locale/InternalLocaleBuilder.java ! src/share/classes/sun/util/locale/InvalidLocaleIdentifierException.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/LocaleExtensions.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: fb1c22979dd5 Author: dougfelt Date: 2009-03-09 16:19 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/fb1c22979dd5 Remove tabs. (why aren't settings sticking?) ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 4561647ab308 Author: dougfelt Date: 2009-03-09 18:01 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/4561647ab308 More work on class docs for Locale. ! src/share/classes/java/util/Locale.java From y.umaoka at gmail.com Mon Mar 9 22:23:39 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 10 Mar 2009 01:23:39 -0400 Subject: [loc-en-dev] The latest proposed APIs for review Message-ID: <49B5F95B.8030804@gmail.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090310/917ceef3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1918 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090310/917ceef3/attachment.bin From y.umaoka at gmail.com Tue Mar 10 10:10:21 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 10 Mar 2009 13:10:21 -0400 Subject: [loc-en-dev] Design notes Message-ID: <49B69EFD.4050007@gmail.com> I put some design notes in the project site - http://sites.google.com/site/openjdklocale/design-notes -Yoshito From y.umaoka at gmail.com Wed Mar 11 06:08:48 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Wed, 11 Mar 2009 09:08:48 -0400 Subject: [loc-en-dev] March 10 - JDK7 API review meeting minutes Message-ID: <49B7B7E0.9020008@gmail.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090311/129e7e12/attachment.html From dougfelt at google.com Wed Mar 11 14:49:22 2009 From: dougfelt at google.com (Doug Felt) Date: Wed, 11 Mar 2009 14:49:22 -0700 Subject: [loc-en-dev] getLocaleKeywordKeys/Value In-Reply-To: <146f39a80903111423v4ef25960qdd0cf3885d539e1e@mail.gmail.com> References: <146f39a80903111423v4ef25960qdd0cf3885d539e1e@mail.gmail.com> Message-ID: <146f39a80903111449x59c843a1n24c771760bbe1a20@mail.gmail.com> Yesterday during the conference call there was an objection raised to providing LDML-extension-specific API on Locale. The argument against, as I understand it, is that in the future there might be other extensions, and Locale might need to support them. Special casing support for the LDML extension doesn't look clean. The argument for, as I understand it, is that LDML extensions are in process and will be defined before JDK7 is released, and that these are important for making use of LDML data in the JDK. One suggested compromise was to provide an LDML accessor object so that the LDML-specific API resided on a different class. I think this is not going to work out. It seems to me that we would require an LDML-specific builder as well as an accessor. Locale.Builder currently understands both BCP47 and LDML syntax constraints, so knowledge of the LDML API and constraints would have to be migrated off it. An LDML builder that holds the LDML-specific API is mutable, but ideally the LDML accessor is not (it represents the LDML extension on a Locale in API form, and semantically this is cleaner if it is also immutable, like Locale), so this means two classes per extension, an accessor and a builder (just like there is both a Locale and a Locale.Builder). Builder is currently strict, and I don't think we want to make it strict only for BCP47 and non-strict for extensions. So we'd need to provide API on Builder that allows for imposition of those additional extension constraints from outside. Builder currently provides a public setExtension(String) API. Access to this API without going through an extension builder means it is possible to create language tags that are well-formed from the point of view of BCP47 but that contain ill-formed LDML (or other extension) tags. Thus this API cannot take a String unless it already knows how to syntax check the extension. This API could be changed to take an ExtensionBuilder instead of a String, but then the same problem occurs with setLanguageTag. Since this can take strings containing multiple extensions we'd either need to parameterize the call with extension builders or parameterize the Builder itself with extension syntax checkers. A user-implementable API for extension builders means it is also possible to create different builders for the same extension with conflicting syntax constraints. So I think we'd probably want to implement extension support in the JDK in a non-extensible way. Once we do that, it's baked in anyway, so the question is whether we put the API in Locale and Locale.Builder, or on some other objects. Putting it on other objects makes use of the APIs much more cumbersome, especially as this is the default use. Putting the API on Locale and Locale.Builder doesn't prelude adding other API in the future and makes the use of Locale and the Builder significantly simpler. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090311/461808d5/attachment.html From y.umaoka at gmail.com Thu Mar 12 08:53:59 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 12 Mar 2009 11:53:59 -0400 Subject: [loc-en-dev] getLocaleKeywordKeys/Value In-Reply-To: <146f39a80903111449x59c843a1n24c771760bbe1a20@mail.gmail.com> References: <146f39a80903111423v4ef25960qdd0cf3885d539e1e@mail.gmail.com> <146f39a80903111449x59c843a1n24c771760bbe1a20@mail.gmail.com> Message-ID: <49B93017.6050307@gmail.com> I agree with Doug. I considered a generic type "Extension" and its subclass for "LDMLExtension" to represent the LDML extension while I was working on the early proto-type, but I soon realized that it require downcasting to access LDML keyword values. I thought the API design requiring downcasting was not good. I reconsidered the option and other potential implementations after the conf call, but I ended up the same conclusion with Doug. I think even we design extension as a generic type, it does not mean that Java users can simply integrate their own handler for new extension types, unless we add SPI framework for this. At least for now, we do not see any use cases other than LDML's usage. So adding such framework looks over engineering. As Doug pointed out, it also implies that Builder#setExtension needs to be extensible, but we do not want to break the assumption that Builder only creates well-formed Locales. It's possible, but I do not see any good reasons to build complex framework for things which might be never used. JDK itself is interested in LDML extensions and I think we do not have any objections that we're going to use LDML keywords to represent cultural behavior difference within a single base locale, rather than inventing more proprietary variants. So I think LDML extension has special semantics for JDK. I would like to wrap up this design strategy discussion by next week. If anyone disagree to this, please respond to this ML with actual counter API specification with a JavaDoc. Thanks, Yoshito Doug Felt wrote: > Yesterday during the conference call there was an objection raised to > providing LDML-extension-specific API on Locale. > > The argument against, as I understand it, is that in the future there > might be other extensions, and Locale might need to support them. > Special casing support for the LDML extension doesn't look clean. > > The argument for, as I understand it, is that LDML extensions are in > process and will be defined before JDK7 is released, and that these > are important for making use of LDML data in the JDK. > > One suggested compromise was to provide an LDML accessor object so > that the LDML-specific API resided on a different class. I think this > is not going to work out. > > It seems to me that we would require an LDML-specific builder as well > as an accessor. Locale.Builder currently understands both BCP47 and > LDML syntax constraints, so knowledge of the LDML API and constraints > would have to be migrated off it. An LDML builder that holds the > LDML-specific API is mutable, but ideally the LDML accessor is not (it > represents the LDML extension on a Locale in API form, and > semantically this is cleaner if it is also immutable, like Locale), so > this means two classes per extension, an accessor and a builder (just > like there is both a Locale and a Locale.Builder). > > Builder is currently strict, and I don't think we want to make it > strict only for BCP47 and non-strict for extensions. So we'd need to > provide API on Builder that allows for imposition of those additional > extension constraints from outside. > > Builder currently provides a public setExtension(String) API. Access > to this API without going through an extension builder means it is > possible to create language tags that are well-formed from the point > of view of BCP47 but that contain ill-formed LDML (or other extension) > tags. Thus this API cannot take a String unless it already knows how > to syntax check the extension. This API could be changed to take an > ExtensionBuilder instead of a String, but then the same problem occurs > with setLanguageTag. Since this can take strings containing multiple > extensions we'd either need to parameterize the call with extension > builders or parameterize the Builder itself with extension syntax > checkers. > > A user-implementable API for extension builders means it is also > possible to create different builders for the same extension with > conflicting syntax constraints. > > So I think we'd probably want to implement extension support in the > JDK in a non-extensible way. Once we do that, it's baked in anyway, > so the question is whether we put the API in Locale and > Locale.Builder, or on some other objects. Putting it on other objects > makes use of the APIs much more cumbersome, especially as this is the > default use. Putting the API on Locale and Locale.Builder doesn't > prelude adding other API in the future and makes the use of Locale and > the Builder significantly simpler. > > Doug > From y.umaoka at gmail.com Thu Mar 12 09:04:24 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 12 Mar 2009 12:04:24 -0400 Subject: [loc-en-dev] getLocaleKeywordKeys/getLocaleKeywordValue Message-ID: <49B93288.4070705@gmail.com> In the API review conference call on Tuesday, we agreed that the term "LocaleKeywordXXX" and "Unicode Locale Identifier" might not be appropriate. I'm going to update the name of these APIs: Locale#getLocaleKeywordValue -> getLDMLType Locale#getLocaleKeywordKeys -> getLDMLKeys Builder#setLocaleKeyword -> setLDMLKeyword I'll also add a static definition for LDML extension letter as LDML_EXTENSION_KEY ('u') I attached the new JavaDoc comments and API signature at the end of this message. If you have any problems with the new names, please respond to the ML. -Yoshito /** * New * API Returns the LDML keyword type value associated with * the specified LDML key for this locale. LDML keywords are specified * by the 'u' extension and consist of key/type pairs. The key must be * two alphanumeric characters in length, or an IllegalArgumentException * is thrown. * @param key the LDML key * @return the value ('type') associated with the key, or null if the * locale does not define a value for the key. * @throws IllegalArgumentException if the key is not valid. * @since 1.7 */ public String getLDMLType(String key) /** * New API * Returns the set of keys for LDML keywords defined by this locale, or * null if this locale has no locale extension. The returned set is * immutable. * @return The set of the LDML keys, or null * @since 1.7 */ public Set getLDMLKeys() /** * New API * Sets the Unicode locale type for the given key. If the * type is the empty string, the locale key is removed. * Well-formed keys are strings of two alphanumeric characters. Well-formed * types are strings of three to eight alphanumeric characters. *

* Note:Setting the 'u' extension replaces all LDML * keywords with those defined in the extension. * @param key the key * @param type the Unicode locale type * @return this builder * @throws IllegalArgumentException if key or type * is ill-formed * @see #setExtension(char, String) * @since 1.7 */ public Builder setLDMLKeyword(String key, String type) /** * New API * The key for LDML extension. * @see #getExtension(char) * @see Builder#setExtension(char, String) * @since 1.7 */ static public final char LDML_EXTENSION_KEY = 'u'; From dougfelt at google.com Thu Mar 12 10:02:13 2009 From: dougfelt at google.com (Doug Felt) Date: Thu, 12 Mar 2009 10:02:13 -0700 Subject: [loc-en-dev] getLocaleKeywordKeys/getLocaleKeywordValue In-Reply-To: <49B93288.4070705@gmail.com> References: <49B93288.4070705@gmail.com> Message-ID: <146f39a80903121002s5350f8d2pcc805ce5f037147d@mail.gmail.com> My preference is for Locale.getLDMLExtensionKeys Locale.getLDMLExtensionValue Builder.setLDMLExtensionValue(char key, String value); To my mind, this better communicates that - this is a key/value map - it's subordinate to an extension - it's represented as an LDML extension in the language tag I find the term 'type' unfortunate and misleading, and I don't see a pressing need to push this LDML terminology into the Java arena. I'd rather reuse common terminology that reflects the semantics of the operation. Doug On Thu, Mar 12, 2009 at 9:04 AM, Yoshito Umaoka wrote: > In the API review conference call on Tuesday, we agreed that the term > "LocaleKeywordXXX" and "Unicode Locale Identifier" might not be appropriate. > I'm going to update the name of these APIs: > > Locale#getLocaleKeywordValue -> getLDMLType > Locale#getLocaleKeywordKeys -> getLDMLKeys > Builder#setLocaleKeyword -> setLDMLKeyword > > I'll also add a static definition for LDML extension letter as > LDML_EXTENSION_KEY ('u') > > I attached the new JavaDoc comments and API signature at the end of this > message. If you have any problems with the new names, please respond to the > ML. > > -Yoshito > > /** > * New > * API Returns the LDML keyword type value associated with > * the specified LDML key for this locale. LDML keywords are specified > * by the 'u' extension and consist of key/type pairs. The key must be > * two alphanumeric characters in length, or an IllegalArgumentException > * is thrown. > * @param key the LDML key > * @return the value ('type') associated with the key, or null if the > * locale does not define a value for the key. > * @throws IllegalArgumentException if the key is not valid. > * @since 1.7 > */ > public String getLDMLType(String key) > > /** > * New > API > * Returns the set of keys for LDML keywords defined by this locale, or > * null if this locale has no locale extension. The returned set is > * immutable. > * @return The set of the LDML keys, or null > * @since 1.7 > */ > public Set getLDMLKeys() > /** > * New > API > * Sets the Unicode locale type for the given key. If the > * type is the empty string, the locale key is removed. > * Well-formed keys are strings of two alphanumeric characters. > Well-formed > * types are strings of three to eight alphanumeric characters. > *

> * Note:Setting the 'u' extension replaces all LDML > * keywords with those defined in the extension. > * @param key the key > * @param type the Unicode locale type > * @return this builder > * @throws IllegalArgumentException if key or > type > * is ill-formed > * @see #setExtension(char, String) > * @since 1.7 > */ > public Builder setLDMLKeyword(String key, String type) > > /** > * New > API > * The key for LDML extension. > * @see #getExtension(char) > * @see Builder#setExtension(char, String) > * @since 1.7 > */ > static public final char LDML_EXTENSION_KEY = 'u'; > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090312/c7c7ea06/attachment.html From Naoto.Sato at Sun.COM Thu Mar 12 12:34:54 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Thu, 12 Mar 2009 12:34:54 -0700 Subject: [loc-en-dev] getLocaleKeywordKeys/getLocaleKeywordValue In-Reply-To: <49B93288.4070705@gmail.com> References: <49B93288.4070705@gmail.com> Message-ID: <49B963DE.4080601@Sun.COM> Looks like there are still a couple of occurrences of the term "Unicode locale". Thanks, Naoto Yoshito Umaoka wrote: > In the API review conference call on Tuesday, we agreed that the term > "LocaleKeywordXXX" and "Unicode Locale Identifier" might not be > appropriate. I'm going to update the name of these APIs: > > Locale#getLocaleKeywordValue -> getLDMLType > Locale#getLocaleKeywordKeys -> getLDMLKeys > Builder#setLocaleKeyword -> setLDMLKeyword > > I'll also add a static definition for LDML extension letter as > LDML_EXTENSION_KEY ('u') > > I attached the new JavaDoc comments and API signature at the end of > this message. If you have any problems with the new names, please > respond to the ML. > > -Yoshito > > /** > * New > * API Returns the LDML keyword type value associated with > * the specified LDML key for this locale. LDML keywords are specified > * by the 'u' extension and consist of key/type pairs. The key must be > * two alphanumeric characters in length, or an IllegalArgumentException > * is thrown. > * @param key the LDML key > * @return the value ('type') associated with the key, or null if the > * locale does not define a value for the key. > * @throws IllegalArgumentException if the key is not valid. > * @since 1.7 > */ > public String getLDMLType(String key) > > /** > * New > API > * Returns the set of keys for LDML keywords defined by this locale, or > * null if this locale has no locale extension. The returned set is > * immutable. > * @return The set of the LDML keys, or null > * @since 1.7 > */ > public Set getLDMLKeys() > /** > * New > API > * Sets the Unicode locale type for the given key. If the > * type is the empty string, the locale key is removed. > * Well-formed keys are strings of two alphanumeric characters. > Well-formed > * types are strings of three to eight alphanumeric characters. > *

> * Note:Setting the 'u' extension replaces all LDML > * keywords with those defined in the extension. > * @param key the key > * @param type the Unicode locale type > * @return this builder > * @throws IllegalArgumentException if key or > type > * is ill-formed > * @see #setExtension(char, String) > * @since 1.7 > */ > public Builder setLDMLKeyword(String key, String type) > > /** > * New > API > * The key for LDML extension. > * @see #getExtension(char) > * @see Builder#setExtension(char, String) > * @since 1.7 > */ > static public final char LDML_EXTENSION_KEY = 'u'; > -- Naoto Sato From y.umaoka at gmail.com Thu Mar 12 12:40:27 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 12 Mar 2009 15:40:27 -0400 Subject: [loc-en-dev] getLocaleKeywordKeys/getLocaleKeywordValue In-Reply-To: <146f39a80903121002s5350f8d2pcc805ce5f037147d@mail.gmail.com> References: <49B93288.4070705@gmail.com> <146f39a80903121002s5350f8d2pcc805ce5f037147d@mail.gmail.com> Message-ID: <49B9652B.1050503@gmail.com> Doug Felt wrote: > My preference is for > > Locale.getLDMLExtensionKeys > Locale.getLDMLExtensionValue > Builder.setLDMLExtensionValue(char key, String value); > > To my mind, this better communicates that > - this is a key/value map > - it's subordinate to an extension > - it's represented as an LDML extension in the language tag > > I find the term 'type' unfortunate and misleading, and I don't see a > pressing need to push this LDML terminology into the Java arena. I'd > rather reuse common terminology that reflects the semantics of the > operation. > > Doug Because I also added - public static final char LMDL_EXTENSION_KEY = 'u', I was worrying about if someone get confused with getLDMLExtensionXXX. I do not like the term Keyword key and "type", but if we say "getLDMLExtensionValue", it looks like a value associated with LDML_EXTENSION_KEY. So, how about this? public static final char PRIVATE_USE_EXTENSION = 'x'; // changed from PRIVATE_USE_KEY public static final char LDML_EXTENSION = 'u'; // changed from LOCALE_EXTENSION_KEY Then, Locale.getLDMLExtensionKeys ( <- getLDMLKeys) Locale.getLDMLExtensionValue ( <- getLDMLType) Builder.setLDMLExtensionValue ( <- setLDMLKeyword) If no objections, I'll make the name changes. -Yoshito From y.umaoka at gmail.com Thu Mar 12 12:41:06 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 12 Mar 2009 15:41:06 -0400 Subject: [loc-en-dev] getLocaleKeywordKeys/getLocaleKeywordValue In-Reply-To: <49B963DE.4080601@Sun.COM> References: <49B93288.4070705@gmail.com> <49B963DE.4080601@Sun.COM> Message-ID: <49B96552.1020505@gmail.com> Naoto Sato wrote: > Looks like there are still a couple of occurrences of the term > "Unicode locale". > > Thanks, > Naoto Thanks. I'll scan it again and will update them. -Yoshito From y.umaoka at gmail.com Thu Mar 12 13:12:14 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 12 Mar 2009 16:12:14 -0400 Subject: [loc-en-dev] JDK 7 Development Process question Message-ID: <49B96C9E.8020805@gmail.com> > > I've posted a (partial) first draft, here: > > http://cr.openjdk.java.net/~mr/jdk7-dev-process.html > > This draft covers teams, schedule structure, and the proposal > and review process for features. Still to come are sections > on how to document code/API/specification changes and on the > process for reviewing such changes (i.e., the redesign of > Sun's internal CCC process). > I'm currently working for the Locale Enhancement project sponsored by the Internationalization group. I read your proposal above and have some questions. > To propose a new Feature for inclusion in the release, the first step is > to write up a Feature Proposal and circulate it to the jdk7-dev list or > other lists, as appropriate, for comment and feedback. (A template will > be provided; it will look much like a traditional Sun "one pager" > document.) > > When you're ready, submit your proposal to the Release Team for initial > review and approval. The RT will evaluate your proposal and decide > whether it merits inclusion in the release. > > A Feature, once approved, is subject to two further approval steps: > > - Design Review: Once an overall approach and design is complete it > should be submitted to the Design Team for review. > > - Final Review: When the Feature is nearly ready for integration it > should be submitted to the Design Team for review and to the Release > Team for final approval and targeting to a specific milestone build. > > Owners of Features already approved for JDK 7 will be asked to write and > publish a Feature Proposal, but in most cases this can be constructed > from existing documents, e.g., Sun's internal JDK feature-planning > database or team-specific one-pagers. Previously-approved Features will > be subject only to the Final Review step. > When are you going to migrate to this process described above? Our project wants to propose a new Feature to JDK7, and I was told from a member of the Internationalization group working for Sun that we're supposed to submit a CCC. Then he told me that the process will be changed soon and referred your note above recently. Could you advice us what we're supposed to do for proposing a new feature to JDK7 now? -Yoshito Umaoka (OpenJDK Locale Enhancement Project) From y.umaoka at gmail.com Thu Mar 12 21:22:07 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 13 Mar 2009 00:22:07 -0400 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation Message-ID: <49B9DF6F.6090300@gmail.com> Hi folks The very first proposal suggested that locale service look up is done by base locale, then a service provider may or may not use information taken from extensions. For example, NumberFormat#getInstance(Locale) look for a NumberFormatServiceProvider implementation which support the Locale if the support is not available in JDK. The set of Locales supported by a LocaleServiceProvider is resolved by an array of Locales returned by getAvailableLocales implemented by each provider. In this scenario, the original design proposal suggested to compare a Locale returned by getAvailableLocales with the requested Locale only for the base locale portion (language, script, region and variant). We did not look into this area in detail, because we tried to wrap up the APIs in Locale itself first. I noticed there is a potential problem in this scenario. The existing LocaleServiceProvider implementations do not know about the extensions. If you have two Locales with the same base locale, but one with no extensions, another with LDML extensions such as nu=arab (number system is Arabic). For these two Locales, localeA.equals(localeB) returns false, because they are different. If an existing LocaleServiceProvider implementation depends on Locale#equals, it may not work as expected (I thing it's not practical, but possible...) Of course, even a LocaleServiceProvider return null, it does not cause any disaster (because it's the contract - for Locale which cannot be handled by a LocaleServicePoriver implementation, it can return null, then JDK has a fallback logic.) First of all, do we care this potential compatibility problem? This happens - if someone request a Locale with an extension and if the Locale is not supported by JDK and if its base locale is supported by a custom SPI implementation and if the SPI implementation depends on Locale#equals to identify a Locale.. Even those ifs are all true, it still return a service object (but fallback is involved). If we think we cannot break this, then, we still have several options. Option 1: If a LocaleServiceProvider claims that the requested Locale's base locale is supported, then, JDK calls the provider implementation with full Locale (including extensions). If it returns null, JDK tries the requested Locale's base locale only. Option 2: Add parallel APIs in SPI - for example, in addition to NumberFormatProvider#getNumberInstance(Locale), add a method NumberFormatProvider#getNumberInstanceEx(Locale). JDK calls "Ex" version with extension (the default implementation is to return null), then if it returns null, call regular version without extensions. Well, these are somewhat ugly. So if possible, I'd like to ignore this potential compatibility issue. Do you have any opinions? While thinking various scenarios, I'm feeling that we should provide an easy way to compare two locales excluding exceptions. I proposed getBaseLocale before because I thought it might have a good use case. I'm considering such API again. Actually, Locale#hasSameBaseLocale(Locale) would do for this purpose (do not need to create a Locale). Thanks, Yoshito From Naoto.Sato at Sun.COM Fri Mar 13 10:59:53 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 13 Mar 2009 10:59:53 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49B9DF6F.6090300@gmail.com> References: <49B9DF6F.6090300@gmail.com> Message-ID: <49BA9F19.4050304@Sun.COM> Umaoka-san, I don't think this is a compatibility issue, because the existing SPI implementations should still work compatible with the locales without extensions. Possible issue would only arise with the new locales. BTW, current SPI implementation invocation already involves fallback itself. i.e., say the request locale is xx_YY_foo_bar, and one SPI provider implements xx_YY, then that provider's service is used. So adding the extension fallback is not that ugly to me. Thanks, Naoto Yoshito Umaoka wrote: > Hi folks > > The very first proposal suggested that locale service look up is done by > base locale, then a service provider may or may not use information > taken from extensions. For example, NumberFormat#getInstance(Locale) > look for a NumberFormatServiceProvider implementation which support the > Locale if the support is not available in JDK. The set of Locales > supported by a LocaleServiceProvider is resolved by an array of Locales > returned by getAvailableLocales implemented by each provider. In this > scenario, the original design proposal suggested to compare a Locale > returned by getAvailableLocales with the requested Locale only for the > base locale portion (language, script, region and variant). We did not > look into this area in detail, because we tried to wrap up the APIs in > Locale itself first. I noticed there is a potential problem in this > scenario. The existing LocaleServiceProvider implementations do not > know about the extensions. If you have two Locales with the same base > locale, but one with no extensions, another with LDML extensions such as > nu=arab (number system is Arabic). For these two Locales, > localeA.equals(localeB) returns false, because they are different. If > an existing LocaleServiceProvider implementation depends on > Locale#equals, it may not work as expected (I thing it's not practical, > but possible...) Of course, even a LocaleServiceProvider return null, > it does not cause any disaster (because it's the contract - for Locale > which cannot be handled by a LocaleServicePoriver implementation, it can > return null, then JDK has a fallback logic.) > > First of all, do we care this potential compatibility problem? This > happens - if someone request a Locale with an extension and if the > Locale is not supported by JDK and if its base locale is supported by a > custom SPI implementation and if the SPI implementation depends on > Locale#equals to identify a Locale.. Even those ifs are all true, it > still return a service object (but fallback is involved). > > If we think we cannot break this, then, we still have several options. > > Option 1: If a LocaleServiceProvider claims that the requested Locale's > base locale is supported, then, JDK calls the provider implementation > with full Locale (including extensions). If it returns null, JDK tries > the requested Locale's base locale only. > Option 2: Add parallel APIs in SPI - for example, in addition to > NumberFormatProvider#getNumberInstance(Locale), add a method > NumberFormatProvider#getNumberInstanceEx(Locale). JDK calls "Ex" > version with extension (the default implementation is to return null), > then if it returns null, call regular version without extensions. > > Well, these are somewhat ugly. So if possible, I'd like to ignore this > potential compatibility issue. Do you have any opinions? > > While thinking various scenarios, I'm feeling that we should provide an > easy way to compare two locales excluding exceptions. I proposed > getBaseLocale before because I thought it might have a good use case. > I'm considering such API again. Actually, > Locale#hasSameBaseLocale(Locale) would do for this purpose (do not need > to create a Locale). > > > Thanks, > Yoshito -- Naoto Sato From y.umaoka at gmail.com Fri Mar 13 12:33:25 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 13 Mar 2009 15:33:25 -0400 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BA9F19.4050304@Sun.COM> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> Message-ID: <49BAB505.30601@gmail.com> Naoto Sato wrote: > Umaoka-san, > > I don't think this is a compatibility issue, because the existing SPI > implementations should still work compatible with the locales without > extensions. Possible issue would only arise with the new locales. > > BTW, current SPI implementation invocation already involves fallback > itself. i.e., say the request locale is xx_YY_foo_bar, and one SPI > provider implements xx_YY, then that provider's service is used. So > adding the extension fallback is not that ugly to me. Yes, I know the current fallback strategy. LDML extensions are designed for specifying optional behavior for a locale. Therefore, as we described in the very first proposal, extensions are carried in each level. More specifically, if a locale xx-yy-zzzz-u-cu-usd is requested, below is the candidate list. xx-yy-zzzz-u-usd xx-yy-u-usd xx-u-usd If we need "extensionless" version inserted, it becomes xx-yy-zzzz-u-usd xx-yy-zzzz xx-yy-u-usd xx-yy xx-u-usd xx Don't you think it's somewhat ugly? -Yoshito From Naoto.Sato at Sun.COM Fri Mar 13 13:11:21 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 13 Mar 2009 13:11:21 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BAB505.30601@gmail.com> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> Message-ID: <49BABDE9.3050505@Sun.COM> So are you specifically talking about LDML extensions? In BCP 47, it's one of the subtags and the BCP does not give any special semantics to it (because it does not know for what it would be used). So I thought the fallback would be: xx-yy-zz-ext xx-yy-zz xx-yy xx Thanks, Naoto Yoshito Umaoka wrote: > Naoto Sato wrote: >> Umaoka-san, >> >> I don't think this is a compatibility issue, because the existing SPI >> implementations should still work compatible with the locales without >> extensions. Possible issue would only arise with the new locales. >> >> BTW, current SPI implementation invocation already involves fallback >> itself. i.e., say the request locale is xx_YY_foo_bar, and one SPI >> provider implements xx_YY, then that provider's service is used. So >> adding the extension fallback is not that ugly to me. > Yes, I know the current fallback strategy. > LDML extensions are designed for specifying optional behavior for a > locale. Therefore, as we described in the very first proposal, > extensions are carried in each level. More specifically, if a locale > xx-yy-zzzz-u-cu-usd is requested, below is the candidate list. > > xx-yy-zzzz-u-usd > xx-yy-u-usd > xx-u-usd > > If we need "extensionless" version inserted, it becomes > > xx-yy-zzzz-u-usd > xx-yy-zzzz > xx-yy-u-usd > xx-yy > xx-u-usd > xx > > Don't you think it's somewhat ugly? > > -Yoshito -- Naoto Sato From dougfelt at google.com Fri Mar 13 16:32:12 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 13 Mar 2009 16:32:12 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BABDE9.3050505@Sun.COM> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> Message-ID: <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> The way we've been thinking of it is that the extensions are an adjunct to the fields of the locale. Their order isn't important, so we canonicalize their order (the same is true for ldml keywords within the ldml extension). The model I have is as follows: The user passes a Locale to a service, which (usually) looks up a bundle, using the base fields language, script, region, and variant (including subfields of variant). Once a matching bundle is found, it's returned to the service. The appropriate extensions (in our particular case, the ldml extension) are then interpreted by the service when accessing the bundle-- which extensions are used depend on the service. There's no real hierarchical ordering to the ldml extensions, they're just different customizations that apply to whatever services care about them. This is different from language/script/region/variant where there is (generally) a useful hierarchical order. Part of the idea here is that by handling extensions separately, the service provider doesn't have to list them-- and if there's no canonical order, it needs to list all permutations. For example, you might have keywords for collation, calendar, and number that apply to several locales. If there were no canonical order you'd have to support all 16 permutations (zero, one, two, or three keywords, in any order) for each such locale. This is rather a lot to list in getAvailableLocales. And this doesn't even involve the values of the keywords. Even if there is a canonical order, then simple fallback doesn't work for all services. Say NumberFormat is passed a locale with the extension "th-th-u-ca-foobar-nu-thai" (calendar = foobar, numbers = thai). There's no locale matching that so this falls back to "th-th-u-ca-foobar", tossing the numbers extension on the floor. The problem appears when there is a bundle "th-th-u-nu-thai", the (irrelevant, from NumberFormat's point of view) request for the foobar calendar preempted the (relevant) request for thai numbers, since it was canonalized to a position earlier in the language tag. The exact opposite could happen for DateFormat with calendar = japanese and animal = foobar (as a hypothetical example). This leads to each service having to manipulate the extensions before looking up the bundle, to keep irrelevant extensions out of the way. This means each service is potentially seeing an entirely different bundle for the 'same' locale. If data used by both services is different between the two bundles, this might show up as an unwanted and unexpected side effect. Considerations like these led us to want to perform lookup using only the base locale, and let the services make use of the extension data as they saw fit based on that same bundle. As for BCP47, it does have descriptions of how one might match against a preferred language list, and also says that particular implementations can perform lookup ignoring extensions. But this language from the spec is generally in the context of matching a preferred language list with wildcards, and so it's not clear how or if this applies to examining a partially ordered collection of locale resources. I tend to think it does not directly apply, and that the way we propose handling lookup is conformant. Mark of course may have a different opinion. Doug On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato wrote: > So are you specifically talking about LDML extensions? In BCP 47, it's one > of the subtags and the BCP does not give any special semantics to it > (because it does not know for what it would be used). So I thought the > fallback would be: > > xx-yy-zz-ext > xx-yy-zz > xx-yy > xx > > Thanks, > Naoto > > Yoshito Umaoka wrote: > >> Naoto Sato wrote: >> >>> Umaoka-san, >>> >>> I don't think this is a compatibility issue, because the existing SPI >>> implementations should still work compatible with the locales without >>> extensions. Possible issue would only arise with the new locales. >>> >>> BTW, current SPI implementation invocation already involves fallback >>> itself. i.e., say the request locale is xx_YY_foo_bar, and one SPI provider >>> implements xx_YY, then that provider's service is used. So adding the >>> extension fallback is not that ugly to me. >>> >> Yes, I know the current fallback strategy. >> LDML extensions are designed for specifying optional behavior for a >> locale. Therefore, as we described in the very first proposal, extensions >> are carried in each level. More specifically, if a locale >> xx-yy-zzzz-u-cu-usd is requested, below is the candidate list. >> >> xx-yy-zzzz-u-usd >> xx-yy-u-usd >> xx-u-usd >> >> If we need "extensionless" version inserted, it becomes >> >> xx-yy-zzzz-u-usd >> xx-yy-zzzz >> xx-yy-u-usd >> xx-yy >> xx-u-usd >> xx >> >> Don't you think it's somewhat ugly? >> >> -Yoshito >> > > > -- > Naoto Sato > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090313/3859dec3/attachment.html From dougfelt at google.com Fri Mar 13 16:52:36 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Fri, 13 Mar 2009 23:52:36 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Add missing file. Message-ID: <20090313235255.4AF6FEEEC@hg.openjdk.java.net> Changeset: 550d212fcf96 Author: dougfelt Date: 2009-03-13 16:49 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/550d212fcf96 Add missing file. + src/share/classes/java/util/IllformedLocaleException.java From dougfelt at google.com Fri Mar 13 17:05:26 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 13 Mar 2009 17:05:26 -0700 Subject: [loc-en-dev] push without email notification Message-ID: <146f39a80903131705p739048e0m2bb5b7a799452ed2@mail.gmail.com> Just a note, I did a push just previous to the one about the missing file, but no notification was sent to the mailing list. If you look at the repository summary you'll see the change is there. I'm not exactly sure why no mail was sent, I think I might have aborted the push command before it went out (sometimes it hangs in my environment although it's completed, I might have jumped the gun). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090313/d20e7eef/attachment.html From dougfelt at google.com Mon Mar 16 10:37:26 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Mon, 16 Mar 2009 17:37:26 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 22 new changesets Message-ID: <20090316174203.79707E014@hg.openjdk.java.net> Changeset: 266358f13a6f Author: dl Date: 2009-02-24 14:01 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/266358f13a6f 6803402: Race condition in AbstractQueuedSynchronizer Summary: Read fields in reverse initialization order Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: f9c187839d72 Author: kevinw Date: 2009-02-24 19:03 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/f9c187839d72 6809463: Missing license header in test LargeZipFile.java Reviewed-by: alanb ! test/java/util/zip/ZipFile/LargeZipFile.java Changeset: dde3fe2e8164 Author: kevinw Date: 2009-02-25 14:32 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/dde3fe2e8164 Merge Changeset: 2fb53eb9df14 Author: mchung Date: 2009-02-26 14:36 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2fb53eb9df14 6801467: Defer get the launcher resource bundle until it's needed Summary: Lazily initialize the launcher resource bundle Reviewed-by: ksrini, darcy ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 4f0b6455a977 Author: jjg Date: 2009-02-26 18:51 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/4f0b6455a977 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/docs/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: de1d02ad2d1d Author: mchung Date: 2009-02-27 13:43 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/de1d02ad2d1d 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Summary: Lazily initialize the hexFloatPattern static field Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java Changeset: 0da45c759116 Author: mchung Date: 2009-02-27 16:34 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/0da45c759116 6809504: Remove enctype="text/xml" from the offline registration page Summary: Remove enctype="text/xml" from register.html and other localized versions Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html Changeset: b656e842e1be Author: xuelei Date: 2009-03-02 23:17 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b656e842e1be 6549506: Specification of Permission.toString() method contradicts with JDK implementation Summary: update the spec, and add double quotes around component. Reviewed-by: weijun ! src/share/classes/java/security/Permission.java + test/java/security/Permission/ToString.java Changeset: 7546743f4cc0 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7546743f4cc0 Merge Changeset: 07d2550f5c84 Author: mchung Date: 2009-03-03 19:26 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/07d2550f5c84 6799230: Lazily load java.lang.annotation.Annotation class Summary: Remove the static EMPTY_ANNOTATION_ARRAY field; add AnnotationParser.toArray method Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java Changeset: a8d9e8cb38bb Author: weijun Date: 2009-03-04 15:09 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/a8d9e8cb38bb 6705872: SecureRandom number init is taking too long on a java.io.tmpdir with a large number of files. Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/provider/SeedGenerator.java Changeset: 94d02968a504 Author: chegar Date: 2009-03-04 13:28 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/94d02968a504 6775145: ClassLoaderUtil.releaseLoader calls System.out.println ("classLoader = " + classLoader) Summary: Remove System.out debugging statements Reviewed-by: michaelm ! src/share/classes/sun/misc/ClassLoaderUtil.java Changeset: 03001e92d155 Author: chegar Date: 2009-03-04 13:36 +0000 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/03001e92d155 6737323: Typo in javadoc for SocketPermission Summary: Remove redundant line form class description Reviewed-by: jccollet ! src/share/classes/java/net/SocketPermission.java Changeset: 6568cd51ae12 Author: sherman Date: 2009-03-04 09:26 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/6568cd51ae12 6812879: Excess code line in ArrayList method Summary: Removed the line of "oldData" which is no longer used. Reviewed-by: martin ! src/share/classes/java/util/ArrayList.java Changeset: 97da21737d9e Author: weijun Date: 2009-03-05 14:49 +0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/97da21737d9e 6813402: keytool cannot -printcert entries without extensions Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/NoExtNPE.sh Changeset: da9d0283a496 Author: valeriep Date: 2009-03-03 19:50 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/da9d0283a496 6812738: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider Summary: Removed finalize() and add more error handling to native code Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 7b3cfde54812 Author: valeriep Date: 2009-03-05 11:44 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/7b3cfde54812 Merge Changeset: 2b6cf18aeb6f Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/2b6cf18aeb6f Merge Changeset: c769c46c27ce Author: mullan Date: 2009-03-09 09:46 -0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/c769c46c27ce 6787130: java.policy file contains stale link to http://java.sun.com/notes Reviewed-by: weijun ! src/share/lib/security/java.policy Changeset: aa48deaf9af4 Author: mullan Date: 2009-03-09 09:56 -0400 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/aa48deaf9af4 Merge Changeset: 175504cc095d Author: tbell Date: 2009-03-09 23:37 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/175504cc095d Merge Changeset: 605e6f20d606 Author: dougfelt Date: 2009-03-16 10:33 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/605e6f20d606 Automated merge with http://hg.openjdk.java.net/jdk7/jdk7/jdk/ From Naoto.Sato at Sun.COM Mon Mar 16 11:28:14 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Mon, 16 Mar 2009 11:28:14 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> Message-ID: <49BE9A3E.50908@Sun.COM> Well, I understand the rationale for the LDML keywords. However on the other hand, BCP 47 specifies the look up fallback as I described before (RFC4647, "3.4. Lookup"). Regarding the extensions, it reads: --- Extensions and unrecognized private-use subtags might be unrelated to a particular application of lookup. Since these subtags come at the end of the subtag sequence, they are removed first during the fallback process and usually pose no barrier to interoperability. However, an implementation MAY remove these from ranges prior to performing the lookup (provided the implementation also removes them from the tags being compared). Such modification is internal to the implementation and applications, protocols, or specifications SHOULD NOT remove or modify subtags in content that they return or forward, because this removes information that can be used elsewhere. --- So this expects that the extensions should first be removed when fallback happens. I am not sure whether removing the left subtags (variant, region, etc.) and appending the extension would conform to this specification. At least I think that the current proposed fallback could confuse some of the developers. Naoto Doug Felt wrote: > The way we've been thinking of it is that the extensions are an > adjunct to the fields of the locale. Their order isn't important, so > we canonicalize their order (the same is true for ldml keywords within > the ldml extension). > > The model I have is as follows: > > The user passes a Locale to a service, which (usually) looks up a > bundle, using the base fields language, script, region, and variant > (including subfields of variant). Once a matching bundle is found, > it's returned to the service. The appropriate extensions (in our > particular case, the ldml extension) are then interpreted by the > service when accessing the bundle-- which extensions are used depend > on the service. There's no real hierarchical ordering to the ldml > extensions, they're just different customizations that apply to > whatever services care about them. This is different from > language/script/region/variant where there is (generally) a useful > hierarchical order. > > Part of the idea here is that by handling extensions separately, the > service provider doesn't have to list them-- and if there's no > canonical order, it needs to list all permutations. For example, you > might have keywords for collation, calendar, and number that apply to > several locales. If there were no canonical order you'd have to > support all 16 permutations (zero, one, two, or three keywords, in any > order) for each such locale. This is rather a lot to list in > getAvailableLocales. And this doesn't even involve the values of the > keywords. > > Even if there is a canonical order, then simple fallback doesn't work > for all services. Say NumberFormat is passed a locale with the > extension "th-th-u-ca-foobar-nu-thai" (calendar = foobar, numbers = > thai). There's no locale matching that so this falls back to > "th-th-u-ca-foobar", tossing the numbers extension on the floor. The > problem appears when there is a bundle "th-th-u-nu-thai", the > (irrelevant, from NumberFormat's point of view) request for the foobar > calendar preempted the (relevant) request for thai numbers, since it > was canonalized to a position earlier in the language tag. The exact > opposite could happen for DateFormat with calendar = japanese and > animal = foobar (as a hypothetical example). > > This leads to each service having to manipulate the extensions before > looking up the bundle, to keep irrelevant extensions out of the way. > This means each service is potentially seeing an entirely different > bundle for the 'same' locale. If data used by both services is > different between the two bundles, this might show up as an unwanted > and unexpected side effect. > > Considerations like these led us to want to perform lookup using only > the base locale, and let the services make use of the extension data > as they saw fit based on that same bundle. > > As for BCP47, it does have descriptions of how one might match against > a preferred language list, and also says that particular > implementations can perform lookup ignoring extensions. But this > language from the spec is generally in the context of matching a > preferred language list with wildcards, and so it's not clear how or > if this applies to examining a partially ordered collection of locale > resources. I tend to think it does not directly apply, and that the > way we propose handling lookup is conformant. Mark of course may have > a different opinion. > > Doug > > On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato > wrote: > > So are you specifically talking about LDML extensions? In BCP 47, > it's one of the subtags and the BCP does not give any special > semantics to it (because it does not know for what it would be > used). So I thought the fallback would be: > > xx-yy-zz-ext > xx-yy-zz > xx-yy > xx > > > Thanks, > Naoto > > Yoshito Umaoka wrote: > > Naoto Sato wrote: > > Umaoka-san, > > I don't think this is a compatibility issue, because the > existing SPI implementations should still work compatible > with the locales without extensions. Possible issue would > only arise with the new locales. > > BTW, current SPI implementation invocation already > involves fallback itself. i.e., say the request locale is > xx_YY_foo_bar, and one SPI provider implements xx_YY, then > that provider's service is used. So adding the extension > fallback is not that ugly to me. > > Yes, I know the current fallback strategy. > LDML extensions are designed for specifying optional behavior > for a locale. Therefore, as we described in the very first > proposal, extensions are carried in each level. More > specifically, if a locale xx-yy-zzzz-u-cu-usd is requested, > below is the candidate list. > > xx-yy-zzzz-u-usd > xx-yy-u-usd > xx-u-usd > > If we need "extensionless" version inserted, it becomes > > xx-yy-zzzz-u-usd > xx-yy-zzzz > xx-yy-u-usd > xx-yy > xx-u-usd > xx > > Don't you think it's somewhat ugly? > > -Yoshito > > > > -- > Naoto Sato > > From dougfelt at google.com Mon Mar 16 12:43:13 2009 From: dougfelt at google.com (Doug Felt) Date: Mon, 16 Mar 2009 12:43:13 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BE9A3E.50908@Sun.COM> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> <49BE9A3E.50908@Sun.COM> Message-ID: <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> Well, perhaps Mark can clarify this passage for us Mark? As you cite: "However, an implementation MAY remove these [extensions and unrecognized private-use subtags] from ranges prior to performing the lookup, provided the implementation also removes them from the tags being compared" This seem to me to allow us to compare only the initial fields when doing lookup, while still using the full locale after lookup has been completed. Naoto, how would you propose dealing with the problems I cited? Doug On Mon, Mar 16, 2009 at 11:28 AM, Naoto Sato wrote: > Well, I understand the rationale for the LDML keywords. However on the > other hand, BCP 47 specifies the look up fallback as I described before > (RFC4647, "3.4. Lookup"). Regarding the extensions, it reads: > > --- > > Extensions and unrecognized private-use subtags might be unrelated to > a particular application of lookup. Since these subtags come at the > end of the subtag sequence, they are removed first during the > fallback process and usually pose no barrier to interoperability. > However, an implementation MAY remove these from ranges prior to > performing the lookup (provided the implementation also removes them > from the tags being compared). Such modification is internal to the > implementation and applications, protocols, or specifications SHOULD > NOT remove or modify subtags in content that they return or forward, > because this removes information that can be used elsewhere. > > --- > > So this expects that the extensions should first be removed when fallback > happens. I am not sure whether removing the left subtags (variant, region, > etc.) and appending the extension would conform to this specification. At > least I think that the current proposed fallback could confuse some of the > developers. > > Naoto > > Doug Felt wrote: > >> The way we've been thinking of it is that the extensions are an adjunct to >> the fields of the locale. Their order isn't important, so we canonicalize >> their order (the same is true for ldml keywords within the ldml extension). >> >> The model I have is as follows: >> >> The user passes a Locale to a service, which (usually) looks up a bundle, >> using the base fields language, script, region, and variant (including >> subfields of variant). Once a matching bundle is found, it's returned to >> the service. The appropriate extensions (in our particular case, the ldml >> extension) are then interpreted by the service when accessing the bundle-- >> which extensions are used depend on the service. There's no real >> hierarchical ordering to the ldml extensions, they're just different >> customizations that apply to whatever services care about them. This is >> different from language/script/region/variant where there is (generally) a >> useful hierarchical order. >> >> Part of the idea here is that by handling extensions separately, the >> service provider doesn't have to list them-- and if there's no canonical >> order, it needs to list all permutations. For example, you might have >> keywords for collation, calendar, and number that apply to several locales. >> If there were no canonical order you'd have to support all 16 permutations >> (zero, one, two, or three keywords, in any order) for each such locale. >> This is rather a lot to list in getAvailableLocales. And this doesn't even >> involve the values of the keywords. >> >> Even if there is a canonical order, then simple fallback doesn't work for >> all services. Say NumberFormat is passed a locale with the extension >> "th-th-u-ca-foobar-nu-thai" (calendar = foobar, numbers = thai). There's no >> locale matching that so this falls back to "th-th-u-ca-foobar", tossing the >> numbers extension on the floor. The problem appears when there is a bundle >> "th-th-u-nu-thai", the (irrelevant, from NumberFormat's point of view) >> request for the foobar calendar preempted the (relevant) request for thai >> numbers, since it was canonalized to a position earlier in the language tag. >> The exact opposite could happen for DateFormat with calendar = japanese and >> animal = foobar (as a hypothetical example). >> >> This leads to each service having to manipulate the extensions before >> looking up the bundle, to keep irrelevant extensions out of the way. >> This means each service is potentially seeing an entirely different bundle >> for the 'same' locale. If data used by both services is different between >> the two bundles, this might show up as an unwanted and unexpected side >> effect. >> >> Considerations like these led us to want to perform lookup using only the >> base locale, and let the services make use of the extension data as they saw >> fit based on that same bundle. >> >> As for BCP47, it does have descriptions of how one might match against a >> preferred language list, and also says that particular implementations can >> perform lookup ignoring extensions. But this language from the spec is >> generally in the context of matching a preferred language list with >> wildcards, and so it's not clear how or if this applies to examining a >> partially ordered collection of locale resources. I tend to think it does >> not directly apply, and that the way we propose handling lookup is >> conformant. Mark of course may have a different opinion. >> >> Doug >> >> On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato > Naoto.Sato at sun.com>> wrote: >> >> So are you specifically talking about LDML extensions? In BCP 47, >> it's one of the subtags and the BCP does not give any special >> semantics to it (because it does not know for what it would be >> used). So I thought the fallback would be: >> >> xx-yy-zz-ext >> xx-yy-zz >> xx-yy >> xx >> >> >> Thanks, >> Naoto >> >> Yoshito Umaoka wrote: >> >> Naoto Sato wrote: >> >> Umaoka-san, >> >> I don't think this is a compatibility issue, because the >> existing SPI implementations should still work compatible >> with the locales without extensions. Possible issue would >> only arise with the new locales. >> >> BTW, current SPI implementation invocation already >> involves fallback itself. i.e., say the request locale is >> xx_YY_foo_bar, and one SPI provider implements xx_YY, then >> that provider's service is used. So adding the extension >> fallback is not that ugly to me. >> >> Yes, I know the current fallback strategy. >> LDML extensions are designed for specifying optional behavior >> for a locale. Therefore, as we described in the very first >> proposal, extensions are carried in each level. More >> specifically, if a locale xx-yy-zzzz-u-cu-usd is requested, >> below is the candidate list. >> >> xx-yy-zzzz-u-usd >> xx-yy-u-usd >> xx-u-usd >> >> If we need "extensionless" version inserted, it becomes >> >> xx-yy-zzzz-u-usd >> xx-yy-zzzz >> xx-yy-u-usd >> xx-yy >> xx-u-usd >> xx >> >> Don't you think it's somewhat ugly? >> >> -Yoshito >> >> >> >> -- Naoto Sato >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090316/89314675/attachment.html From Naoto.Sato at Sun.COM Tue Mar 17 11:07:11 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Tue, 17 Mar 2009 11:07:11 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> <49BE9A3E.50908@Sun.COM> <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> Message-ID: <49BFE6CF.1010809@Sun.COM> If handling the extension is special and it's our discretion how to deal with it, then I would think the following fallback is the most compatible (for the reason Yoshito mentioned) and still meets the requirement from -u extension for LDML keywords, assuming that the providers only advertise their base locales. xx-yy-zzzz-ext xx-yy-zzzz xx-yy-ext xx-yy xx-ext xx Thanks, Naoto Doug Felt wrote: > Well, perhaps Mark can clarify this passage for us Mark? > > As you cite: > > "However, an implementation MAY remove these [extensions and > unrecognized private-use subtags] from ranges prior to performing the > lookup, provided the implementation also removes them from the tags > being compared" > > This seem to me to allow us to compare only the initial fields when > doing lookup, while still using the full locale after lookup has been > completed. > > Naoto, how would you propose dealing with the problems I cited? > > Doug > > On Mon, Mar 16, 2009 at 11:28 AM, Naoto Sato > wrote: > > Well, I understand the rationale for the LDML keywords. However > on the other hand, BCP 47 specifies the look up fallback as I > described before (RFC4647, "3.4. Lookup"). Regarding the > extensions, it reads: > > --- > > Extensions and unrecognized private-use subtags might be unrelated to > a particular application of lookup. Since these subtags come at the > end of the subtag sequence, they are removed first during the > fallback process and usually pose no barrier to interoperability. > However, an implementation MAY remove these from ranges prior to > performing the lookup (provided the implementation also removes them > from the tags being compared). Such modification is internal to the > implementation and applications, protocols, or specifications SHOULD > NOT remove or modify subtags in content that they return or forward, > because this removes information that can be used elsewhere. > > --- > > So this expects that the extensions should first be removed when > fallback happens. I am not sure whether removing the left subtags > (variant, region, etc.) and appending the extension would conform > to this specification. At least I think that the current proposed > fallback could confuse some of the developers. > > Naoto > > Doug Felt wrote: > > The way we've been thinking of it is that the extensions are > an adjunct to the fields of the locale. Their order isn't > important, so we canonicalize their order (the same is true > for ldml keywords within the ldml extension). > > The model I have is as follows: > > The user passes a Locale to a service, which (usually) looks > up a bundle, using the base fields language, script, region, > and variant (including subfields of variant). Once a matching > bundle is found, it's returned to the service. The > appropriate extensions (in our particular case, the ldml > extension) are then interpreted by the service when accessing > the bundle-- which extensions are used depend on the service. > There's no real hierarchical ordering to the ldml extensions, > they're just different customizations that apply to whatever > services care about them. This is different from > language/script/region/variant where there is (generally) a > useful hierarchical order. > > Part of the idea here is that by handling extensions > separately, the service provider doesn't have to list them-- > and if there's no canonical order, it needs to list all > permutations. For example, you might have keywords for > collation, calendar, and number that apply to several locales. > If there were no canonical order you'd have to support all 16 > permutations (zero, one, two, or three keywords, in any order) > for each such locale. This is rather a lot to list in > getAvailableLocales. And this doesn't even involve the values > of the keywords. > > Even if there is a canonical order, then simple fallback > doesn't work for all services. Say NumberFormat is passed a > locale with the extension "th-th-u-ca-foobar-nu-thai" > (calendar = foobar, numbers = thai). There's no locale > matching that so this falls back to "th-th-u-ca-foobar", > tossing the numbers extension on the floor. The problem > appears when there is a bundle "th-th-u-nu-thai", the > (irrelevant, from NumberFormat's point of view) request for > the foobar calendar preempted the (relevant) request for thai > numbers, since it was canonalized to a position earlier in the > language tag. The exact opposite could happen for DateFormat > with calendar = japanese and animal = foobar (as a > hypothetical example). > > This leads to each service having to manipulate the extensions > before looking up the bundle, to keep irrelevant extensions > out of the way. > This means each service is potentially seeing an entirely > different bundle for the 'same' locale. If data used by both > services is different between the two bundles, this might show > up as an unwanted and unexpected side effect. > > Considerations like these led us to want to perform lookup > using only the base locale, and let the services make use of > the extension data as they saw fit based on that same bundle. > > As for BCP47, it does have descriptions of how one might match > against a preferred language list, and also says that > particular implementations can perform lookup ignoring > extensions. But this language from the spec is generally in > the context of matching a preferred language list with > wildcards, and so it's not clear how or if this applies to > examining a partially ordered collection of locale resources. > I tend to think it does not directly apply, and that the way > we propose handling lookup is conformant. Mark of course may > have a different opinion. > > Doug > > On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato > > >> wrote: > > So are you specifically talking about LDML extensions? In > BCP 47, > it's one of the subtags and the BCP does not give any special > semantics to it (because it does not know for what it would be > used). So I thought the fallback would be: > > xx-yy-zz-ext > xx-yy-zz > xx-yy > xx > > > Thanks, > Naoto > > Yoshito Umaoka wrote: > > Naoto Sato wrote: > > Umaoka-san, > > I don't think this is a compatibility issue, > because the > existing SPI implementations should still work > compatible > with the locales without extensions. Possible > issue would > only arise with the new locales. > > BTW, current SPI implementation invocation already > involves fallback itself. i.e., say the request > locale is > xx_YY_foo_bar, and one SPI provider implements > xx_YY, then > that provider's service is used. So adding the > extension > fallback is not that ugly to me. > > Yes, I know the current fallback strategy. > LDML extensions are designed for specifying optional > behavior > for a locale. Therefore, as we described in the very first > proposal, extensions are carried in each level. More > specifically, if a locale xx-yy-zzzz-u-cu-usd is requested, > below is the candidate list. > > xx-yy-zzzz-u-usd > xx-yy-u-usd > xx-u-usd > > If we need "extensionless" version inserted, it becomes > > xx-yy-zzzz-u-usd > xx-yy-zzzz > xx-yy-u-usd > xx-yy > xx-u-usd > xx > > Don't you think it's somewhat ugly? > > -Yoshito > > > > -- Naoto Sato > > > > From dougfelt at google.com Tue Mar 17 11:14:02 2009 From: dougfelt at google.com (Doug Felt) Date: Tue, 17 Mar 2009 11:14:02 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BFE6CF.1010809@Sun.COM> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> <49BE9A3E.50908@Sun.COM> <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> <49BFE6CF.1010809@Sun.COM> Message-ID: <146f39a80903171114u1b914f15hb6a4eba28744e628@mail.gmail.com> I don't understand this. If providers only advertise their base locales, why is the extension involved in lookup at all? Doug On Tue, Mar 17, 2009 at 11:07 AM, Naoto Sato wrote: > If handling the extension is special and it's our discretion how to deal > with it, then I would think the following fallback is the most compatible > (for the reason Yoshito mentioned) and still meets the requirement from -u > extension for LDML keywords, assuming that the providers only advertise > their base locales. > > xx-yy-zzzz-ext > xx-yy-zzzz > xx-yy-ext > xx-yy > xx-ext > xx > > Thanks, > Naoto > > Doug Felt wrote: > >> Well, perhaps Mark can clarify this passage for us Mark? >> >> As you cite: >> >> "However, an implementation MAY remove these [extensions and unrecognized >> private-use subtags] from ranges prior to performing the lookup, provided >> the implementation also removes them from the tags being compared" >> >> This seem to me to allow us to compare only the initial fields when doing >> lookup, while still using the full locale after lookup has been completed. >> >> Naoto, how would you propose dealing with the problems I cited? >> >> Doug >> >> On Mon, Mar 16, 2009 at 11:28 AM, Naoto Sato > Naoto.Sato at sun.com>> wrote: >> >> Well, I understand the rationale for the LDML keywords. However >> on the other hand, BCP 47 specifies the look up fallback as I >> described before (RFC4647, "3.4. Lookup"). Regarding the >> extensions, it reads: >> >> --- >> >> Extensions and unrecognized private-use subtags might be unrelated to >> a particular application of lookup. Since these subtags come at the >> end of the subtag sequence, they are removed first during the >> fallback process and usually pose no barrier to interoperability. >> However, an implementation MAY remove these from ranges prior to >> performing the lookup (provided the implementation also removes them >> from the tags being compared). Such modification is internal to the >> implementation and applications, protocols, or specifications SHOULD >> NOT remove or modify subtags in content that they return or forward, >> because this removes information that can be used elsewhere. >> >> --- >> >> So this expects that the extensions should first be removed when >> fallback happens. I am not sure whether removing the left subtags >> (variant, region, etc.) and appending the extension would conform >> to this specification. At least I think that the current proposed >> fallback could confuse some of the developers. >> >> Naoto >> >> Doug Felt wrote: >> >> The way we've been thinking of it is that the extensions are >> an adjunct to the fields of the locale. Their order isn't >> important, so we canonicalize their order (the same is true >> for ldml keywords within the ldml extension). >> >> The model I have is as follows: >> >> The user passes a Locale to a service, which (usually) looks >> up a bundle, using the base fields language, script, region, >> and variant (including subfields of variant). Once a matching >> bundle is found, it's returned to the service. The >> appropriate extensions (in our particular case, the ldml >> extension) are then interpreted by the service when accessing >> the bundle-- which extensions are used depend on the service. >> There's no real hierarchical ordering to the ldml extensions, >> they're just different customizations that apply to whatever >> services care about them. This is different from >> language/script/region/variant where there is (generally) a >> useful hierarchical order. >> >> Part of the idea here is that by handling extensions >> separately, the service provider doesn't have to list them-- >> and if there's no canonical order, it needs to list all >> permutations. For example, you might have keywords for >> collation, calendar, and number that apply to several locales. >> If there were no canonical order you'd have to support all 16 >> permutations (zero, one, two, or three keywords, in any order) >> for each such locale. This is rather a lot to list in >> getAvailableLocales. And this doesn't even involve the values >> of the keywords. >> >> Even if there is a canonical order, then simple fallback >> doesn't work for all services. Say NumberFormat is passed a >> locale with the extension "th-th-u-ca-foobar-nu-thai" >> (calendar = foobar, numbers = thai). There's no locale >> matching that so this falls back to "th-th-u-ca-foobar", >> tossing the numbers extension on the floor. The problem >> appears when there is a bundle "th-th-u-nu-thai", the >> (irrelevant, from NumberFormat's point of view) request for >> the foobar calendar preempted the (relevant) request for thai >> numbers, since it was canonalized to a position earlier in the >> language tag. The exact opposite could happen for DateFormat >> with calendar = japanese and animal = foobar (as a >> hypothetical example). >> >> This leads to each service having to manipulate the extensions >> before looking up the bundle, to keep irrelevant extensions >> out of the way. >> This means each service is potentially seeing an entirely >> different bundle for the 'same' locale. If data used by both >> services is different between the two bundles, this might show >> up as an unwanted and unexpected side effect. >> >> Considerations like these led us to want to perform lookup >> using only the base locale, and let the services make use of >> the extension data as they saw fit based on that same bundle. >> >> As for BCP47, it does have descriptions of how one might match >> against a preferred language list, and also says that >> particular implementations can perform lookup ignoring >> extensions. But this language from the spec is generally in >> the context of matching a preferred language list with >> wildcards, and so it's not clear how or if this applies to >> examining a partially ordered collection of locale resources. >> I tend to think it does not directly apply, and that the way >> we propose handling lookup is conformant. Mark of course may >> have a different opinion. >> >> Doug >> >> On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato >> >> >> wrote: >> >> So are you specifically talking about LDML extensions? In >> BCP 47, >> it's one of the subtags and the BCP does not give any special >> semantics to it (because it does not know for what it would be >> used). So I thought the fallback would be: >> >> xx-yy-zz-ext >> xx-yy-zz >> xx-yy >> xx >> >> >> Thanks, >> Naoto >> >> Yoshito Umaoka wrote: >> >> Naoto Sato wrote: >> >> Umaoka-san, >> >> I don't think this is a compatibility issue, >> because the >> existing SPI implementations should still work >> compatible >> with the locales without extensions. Possible >> issue would >> only arise with the new locales. >> >> BTW, current SPI implementation invocation already >> involves fallback itself. i.e., say the request >> locale is >> xx_YY_foo_bar, and one SPI provider implements >> xx_YY, then >> that provider's service is used. So adding the >> extension >> fallback is not that ugly to me. >> >> Yes, I know the current fallback strategy. >> LDML extensions are designed for specifying optional >> behavior >> for a locale. Therefore, as we described in the very first >> proposal, extensions are carried in each level. More >> specifically, if a locale xx-yy-zzzz-u-cu-usd is requested, >> below is the candidate list. >> >> xx-yy-zzzz-u-usd >> xx-yy-u-usd >> xx-u-usd >> >> If we need "extensionless" version inserted, it becomes >> >> xx-yy-zzzz-u-usd >> xx-yy-zzzz >> xx-yy-u-usd >> xx-yy >> xx-u-usd >> xx >> >> Don't you think it's somewhat ugly? >> >> -Yoshito >> >> >> >> -- Naoto Sato >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090317/10b024c3/attachment.html From y.umaoka at gmail.com Tue Mar 17 11:22:59 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 17 Mar 2009 14:22:59 -0400 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <146f39a80903171114u1b914f15hb6a4eba28744e628@mail.gmail.com> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> <49BE9A3E.50908@Sun.COM> <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> <49BFE6CF.1010809@Sun.COM> <146f39a80903171114u1b914f15hb6a4eba28744e628@mail.gmail.com> Message-ID: <49BFEA83.3000800@gmail.com> I think Naoto mentioned the interaction between Java and a LSP. The lookup is done by base locale which is under Java's control. Once Java found a LSP which support the base locale, then call a service method with extensions first. If null is returned, then call the same provider with the base locale only. So conceptually, look up and service invocation are not a single fallback chain. More specifically, 1. Requested locale is xx-yy-zzzz-ext 2. Java try to locate a service claiming to support xx-yy-zzzz 3. Java invoke the service method with xx-yy-zzzz-ext 4. If 3 is failed (null is returned), then call the same service method with xx-yy-zzzz 5. If 4 is failed (still returning null), then Java to try xx-yy and start over the steps 2 to 4, then xx. One thing I'm not sure (and it was my original question) is if we really need step 4 above. -Yoshito Doug Felt wrote: > I don't understand this. > > If providers only advertise their base locales, why is the extension > involved in lookup at all? > > Doug > > On Tue, Mar 17, 2009 at 11:07 AM, Naoto Sato > wrote: > > If handling the extension is special and it's our discretion how > to deal with it, then I would think the following fallback is the > most compatible (for the reason Yoshito mentioned) and still meets > the requirement from -u extension for LDML keywords, assuming that > the providers only advertise their base locales. > > xx-yy-zzzz-ext > xx-yy-zzzz > xx-yy-ext > xx-yy > xx-ext > xx > > Thanks, > Naoto > > Doug Felt wrote: > > Well, perhaps Mark can clarify this passage for us Mark? > > As you cite: > > "However, an implementation MAY remove these [extensions and > unrecognized private-use subtags] from ranges prior to > performing the lookup, provided the implementation also > removes them from the tags being compared" > > This seem to me to allow us to compare only the initial fields > when doing lookup, while still using the full locale after > lookup has been completed. > > Naoto, how would you propose dealing with the problems I cited? > > Doug > > On Mon, Mar 16, 2009 at 11:28 AM, Naoto Sato > > >> wrote: > > Well, I understand the rationale for the LDML keywords. > However > on the other hand, BCP 47 specifies the look up fallback as I > described before (RFC4647, "3.4. Lookup"). Regarding the > extensions, it reads: > > --- > > Extensions and unrecognized private-use subtags might be > unrelated to > a particular application of lookup. Since these subtags > come at the > end of the subtag sequence, they are removed first during the > fallback process and usually pose no barrier to > interoperability. > However, an implementation MAY remove these from ranges > prior to > performing the lookup (provided the implementation also > removes them > from the tags being compared). Such modification is > internal to the > implementation and applications, protocols, or > specifications SHOULD > NOT remove or modify subtags in content that they return > or forward, > because this removes information that can be used elsewhere. > > --- > > So this expects that the extensions should first be removed > when > fallback happens. I am not sure whether removing the left > subtags > (variant, region, etc.) and appending the extension would > conform > to this specification. At least I think that the current > proposed > fallback could confuse some of the developers. > > Naoto > > Doug Felt wrote: > > The way we've been thinking of it is that the > extensions are > an adjunct to the fields of the locale. Their order isn't > important, so we canonicalize their order (the same is true > for ldml keywords within the ldml extension). > > The model I have is as follows: > > The user passes a Locale to a service, which (usually) > looks > up a bundle, using the base fields language, script, > region, > and variant (including subfields of variant). Once a > matching > bundle is found, it's returned to the service. The > appropriate extensions (in our particular case, the ldml > extension) are then interpreted by the service when > accessing > the bundle-- which extensions are used depend on the > service. > There's no real hierarchical ordering to the ldml > extensions, > they're just different customizations that apply to > whatever > services care about them. This is different from > language/script/region/variant where there is (generally) a > useful hierarchical order. > > Part of the idea here is that by handling extensions > separately, the service provider doesn't have to list > them-- > and if there's no canonical order, it needs to list all > permutations. For example, you might have keywords for > collation, calendar, and number that apply to several > locales. > If there were no canonical order you'd have to support > all 16 > permutations (zero, one, two, or three keywords, in any > order) > for each such locale. This is rather a lot to list in > getAvailableLocales. And this doesn't even involve the > values > of the keywords. > > Even if there is a canonical order, then simple fallback > doesn't work for all services. Say NumberFormat is > passed a > locale with the extension "th-th-u-ca-foobar-nu-thai" > (calendar = foobar, numbers = thai). There's no locale > matching that so this falls back to "th-th-u-ca-foobar", > tossing the numbers extension on the floor. The problem > appears when there is a bundle "th-th-u-nu-thai", the > (irrelevant, from NumberFormat's point of view) request for > the foobar calendar preempted the (relevant) request > for thai > numbers, since it was canonalized to a position earlier > in the > language tag. The exact opposite could happen for > DateFormat > with calendar = japanese and animal = foobar (as a > hypothetical example). > > This leads to each service having to manipulate the > extensions > before looking up the bundle, to keep irrelevant extensions > out of the way. > This means each service is potentially seeing an entirely > different bundle for the 'same' locale. If data used > by both > services is different between the two bundles, this > might show > up as an unwanted and unexpected side effect. > > Considerations like these led us to want to perform lookup > using only the base locale, and let the services make > use of > the extension data as they saw fit based on that same > bundle. > > As for BCP47, it does have descriptions of how one > might match > against a preferred language list, and also says that > particular implementations can perform lookup ignoring > extensions. But this language from the spec is > generally in > the context of matching a preferred language list with > wildcards, and so it's not clear how or if this applies to > examining a partially ordered collection of locale > resources. > I tend to think it does not directly apply, and that > the way > we propose handling lookup is conformant. Mark of > course may > have a different opinion. > > Doug > > On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato > > > > > >>> wrote: > > So are you specifically talking about LDML > extensions? In > BCP 47, > it's one of the subtags and the BCP does not give > any special > semantics to it (because it does not know for what > it would be > used). So I thought the fallback would be: > > xx-yy-zz-ext > xx-yy-zz > xx-yy > xx > > > Thanks, > Naoto > > Yoshito Umaoka wrote: > > Naoto Sato wrote: > > Umaoka-san, > > I don't think this is a compatibility issue, > because the > existing SPI implementations should still work > compatible > with the locales without extensions. Possible > issue would > only arise with the new locales. > > BTW, current SPI implementation invocation > already > involves fallback itself. i.e., say the request > locale is > xx_YY_foo_bar, and one SPI provider implements > xx_YY, then > that provider's service is used. So adding the > extension > fallback is not that ugly to me. > > Yes, I know the current fallback strategy. > LDML extensions are designed for specifying optional > behavior > for a locale. Therefore, as we described in the > very first > proposal, extensions are carried in each level. > More > specifically, if a locale xx-yy-zzzz-u-cu-usd is > requested, > below is the candidate list. > > xx-yy-zzzz-u-usd > xx-yy-u-usd > xx-u-usd > > If we need "extensionless" version inserted, it > becomes > > xx-yy-zzzz-u-usd > xx-yy-zzzz > xx-yy-u-usd > xx-yy > xx-u-usd > xx > > Don't you think it's somewhat ugly? > > -Yoshito > > > > -- Naoto Sato > > > > > > From y.umaoka at gmail.com Tue Mar 17 14:12:11 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 17 Mar 2009 17:12:11 -0400 Subject: [loc-en-dev] Bi-weekly project meeting today Message-ID: <49C0122B.4030108@gmail.com> Hi folks, I posted the agenda for today's call here -> http://sites.google.com/site/openjdklocale/meeting-agenda I also refreshed proposed API docs including 1. Updated JavaDoc descriptions 2. Made Locale.Builder "final" 3. Added IllformedLocaleException extending IllegalArgumentException. This exception class was added to return error offset information as we discussed last week. -> http://sites.google.com/site/openjdklocale/apis Thanks, Yoshito From dougfelt at google.com Tue Mar 17 18:16:30 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Wed, 18 Mar 2009 01:16:30 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: Latest fixes from Yoshito. Message-ID: <20090318011655.B3CF4E152@hg.openjdk.java.net> Changeset: b0f401427f12 Author: dougfelt Date: 2009-03-17 18:10 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/b0f401427f12 Latest fixes from Yoshito. ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/InternalLocaleBuilder.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/LocaleExtensions.java ! test/java/util/Locale/LocaleEnhanceTest.java From Naoto.Sato at Sun.COM Tue Mar 17 23:24:18 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Tue, 17 Mar 2009 23:24:18 -0700 Subject: [loc-en-dev] Equality of base locale and LocaleServiceProvider implementation In-Reply-To: <49BFEA83.3000800@gmail.com> References: <49B9DF6F.6090300@gmail.com> <49BA9F19.4050304@Sun.COM> <49BAB505.30601@gmail.com> <49BABDE9.3050505@Sun.COM> <146f39a80903131632o79a837d0h471fce3c19378751@mail.gmail.com> <49BE9A3E.50908@Sun.COM> <146f39a80903161243m1e170b2cn42aa487881c9a124@mail.gmail.com> <49BFE6CF.1010809@Sun.COM> <146f39a80903171114u1b914f15hb6a4eba28744e628@mail.gmail.com> <49BFEA83.3000800@gmail.com> Message-ID: <49C09392.8050406@Sun.COM> The rationale I involved the step 4 is for the existing providers which don't know extensions. In this enhanced spec, they are regarded to advertise, say, xx-yy-zzz-* that should match whatever the extension is. However, as Yoshito mentioned, if the provider implementation uses Locale.equals() to compare the requested locale with its advertised locales, it won't return true because of the extension. To avoid this, we need to call the provider with 'xx-yy-zzzz' request locale. Thanks, Naoto Yoshito Umaoka wrote: > I think Naoto mentioned the interaction between Java and a LSP. The > lookup is done by base locale which is under Java's control. Once > Java found a LSP which support the base locale, then call a service > method with extensions first. If null is returned, then call the same > provider with the base locale only. So conceptually, look up and > service invocation are not a single fallback chain. > > More specifically, > > 1. Requested locale is xx-yy-zzzz-ext > 2. Java try to locate a service claiming to support xx-yy-zzzz > 3. Java invoke the service method with xx-yy-zzzz-ext > 4. If 3 is failed (null is returned), then call the same service > method with xx-yy-zzzz > 5. If 4 is failed (still returning null), then Java to try xx-yy and > start over the steps 2 to 4, then xx. > > One thing I'm not sure (and it was my original question) is if we > really need step 4 above. > > -Yoshito > > Doug Felt wrote: >> I don't understand this. >> >> If providers only advertise their base locales, why is the extension >> involved in lookup at all? >> >> Doug >> >> On Tue, Mar 17, 2009 at 11:07 AM, Naoto Sato > > wrote: >> >> If handling the extension is special and it's our discretion how >> to deal with it, then I would think the following fallback is the >> most compatible (for the reason Yoshito mentioned) and still meets >> the requirement from -u extension for LDML keywords, assuming that >> the providers only advertise their base locales. >> >> xx-yy-zzzz-ext >> xx-yy-zzzz >> xx-yy-ext >> xx-yy >> xx-ext >> xx >> >> Thanks, >> Naoto >> >> Doug Felt wrote: >> >> Well, perhaps Mark can clarify this passage for us Mark? >> >> As you cite: >> >> "However, an implementation MAY remove these [extensions and >> unrecognized private-use subtags] from ranges prior to >> performing the lookup, provided the implementation also >> removes them from the tags being compared" >> >> This seem to me to allow us to compare only the initial fields >> when doing lookup, while still using the full locale after >> lookup has been completed. >> >> Naoto, how would you propose dealing with the problems I cited? >> >> Doug >> >> On Mon, Mar 16, 2009 at 11:28 AM, Naoto Sato >> >> >> wrote: >> >> Well, I understand the rationale for the LDML keywords. >> However >> on the other hand, BCP 47 specifies the look up fallback as I >> described before (RFC4647, "3.4. Lookup"). Regarding the >> extensions, it reads: >> >> --- >> >> Extensions and unrecognized private-use subtags might be >> unrelated to >> a particular application of lookup. Since these subtags >> come at the >> end of the subtag sequence, they are removed first during >> the >> fallback process and usually pose no barrier to >> interoperability. >> However, an implementation MAY remove these from ranges >> prior to >> performing the lookup (provided the implementation also >> removes them >> from the tags being compared). Such modification is >> internal to the >> implementation and applications, protocols, or >> specifications SHOULD >> NOT remove or modify subtags in content that they return >> or forward, >> because this removes information that can be used elsewhere. >> >> --- >> >> So this expects that the extensions should first be removed >> when >> fallback happens. I am not sure whether removing the left >> subtags >> (variant, region, etc.) and appending the extension would >> conform >> to this specification. At least I think that the current >> proposed >> fallback could confuse some of the developers. >> >> Naoto >> >> Doug Felt wrote: >> >> The way we've been thinking of it is that the >> extensions are >> an adjunct to the fields of the locale. Their order >> isn't >> important, so we canonicalize their order (the same is >> true >> for ldml keywords within the ldml extension). >> >> The model I have is as follows: >> >> The user passes a Locale to a service, which (usually) >> looks >> up a bundle, using the base fields language, script, >> region, >> and variant (including subfields of variant). Once a >> matching >> bundle is found, it's returned to the service. The >> appropriate extensions (in our particular case, the ldml >> extension) are then interpreted by the service when >> accessing >> the bundle-- which extensions are used depend on the >> service. >> There's no real hierarchical ordering to the ldml >> extensions, >> they're just different customizations that apply to >> whatever >> services care about them. This is different from >> language/script/region/variant where there is >> (generally) a >> useful hierarchical order. >> >> Part of the idea here is that by handling extensions >> separately, the service provider doesn't have to list >> them-- >> and if there's no canonical order, it needs to list all >> permutations. For example, you might have keywords for >> collation, calendar, and number that apply to several >> locales. >> If there were no canonical order you'd have to support >> all 16 >> permutations (zero, one, two, or three keywords, in any >> order) >> for each such locale. This is rather a lot to list in >> getAvailableLocales. And this doesn't even involve the >> values >> of the keywords. >> >> Even if there is a canonical order, then simple fallback >> doesn't work for all services. Say NumberFormat is >> passed a >> locale with the extension "th-th-u-ca-foobar-nu-thai" >> (calendar = foobar, numbers = thai). There's no locale >> matching that so this falls back to "th-th-u-ca-foobar", >> tossing the numbers extension on the floor. The problem >> appears when there is a bundle "th-th-u-nu-thai", the >> (irrelevant, from NumberFormat's point of view) >> request for >> the foobar calendar preempted the (relevant) request >> for thai >> numbers, since it was canonalized to a position earlier >> in the >> language tag. The exact opposite could happen for >> DateFormat >> with calendar = japanese and animal = foobar (as a >> hypothetical example). >> >> This leads to each service having to manipulate the >> extensions >> before looking up the bundle, to keep irrelevant >> extensions >> out of the way. >> This means each service is potentially seeing an entirely >> different bundle for the 'same' locale. If data used >> by both >> services is different between the two bundles, this >> might show >> up as an unwanted and unexpected side effect. >> >> Considerations like these led us to want to perform >> lookup >> using only the base locale, and let the services make >> use of >> the extension data as they saw fit based on that same >> bundle. >> >> As for BCP47, it does have descriptions of how one >> might match >> against a preferred language list, and also says that >> particular implementations can perform lookup ignoring >> extensions. But this language from the spec is >> generally in >> the context of matching a preferred language list with >> wildcards, and so it's not clear how or if this >> applies to >> examining a partially ordered collection of locale >> resources. >> I tend to think it does not directly apply, and that >> the way >> we propose handling lookup is conformant. Mark of >> course may >> have a different opinion. >> >> Doug >> >> On Fri, Mar 13, 2009 at 1:11 PM, Naoto Sato >> >> > >> >> >>> wrote: >> >> So are you specifically talking about LDML >> extensions? In >> BCP 47, >> it's one of the subtags and the BCP does not give >> any special >> semantics to it (because it does not know for what >> it would be >> used). So I thought the fallback would be: >> >> xx-yy-zz-ext >> xx-yy-zz >> xx-yy >> xx >> >> >> Thanks, >> Naoto >> >> Yoshito Umaoka wrote: >> >> Naoto Sato wrote: >> >> Umaoka-san, >> >> I don't think this is a compatibility issue, >> because the >> existing SPI implementations should still work >> compatible >> with the locales without extensions. Possible >> issue would >> only arise with the new locales. >> >> BTW, current SPI implementation invocation >> already >> involves fallback itself. i.e., say the >> request >> locale is >> xx_YY_foo_bar, and one SPI provider implements >> xx_YY, then >> that provider's service is used. So adding >> the >> extension >> fallback is not that ugly to me. >> >> Yes, I know the current fallback strategy. >> LDML extensions are designed for specifying >> optional >> behavior >> for a locale. Therefore, as we described in the >> very first >> proposal, extensions are carried in each level. >> More >> specifically, if a locale xx-yy-zzzz-u-cu-usd is >> requested, >> below is the candidate list. >> >> xx-yy-zzzz-u-usd >> xx-yy-u-usd >> xx-u-usd >> >> If we need "extensionless" version inserted, it >> becomes >> >> xx-yy-zzzz-u-usd >> xx-yy-zzzz >> xx-yy-u-usd >> xx-yy >> xx-u-usd >> xx >> >> Don't you think it's somewhat ugly? >> >> -Yoshito >> >> >> >> -- Naoto Sato >> >> >> >> >> >> > From y.umaoka at gmail.com Thu Mar 26 13:06:08 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 26 Mar 2009 16:06:08 -0400 Subject: [loc-en-dev] [Fwd: JDK 7 schedule and features] Message-ID: <49CBE030.1060406@gmail.com> According to the message posted by Mark in the jdk7-dev ML, the new feature proposal template is coming shortly. I looked at the JDK7 schedule and I think we probably do not have chance to make this feature proposed and done in M3. For now, I think M4 is the earliest possible target practically. Anyway, we need to wait and see the upcoming new feature process and template. -Yoshito -------- Original Message -------- Subject: JDK 7 schedule and features Date: Wed, 25 Mar 2009 09:42:43 -0700 From: Mark Reinhold To: jdk7-dev at openjdk.java.net FYI, I've posted current schedule and feature-list information to the main project page [1], and also published an accompanying blog [2]. - Mark [1] http://openjdk.java.net/projects/jdk7 [2] http://blogs.sun.com/mr/entry/jdk7 From dougfelt at google.com Thu Mar 26 15:20:56 2009 From: dougfelt at google.com (dougfelt at google.com) Date: Thu, 26 Mar 2009 22:20:56 +0000 Subject: [loc-en-dev] hg: locale-enhancement/locale-enhancement: 7 new changesets Message-ID: <20090326222229.9DFB4EABF@hg.openjdk.java.net> Changeset: 711a9fb838d1 Author: ohair Date: 2009-03-16 11:24 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/711a9fb838d1 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: These changes create a preference for the newer 6.1 SDK on Windows. Reviewed-by: tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt.rc ! src/windows/resource/version.rc Changeset: ece878b04159 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/ece878b04159 Merge Changeset: bdb4b0b28407 Author: ohair Date: 2009-03-17 13:44 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/bdb4b0b28407 6818565: Regression with fix 6816311: COMPILER_VERSION -> REQUIRED_COMPILER_VERSION Reviewed-by: tbell - make/common/shared/Compiler.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs.gmk Changeset: fea0898259ae Author: ohair Date: 2009-03-17 13:45 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/fea0898259ae Merge Changeset: bcbeadb4a5d7 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/bcbeadb4a5d7 Added tag jdk7-b51 for changeset fea0898259ae ! .hgtags Changeset: 8026de111ebe Author: dougfelt Date: 2009-03-26 14:52 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/8026de111ebe Merge ! .hgtags ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt.rc ! src/windows/resource/version.rc Changeset: a83ffcf419a6 Author: dougfelt Date: 2009-03-26 15:18 -0700 URL: http://hg.openjdk.java.net/locale-enhancement/locale-enhancement/rev/a83ffcf419a6 Merge tips. - make/common/shared/Compiler.gmk