From scolebourne at joda.org Mon Apr 1 14:48:49 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 01 Apr 2013 21:48:49 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets Message-ID: <20130401215042.AEB234850E@hg.openjdk.java.net> Changeset: e4fa25fb0509 Author: scolebourne Date: 2013-03-31 21:55 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e4fa25fb0509 Avoid use of toString in TCK test ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java Changeset: 0c9a479287b4 Author: scolebourne Date: 2013-03-31 22:24 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0c9a479287b4 Add formatter resolveUsing() method Allows control over the set of fields to be used for resolving date/time ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/Parsed.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java Changeset: 112bd888d017 Author: scolebourne Date: 2013-03-31 23:46 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/112bd888d017 Add formatter parseDefaulting() method Allows default values to be added, useful with optional sections Allows behavior to match SimpleDateFormat auto-defaulting ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java Changeset: 2cc0378b4963 Author: scolebourne Date: 2013-04-01 01:59 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2cc0378b4963 Additional fixes/enhancements for format zone/chrono adjustment Handle conversion from null chrono to ISO Handle map-like temporals More tests ! src/share/classes/java/time/format/DateTimePrintContext.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java Changeset: 9acd8d0c39dc Author: scolebourne Date: 2013-04-01 02:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9acd8d0c39dc Ensure that standard ISO formatters actually are ISO by default See #295 ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: a98a9eb86c54 Author: scolebourne Date: 2013-04-01 22:48 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a98a9eb86c54 Add TemporalField.isDateBased/isTimeBased Rename methods on ChronoField Fix bug in DateTimePrintContext using new information ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java From scolebourne at joda.org Mon Apr 1 15:08:02 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 01 Apr 2013 22:08:02 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130401220825.60DE24850F@hg.openjdk.java.net> Changeset: 3dbe3cd949dd Author: scolebourne Date: 2013-04-01 23:03 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3dbe3cd949dd Add TemporalAdjuster.ofDateAdjuster() Simplifies user-written adjusters ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAdjusters.java ! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java Changeset: ca671c2e333f Author: scolebourne Date: 2013-04-01 23:07 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ca671c2e333f Tweak definition of the Java time-scale ! src/share/classes/java/time/Instant.java From xueming.shen at oracle.com Mon Apr 1 15:38:47 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 01 Apr 2013 15:38:47 -0700 Subject: [threeten-dev] Instant.ofEpochSecond() Message-ID: <515A0C77.3050101@oracle.com> Stephen, Just a nit, it appears the javadoc of Instant.ofEpochSecond() still uses Instant.ofSeconds(...) in example code. -Sherman From scolebourne at joda.org Mon Apr 1 16:10:15 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 01 Apr 2013 23:10:15 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20130401231122.0B00748514@hg.openjdk.java.net> Changeset: 8770f319fd40 Author: scolebourne Date: 2013-04-01 23:58 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8770f319fd40 Minor Javadoc/code layout issues ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/temporal/TemporalField.java Changeset: f6bbf5a5d0a8 Author: scolebourne Date: 2013-04-02 00:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f6bbf5a5d0a8 Remove Comparator from TemporalField Interacts badly with default methods added to Comparator Fixes #298 ! src/share/classes/java/time/temporal/TemporalField.java Changeset: 1ac777083c06 Author: scolebourne Date: 2013-04-02 00:09 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1ac777083c06 Minor Javadoc fixes ! src/share/classes/java/time/Instant.java From scolebourne at joda.org Mon Apr 1 16:14:02 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 2 Apr 2013 00:14:02 +0100 Subject: [threeten-dev] Instant.ofEpochSecond() In-Reply-To: <515A0C77.3050101@oracle.com> References: <515A0C77.3050101@oracle.com> Message-ID: Fixed Stephen On 1 April 2013 23:38, Xueming Shen wrote: > Stephen, > > Just a nit, it appears the javadoc of Instant.ofEpochSecond() still uses > Instant.ofSeconds(...) in example code. > > -Sherman From masayoshi.okutsu at oracle.com Wed Apr 3 09:09:45 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 04 Apr 2013 01:09:45 +0900 Subject: [threeten-dev] Review request: Splitting locale resources (FormatData) for java.time classes Message-ID: <515C5449.5010109@oracle.com> Hi, I've made changes for splitting locale resources into FormatData required by the legacy i18n classes and JavaTimeSupplementary required by the java.time classes. The reason of this split is to make locale resources maintenance easier. Changes are mostly in the locale data adapter side. Here are concrete changes in a random order: - Split FormatData files for JRE into the FormatData files and their corresponding JavaTimeSupplementary files. The supplementary data is added to its FormatData on demand at runtime. This is to avoid loading java.time specific resources in case they are not used. All JavaTimeSupplementary files were generated by a tool. But the tool isn't included in webrev. It's still a mess. - Changed prefix "cldr." to "java.time." for java.time specific resources. - "java.time.*DatePattrens" resources are now converted from legacy JRE resources rather than from CLDR. This change required the TestNonIsoFormatter.java change. - Added missing resources (due to a tool bug) to FormatData files. - No format changes to FormatData files generated from CLDR (XML). - Added ParallelListResourceBundle which supports additional contents (key-value pairs). FormatData* classes are now ParallelListResourceBundle subclasses. sun/util/resources/LocaleData takes care of adding supplementary data at runtime. - Renamed CalendarDataUtility.retrieveCldr* to .retrieveJavaTime*. - Cleaned up OpenListResourceBundle. - CLDR Converter Tool now takes "approved" and "contributed" data items because there are too many missing elements in arrays. However, FormatData and JavaTimeSupplementary files for JRE have only approved items. - Changed some copyright text and removed "DO NOT EDIT" comment lines. I don't believe those files can be re-generated using the older version of CLDR Converter Tool. There are some remaining work items. - Need more verification of the actual locale resources. - Clean up the JavaTimeSupplementary generator tool. - Add a test for ParallelListResourceBundl, which is almost ready for review, but it requires a bug ID for the @bug tag of jtreg. - Clean up test/sun/text/resources/LocaleData with the additional resources. Webrev: http://cr.openjdk.java.net/~okutsu/310/resourcesplit/webrev.00/ Thanks, Masayoshi From scolebourne at joda.org Wed Apr 3 09:28:45 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 3 Apr 2013 17:28:45 +0100 Subject: [threeten-dev] Review request: Splitting locale resources (FormatData) for java.time classes In-Reply-To: <515C5449.5010109@oracle.com> References: <515C5449.5010109@oracle.com> Message-ID: The changes sound sensible and I didn't see anything wrong in a quick look through. Stephen On 3 April 2013 17:09, Masayoshi Okutsu wrote: > Hi, > > I've made changes for splitting locale resources into FormatData required by > the legacy i18n classes and JavaTimeSupplementary required by the java.time > classes. The reason of this split is to make locale resources maintenance > easier. Changes are mostly in the locale data adapter side. > > Here are concrete changes in a random order: > > - Split FormatData files for JRE into the FormatData files and their > corresponding JavaTimeSupplementary files. The supplementary data is added > to its FormatData on demand at runtime. This is to avoid loading java.time > specific resources in case they are not used. All JavaTimeSupplementary > files were generated by a tool. But the tool isn't included in webrev. It's > still a mess. > > - Changed prefix "cldr." to "java.time." for java.time specific resources. > > - "java.time.*DatePattrens" resources are now converted from legacy JRE > resources rather than from CLDR. This change required the > TestNonIsoFormatter.java change. > > - Added missing resources (due to a tool bug) to FormatData files. > > - No format changes to FormatData files generated from CLDR (XML). > > - Added ParallelListResourceBundle which supports additional contents > (key-value pairs). FormatData* classes are now ParallelListResourceBundle > subclasses. sun/util/resources/LocaleData takes care of adding supplementary > data at runtime. > > - Renamed CalendarDataUtility.retrieveCldr* to .retrieveJavaTime*. > > - Cleaned up OpenListResourceBundle. > > - CLDR Converter Tool now takes "approved" and "contributed" data items > because there are too many missing elements in arrays. However, FormatData > and JavaTimeSupplementary files for JRE have only approved items. > > - Changed some copyright text and removed "DO NOT EDIT" comment lines. I > don't believe those files can be re-generated using the older version of > CLDR Converter Tool. > > There are some remaining work items. > > - Need more verification of the actual locale resources. > > - Clean up the JavaTimeSupplementary generator tool. > > - Add a test for ParallelListResourceBundl, which is almost ready for > review, but it requires a bug ID for the @bug tag of jtreg. > > - Clean up test/sun/text/resources/LocaleData with the additional resources. > > Webrev: > http://cr.openjdk.java.net/~okutsu/310/resourcesplit/webrev.00/ > > Thanks, > Masayoshi > > From naoto.sato at oracle.com Wed Apr 3 14:09:53 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 03 Apr 2013 14:09:53 -0700 Subject: [threeten-dev] Review request: Splitting locale resources (FormatData) for java.time classes In-Reply-To: <515C5449.5010109@oracle.com> References: <515C5449.5010109@oracle.com> Message-ID: <515C9AA1.7080608@oracle.com> Looks good overall. Some minor comments: - sun/util/locale/provider/CalendarNameProviderImpl.java, line 234: "cldr" -> "javatime" - sun/util/locale/provider/LocaleResources.java, line 370: Should this method be renamed to getJavaTime...()? - src/share/classes/sun/util/resources/LocaleData.java, line 128: Is there any chance that this assertion would fail with FALLBACK adapter? Naoto On 4/3/13 9:09 AM, Masayoshi Okutsu wrote: > Hi, > > I've made changes for splitting locale resources into FormatData > required by the legacy i18n classes and JavaTimeSupplementary required > by the java.time classes. The reason of this split is to make locale > resources maintenance easier. Changes are mostly in the locale data > adapter side. > > Here are concrete changes in a random order: > > - Split FormatData files for JRE into the FormatData files and their > corresponding JavaTimeSupplementary files. The supplementary data is > added to its FormatData on demand at runtime. This is to avoid loading > java.time specific resources in case they are not used. All > JavaTimeSupplementary files were generated by a tool. But the tool isn't > included in webrev. It's still a mess. > > - Changed prefix "cldr." to "java.time." for java.time specific resources. > > - "java.time.*DatePattrens" resources are now converted from legacy JRE > resources rather than from CLDR. This change required the > TestNonIsoFormatter.java change. > > - Added missing resources (due to a tool bug) to FormatData files. > > - No format changes to FormatData files generated from CLDR (XML). > > - Added ParallelListResourceBundle which supports additional contents > (key-value pairs). FormatData* classes are now > ParallelListResourceBundle subclasses. sun/util/resources/LocaleData > takes care of adding supplementary data at runtime. > > - Renamed CalendarDataUtility.retrieveCldr* to .retrieveJavaTime*. > > - Cleaned up OpenListResourceBundle. > > - CLDR Converter Tool now takes "approved" and "contributed" data items > because there are too many missing elements in arrays. However, > FormatData and JavaTimeSupplementary files for JRE have only approved > items. > > - Changed some copyright text and removed "DO NOT EDIT" comment lines. I > don't believe those files can be re-generated using the older version of > CLDR Converter Tool. > > There are some remaining work items. > > - Need more verification of the actual locale resources. > > - Clean up the JavaTimeSupplementary generator tool. > > - Add a test for ParallelListResourceBundl, which is almost ready for > review, but it requires a bug ID for the @bug tag of jtreg. > > - Clean up test/sun/text/resources/LocaleData with the additional > resources. > > Webrev: > http://cr.openjdk.java.net/~okutsu/310/resourcesplit/webrev.00/ > > Thanks, > Masayoshi > > From scolebourne at joda.org Wed Apr 3 17:49:14 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 04 Apr 2013 00:49:14 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets Message-ID: <20130404005107.221E8485AC@hg.openjdk.java.net> Changeset: fa5461db0139 Author: scolebourne Date: 2013-04-03 21:41 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fa5461db0139 Add ResolverStyle to support lenient/strict resolve See #282 ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/Parsed.java + src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: d8d90fa2a73a Author: scolebourne Date: 2013-04-04 00:51 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d8d90fa2a73a Implement strict/smart/lenient in IsoChrono, IsoFields and JulianFields Not implemented in Chrono and WeekFields Not tested in IsoChrono See #282 ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java Changeset: 35a4c497f286 Author: scolebourne Date: 2013-04-04 01:16 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/35a4c497f286 Move resolverFields from buidler to formatter Better to keep all resolver control in one place ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/Parsed.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java Changeset: e9af88ed0b27 Author: scolebourne Date: 2013-04-04 01:21 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e9af88ed0b27 Enhance Javadoc ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 28c446dcb53c Author: scolebourne Date: 2013-04-04 01:28 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/28c446dcb53c Remove 6 letter patterns for E/e/c from formatter See #64 ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java Changeset: 75c0b557aaec Author: scolebourne Date: 2013-04-04 01:48 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/75c0b557aaec Basic resolver tests for ISO year-month-day ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java From masayoshi.okutsu at oracle.com Thu Apr 4 00:12:23 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Thu, 04 Apr 2013 07:12:23 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Split locale resources (FormatData) for java.time Message-ID: <20130404071246.D69E6485B8@hg.openjdk.java.net> Changeset: e184e025210a Author: okutsu Date: 2013-04-04 16:11 +0900 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e184e025210a Split locale resources (FormatData) for java.time ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/sun/text/FILES_java.gmk ! make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/sun/text/resources/FormatData.java + src/share/classes/sun/text/resources/JavaTimeSupplementary.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/de/FormatData_de_AT.java ! src/share/classes/sun/text/resources/de/FormatData_de_CH.java ! src/share/classes/sun/text/resources/de/FormatData_de_DE.java ! src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/el/FormatData_el_CY.java ! src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java ! src/share/classes/sun/text/resources/en/FormatData_en.java ! src/share/classes/sun/text/resources/en/FormatData_en_AU.java ! src/share/classes/sun/text/resources/en/FormatData_en_CA.java ! src/share/classes/sun/text/resources/en/FormatData_en_GB.java ! src/share/classes/sun/text/resources/en/FormatData_en_IE.java ! src/share/classes/sun/text/resources/en/FormatData_en_IN.java ! src/share/classes/sun/text/resources/en/FormatData_en_MT.java ! src/share/classes/sun/text/resources/en/FormatData_en_NZ.java ! src/share/classes/sun/text/resources/en/FormatData_en_PH.java ! src/share/classes/sun/text/resources/en/FormatData_en_SG.java ! src/share/classes/sun/text/resources/en/FormatData_en_US.java ! src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/es/FormatData_es_AR.java ! src/share/classes/sun/text/resources/es/FormatData_es_BO.java ! src/share/classes/sun/text/resources/es/FormatData_es_CL.java ! src/share/classes/sun/text/resources/es/FormatData_es_CO.java ! src/share/classes/sun/text/resources/es/FormatData_es_CR.java ! src/share/classes/sun/text/resources/es/FormatData_es_DO.java ! src/share/classes/sun/text/resources/es/FormatData_es_EC.java ! src/share/classes/sun/text/resources/es/FormatData_es_ES.java ! src/share/classes/sun/text/resources/es/FormatData_es_GT.java ! src/share/classes/sun/text/resources/es/FormatData_es_HN.java ! src/share/classes/sun/text/resources/es/FormatData_es_MX.java ! src/share/classes/sun/text/resources/es/FormatData_es_NI.java ! src/share/classes/sun/text/resources/es/FormatData_es_PA.java ! src/share/classes/sun/text/resources/es/FormatData_es_PE.java ! src/share/classes/sun/text/resources/es/FormatData_es_PR.java ! src/share/classes/sun/text/resources/es/FormatData_es_PY.java ! src/share/classes/sun/text/resources/es/FormatData_es_SV.java ! src/share/classes/sun/text/resources/es/FormatData_es_US.java ! src/share/classes/sun/text/resources/es/FormatData_es_UY.java ! src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java ! src/share/classes/sun/text/resources/ga/FormatData_ga.java ! src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java ! src/share/classes/sun/text/resources/in/FormatData_in.java ! src/share/classes/sun/text/resources/in/FormatData_in_ID.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/it/FormatData_it_CH.java ! src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java + src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java ! src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java ! src/share/classes/sun/text/resources/no/FormatData_no.java ! src/share/classes/sun/text/resources/no/FormatData_no_NO.java ! src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java ! src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java + src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java + src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java + src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java + src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java + src/share/classes/sun/util/resources/ParallelListResourceBundle.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/temporal/TestChronoField.java ! test/java/util/Calendar/Bug8007038.java ! test/java/util/Calendar/CldrFormatNamesTest.java ! test/sun/text/resources/LocaleData From masayoshi.okutsu at oracle.com Thu Apr 4 01:13:14 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 04 Apr 2013 17:13:14 +0900 Subject: [threeten-dev] Review request: Splitting locale resources (FormatData) for java.time classes In-Reply-To: <515C9AA1.7080608@oracle.com> References: <515C5449.5010109@oracle.com> <515C9AA1.7080608@oracle.com> Message-ID: <515D361A.40301@oracle.com> Thanks for catching them. I've pushed the changes with fixes to the threeten repo. The assertion was a leftover of debugging code and removed. Masayoshi On 4/4/2013 6:09 AM, Naoto Sato wrote: > Looks good overall. Some minor comments: > > - sun/util/locale/provider/CalendarNameProviderImpl.java, line 234: > "cldr" -> "javatime" > > - sun/util/locale/provider/LocaleResources.java, line 370: Should this > method be renamed to getJavaTime...()? > > - src/share/classes/sun/util/resources/LocaleData.java, line 128: Is > there any chance that this assertion would fail with FALLBACK adapter? > > Naoto > > On 4/3/13 9:09 AM, Masayoshi Okutsu wrote: >> Hi, >> >> I've made changes for splitting locale resources into FormatData >> required by the legacy i18n classes and JavaTimeSupplementary required >> by the java.time classes. The reason of this split is to make locale >> resources maintenance easier. Changes are mostly in the locale data >> adapter side. >> >> Here are concrete changes in a random order: >> >> - Split FormatData files for JRE into the FormatData files and their >> corresponding JavaTimeSupplementary files. The supplementary data is >> added to its FormatData on demand at runtime. This is to avoid loading >> java.time specific resources in case they are not used. All >> JavaTimeSupplementary files were generated by a tool. But the tool isn't >> included in webrev. It's still a mess. >> >> - Changed prefix "cldr." to "java.time." for java.time specific >> resources. >> >> - "java.time.*DatePattrens" resources are now converted from legacy JRE >> resources rather than from CLDR. This change required the >> TestNonIsoFormatter.java change. >> >> - Added missing resources (due to a tool bug) to FormatData files. >> >> - No format changes to FormatData files generated from CLDR (XML). >> >> - Added ParallelListResourceBundle which supports additional contents >> (key-value pairs). FormatData* classes are now >> ParallelListResourceBundle subclasses. sun/util/resources/LocaleData >> takes care of adding supplementary data at runtime. >> >> - Renamed CalendarDataUtility.retrieveCldr* to .retrieveJavaTime*. >> >> - Cleaned up OpenListResourceBundle. >> >> - CLDR Converter Tool now takes "approved" and "contributed" data items >> because there are too many missing elements in arrays. However, >> FormatData and JavaTimeSupplementary files for JRE have only approved >> items. >> >> - Changed some copyright text and removed "DO NOT EDIT" comment lines. I >> don't believe those files can be re-generated using the older version of >> CLDR Converter Tool. >> >> There are some remaining work items. >> >> - Need more verification of the actual locale resources. >> >> - Clean up the JavaTimeSupplementary generator tool. >> >> - Add a test for ParallelListResourceBundl, which is almost ready for >> review, but it requires a bug ID for the @bug tag of jtreg. >> >> - Clean up test/sun/text/resources/LocaleData with the additional >> resources. >> >> Webrev: >> http://cr.openjdk.java.net/~okutsu/310/resourcesplit/webrev.00/ >> >> Thanks, >> Masayoshi >> >> > From xueming.shen at oracle.com Thu Apr 4 14:28:10 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 04 Apr 2013 14:28:10 -0700 Subject: [threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE Message-ID: <515DF06A.8020604@oracle.com> Stephen, While working on adding to/fromInstant to FileTime, the difference of the min/max value (year) of machine time and human time becomes a kinda of "block". Have to copy/paste the "special handing" code from the InstantPP to handle the year specially (I'm pretty sure no real world code really care those years...). So just wonder what's the benefit of having the supported human time year off 1 from the machine time. The doc suggests that it tries to "provides sufficient values to handle the range of ZoneOffset, which affect the instant in addition to the LDT", but are we throwing away (invalidate) almost one year (between Instant and LDT/ZDT) to support/validate +/- 14 hrs of offsets? Or I'm reading the doc/code wrong? It appears FileTime have to have its own "format/toStrong" instant of leveraging the JSR310 formatting mainly because 1) it follows the existing jdk/"old" ISO 8601 formatting behavior for BCE years, in which dis-allows the 0000 for proleptic year 0. 2) LocalTime formats the "ss" part optionally. It appears to takes the "it is acceptable to omit lower order time elements..." alternative. 3) FileTime formats the "fraction of second" part as "decimal fraction" while LT uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips any tailing zero, but LD does not if it fits into the 3-letter unit. Stephen, any reason behind this design decision, or it is specified by the standard. Here is the "draft" of the FileTime change, comment and suggestion appreciated. http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/ -Sherman From roger.riggs at oracle.com Thu Apr 4 13:37:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 04 Apr 2013 16:37:52 -0400 Subject: [threeten-dev] ChronoLocalDate Generic type parameters (#292) Message-ID: <515DE4A0.90200@oracle.com> Prompted by the issue #292 ChronoLocalDate generics difficult to use I followed up on the suggestions and did some prototyping of alternatives to the generics on ChronoLocalDate>. The ChronoZonedDateTime and ChronoLocalDateTime types parameter remains > since they retain references the date and can return the parameterized type. Some alternatives for include: 1. ChronoLocalDate - no parameterization 2. ChronoLocalDate 3. Removing the from return values. Though the simplicity of 1) removing the generics seems appealing, it disables application and library designs that can take advantage of the generic types because the fluent design would no longer pass through the generic type and all operations would return ChronoLocalDate. 2) Removing just the constraint on the extends clause doesn't solve the original problem and isn't an improvement of any significance. 3) The original symptom and difficulty of using the wildcard generic types from the API has a couple alternatives for work arounds. The application can itself use the raw types by casting or assignment of the return value to take advantage of the lenient type matching of raw types. The code compiles and runs correctly though the compiler produces warnings about raw type and unchecked assignments which can be suppressed selectively or in an appropriate scope. One alternative to the wildcard return types is to return the raw ChronoLocalDate. In the example, the raw type does not produce a compilation error but does cause the unchecked cast warning. I would recommend against changing the type parameters; we're trying to freeze for the next build and integration. The current parameter usage follows the general recommendations for generic types and the alternatives are not clear improvements on all points. I'd like to get a bit more experience with the API before making changes. Roger From scolebourne at joda.org Fri Apr 5 02:42:40 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 5 Apr 2013 10:42:40 +0100 Subject: [threeten-dev] ChronoLocalDate Generic type parameters (#292) In-Reply-To: <515DE4A0.90200@oracle.com> References: <515DE4A0.90200@oracle.com> Message-ID: On 4 April 2013 21:37, roger riggs wrote: > Some alternatives for include: > > 1. ChronoLocalDate - no parameterization > 2. ChronoLocalDate > 3. Removing the from return values. > > Though the simplicity of 1) removing the generics seems appealing, it > disables application and library designs that can take advantage of the > generic types because the fluent design would no longer pass through > the generic type and all operations would return ChronoLocalDate. Users either use a specific type, or the abstract interface, they won't tend to fix the two, A method: D process(D date) will work perfectly in both cases fooDate = process(fooDate) clDate = process(clDate) The only thing "lost" is the ability to refer to one or more CLD instances as being in the same calendar system, without specifying which calendar system that is. This is no worse than j.u.Calendar today, and in my view a rarer requirement. > 2) Removing just the constraint on the extends clause doesn't solve the > original problem and isn't an improvement of any significance. > > 3) The original symptom and difficulty of using the wildcard generic types > from > the API has a couple alternatives for work arounds. > The application can itself use the raw types by casting or assignment of the > return value to take advantage of the lenient type matching of raw types. > The code compiles and runs correctly though the compiler produces > warnings about raw type and unchecked assignments which can be suppressed > selectively or in an appropriate scope. No solution involving raw types on a public API would be acceptable to me, > I would recommend against changing the type parameters; we're trying > to freeze for the next build and integration. The current parameter usage > follows the general recommendations for generic types and the alternatives > are not clear improvements on all points. I'd like to get a bit more > experience > with the API before making changes. So long as we can still make a change, its fine to leave it for now. Stephen From scolebourne at joda.org Fri Apr 5 03:55:49 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 5 Apr 2013 11:55:49 +0100 Subject: [threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE In-Reply-To: <515DF06A.8020604@oracle.com> References: <515DF06A.8020604@oracle.com> Message-ID: On 4 April 2013 22:28, Xueming Shen wrote: > While working on adding to/fromInstant to FileTime, the difference > of the min/max value (year) of machine time and human time > becomes a kinda of "block". Have to copy/paste the "special > handing" code from the InstantPP to handle the year specially > (I'm pretty sure no real world code really care those years...). > So just wonder what's the benefit of having the supported human > time year off 1 from the machine time. The doc suggests that > it tries to "provides sufficient values to handle the range of > ZoneOffset, which affect the instant in addition to the LDT", but > are we throwing away (invalidate) almost one year (between > Instant and LDT/ZDT) to support/validate +/- 14 hrs of offsets? > Or I'm reading the doc/code wrong? There is non happy choice here that I could see. I wanted LDT.at(offset) to work without error for every possible date-time and offset. This means that the biggest ODT is LDT.MAX.atOffset(ZoneOffset.MIN). We could set the Instant.MAX to that value, but there would still be a gap of invalidity. The most effective solution I could see was to make all the *DateTime classes consistent and without error, but the Instant class be slightly different (larger). The result is that min/max instants can't be converted to LDT/ODT, but that has historically been the case in the API (as Instant.MAX used to be Long.MAX_VALUE). > It appears FileTime have to have its own "format/toStrong" instant > of leveraging the JSR310 formatting mainly because > > 1) it follows the existing jdk/"old" ISO 8601 formatting behavior for BCE > years, in which dis-allows the 0000 for proleptic year 0. > > 2) LocalTime formats the "ss" part optionally. It appears to takes the > "it is acceptable to omit lower order time elements..." alternative. > > 3) FileTime formats the "fraction of second" part as "decimal fraction" > while LT uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips > any tailing zero, but LD does not if it fits into the 3-letter unit. > Stephen, any reason behind this design decision, or it is specified > by the standard. LocalTime has to pretend that it is multiple classes (to avoid class combination explosion). So, it pretends to be an HourMin class, by printing a suitable toString, it also pretends to be an HourMinSec class. For decimal fractions it is also more consistent with SimpleDateFormat to show all three digits for millis. Using DateTimeFormatterBuilder, you can easily produce a formatter that can format/parse the FileTime format however. builder .appendText(ERA, mapOfZeroToMinusSignAndOneToEmptyString) .appendValue(YEAR_OF_ERA, 4) ... .appendFraction(NANO_OF_SECOND, 0, 9) > Here is the "draft" of the FileTime change, comment and suggestion > appreciated. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/ to(TimeUnit unit) unit.convert(instant.getEpochSecond(), TimeUnit.SECONDS) + unit.convert(instant.getNano(), TimeUnit.NANOSECONDS); will not saturate correctly to MIN/MAX toMillis() instant.toEpochMilli(); will throw ArithmeticException, so you'll have to catch and convert to MIN/MAX. hashCode() Because toInstant() can't repesent all values of FileTime, the hashCode's uniqueness is compromised. Same truncation problem in toString() Also, you have a one line if statement which is misisng its braces. An alternate approach would be to convert on input to the existing the long+TimeUnit storage mechanism. Conversion would be immediate, and could spot trailing zeroes in the Instant and choose a larger TimeUnit. Truncation would be possible, but unlikely. Really, I would prefer to see the class changed to be a TemporalAccessor. That way, it could return INSTANT_SECONDS and be passed directly to the formatter (which handles values greater than Instant.MAX). This would require a simple enhancement to the instant formatter to control fractional seconds (which is needed and I'm raising an issue for). Stephen From scolebourne at joda.org Fri Apr 5 08:43:15 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 5 Apr 2013 16:43:15 +0100 Subject: [threeten-dev] Leap seconds and the Java time-scale Message-ID: I've been corresponding with Zefram recently about the API, specifically around leap seconds and the Java time-scale that we define to avoid exposing leap seconds. Zerfram knows far more than I do about UTC/UT1/UT2/.. and the alphabet soup of time-scale acronyms, as has provided some excellent feedback, which I have permission to publish excerpts of for transparancy (at the end of this email). I'm currently proposing this as the new text for the time-scale. Its more precise than we currently have, yet doesn't change any code or implementation behaviour, and also allows for future change. The current text is in the class Javadoc here: http://hg.openjdk.java.net/threeten/threeten/jdk/file/e184e025210a/src/share/classes/java/time/Instant.java " The Java time scale divides each calendar day into exactly 86400 subdivision, known as seconds. These seconds may differ from the SI second. It closely matches the de facto international civil time scale, the definition of which changes from time to time. The Java time scale has slightly different definitions for different segments of the time-line, each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new segment of the Java time scale must be defined for it. Each segment must meet these requirements: * the Java time scale shall closely match the underlying international civil time scale; * the Java time scale shall exactly match the international civil time scale at noon each day on the prime meridian (Greenwich); * the Java time scale shall have a precisely-defined relationship to the international civil time scale. There are currently, as of 2013, two segments in the Java time-scale. For the segment from 1972-11-03 (UTC) (exact boundary discussed below) until further notice, the consensus international time scale is UTC (with leap seconds). In this period, the Java time scale is identical to UTC-SLS [hyperlink]. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread equally over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day. Implementations of the JSR-310 API are not required to provide any clock that is sub-second accurate, or indeed accurate at all, or that progresses monotonically or smoothly. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. Only implementations that claim sub-second accuracy are obliged to distinguish between the various flavours of UT, and how conformant they are with the time-scale. For the segment prior to 1972-11-03 (UTC), extending back arbitrarily far, the consensus international time scale is defined to be UT1 extrapolated proleptically. This is equivalent to the (mean) solar time on the prime meridian (Greenwich). If implementing based on a specific set of UT1 data, then the exact boundary is where UT1 = UTC, which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) depending on the UT1 data. For the segment prior to 1972-11-03 (UTC), extending back arbitrarily far, the consensus international time scale is defined to be UT1 extrapolated proleptically. This is equivalent to the (mean) solar time on the prime meridian (Greenwich). If implementing based on a specific set of UT1 data, then the exact boundary is where UT1 = UTC, which may be up to 36 hours earlier or later than 1972-11-03T00:00Z (UTC) depending on the UT1 data. " Feedback welcome. Stephen ----------------------------------------------------------------- Forwarded conversation Subject: Java definitions ------------------------ From: *Stephen Colebourne* Date: 30 March 2013 00:09 To: Zefram Hi Zefram, Good to meet you on Thursday. I've updated the definition slightly, to require a clear algorithm as part of the time-scale, and refer to UTC-SLS as the approved algorithm. This seems to me to be a firmer definition than before, without totally closing the door to other implementations and changes (which I need to allow for). In particular, if UTC were to be changed in 2014 to have an official smoothing algorithm other than UTC-SLS, then I want some wiggle room to be able to adapt. * Given the complexity of accurate timekeeping described above, this Java API defines * its own time-scale with a simplification. The Java time-scale is defined as follows: *

    *
  • midday will always be exactly as defined by the agreed international civil time
  • *
  • other times during the day will be broadly in line with the agreed international civil time
  • *
  • the day will be divided into exactly 86400 subdivisions, referred to as "seconds"
  • *
  • the Java "second" may differ from an SI second
  • *
  • a well-defined algorithm must be specified to map each second in the accurate agreed * international civil time to each "second" in this time-scale
  • *

* Agreed international civil time is the base time-scale agreed by international convention, * which in 2012 is UTC (with leap-seconds). *

* In 2012, the definition of the Java time-scale is the same as UTC for all days except * those where a leap-second occurs. On days where a leap-second does occur, the time-scale * effectively eliminates the leap-second, maintaining the fiction of 86400 seconds in the day. * The approved well-defined algorithm to eliminate leap-seconds is specified as * UTC-SLS. *

* UTC-SLS is a simple algorithm that smoothes the leap-second over the last 1000 seconds of * the day, making each of the last 1000 seconds 1/1000th longer or shorter than an SI second. * Implementations built on an accurate leap-second aware time source should use UTC-SLS. * Use of a different algorithm risks confusion and misinterpretation of instants around a * leap-second and is discouraged. On the definition before 1972, I'm reluctant to get too deep into the definition (especially given that it doesn't really matter to anyone writing business software today). I'm proposing adding the final ", as per the principles of UT1". Anything else seems like over-definition, given that we handle dates back to one billion years BCE where no standards apply and where the definition "the solar day" seems as good as it can get. * One final problem is the definition of the agreed international civil time before the * introduction of modern UTC in 1972. This includes the Java epoch of {@code 1970-01-01}. * It is intended that instants before 1972 be interpreted based on the solar day divided * into 86400 subdivisions, as per the principles of UT1. Hope these are better! thanks Stephen ---------- From: *Zefram* Date: 2 April 2013 15:45 To: Stephen Colebourne Stephen Colebourne wrote: >I've updated the definition slightly, to require a clear algorithm as >part of the time-scale, and refer to UTC-SLS as the approved >algorithm. The wording now mixes up requirements with definitions. Most of the old definition now constitutes requirements, and the change in status should be reflected in the structure of the text. It could also do with clarification about how the precise definition is to be reached, and some other bits. >On the definition before 1972, I'm reluctant to get too deep into the >definition (especially given that it doesn't really matter to anyone >writing business software today). It doesn't take very much wording. It does need to be segregated out so that it's easy for the majority to ignore. Here's how I'd write the definition: The Java time scale divides each calendar day into exactly 86400 seconds. These seconds may differ from the SI second. It closely matches the de facto international standard time scale, the definition of which changes from time to time. The Java time scale is constructed piecewise from segments each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new piece of the Java time scale must be defined for it. Each segment must meet these requirements: * the Java time scale shall closely match the underlying international time scale; * the Java time scale shall exactly match the international time scale at noon each day; * the Java time scale shall have a precisely-defined relationship to the international time scale. For the period from 1972-10-27 (exact boundary discussed below) until further notice, the consensus international time scale is UTC (with leap seconds). In this period, the Java time scale is identical to UTC-SLS. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day. Implementations of the JSR-310 API are not required to provide any clock that is sub-second accurate, or indeed accurate at all, or that progresses monotonically or smoothly. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. Only implementations that claim sub-second accuracy are obliged to distinguish between the various flavours of UT. For the period prior to 1972-10-27, extending back arbitrarily far, the consensus international time scale is an ambiguous selection among UT1 and its smoothed variants, and the Java time scale is identical to UT2R. The exact boundary between this segment and the UTC-SLS segment is the instant when UT2R = UTC somewhere between 1972-10-26T12 and 1972-10-28T00. If the earlier segment should match UT1 instead of UT2R, the boundary would be when UT1 = UTC around 1972-11-03, specified range 1972-11-03T00 to 1972-11-04T12. The source I'm using for this computation declares an uncertainty of 1.9 ms in UT1-UTC, corresponding to uncertainty of about 14 hours in the time at which the time scales cross. Annoyingly, 1972 began with UTC already marginally ahead of both UT1 and UT2R, so there's no crossing of the time scales until after the 1972-06-30 leap. -zefram ---------- From: *Stephen Colebourne* Date: 2 April 2013 18:12 To: Zefram On 2 April 2013 15:45, Zefram wrote: > Here's how I'd write the definition: I like most of this. My thoughts are interspersed: > The Java time scale divides each calendar day into exactly 86400 I think I'd say "86400 subdivisions, referred to as seconds" > seconds. These seconds may differ from the SI second. It closely > matches the de facto international standard time scale, the definition > of which changes from time to time. "de facto international standard time scale" to "de facto international civil time scale" I still think that defining either UT1 or UR2R is wrong for the far past. Looking into their history, neither makes much sense as even the term UT is quite recent. I've seen other sources that suggest that UT2 isn't much used, at least compared to UT1. Sticking to something that clearly links to the solar day for the far past is more in line with actual history, where the sun rules the day. Perhaps the best option is to use UT1 back to an earlier point in time (such as the creation of UT1) and then a descriptive "solar day" before that - ie. adding another segment to the time-scale. thanks for your thoughts Stephen ---------- From: *Zefram* Date: 3 April 2013 08:47 To: Stephen Colebourne Stephen Colebourne wrote: >I think I'd say "86400 subdivisions, referred to as seconds" >"de facto international standard time scale" to "de facto >international civil time scale" These are fine. >I still think that defining either UT1 or UR2R is wrong for the far >past. Looking into their history, neither makes much sense as even the >term UT is quite recent. It doesn't matter when the term was defined. The time scales are well defined for any period when the Earth has a solid surface. > I've seen other sources that suggest that UT2 >isn't much used, at least compared to UT1. These days UT2 is essentially historical, yes. UT1 is actual Earth rotation, so we look at that if we're interested in Earth orientation, and it's what UTC tracks since 1972. Prior to 1972, UTC tracked UT2. That usage derives from the pre-atomic practice of synchronising time signals directly to UT2. This arose because, in that era, UT2 was the state of the art in generating a stable time scale. Note, this is a logically distinct purpose from tracking Earth orientation. Nowadays, the state of the art in generating a stable time scale from Earth rotation is UT2R. (The state of the art in generating a stable time scale without that constraint is TAI, of course.) >Sticking to something that clearly links to the solar day for the far >past is more in line with actual history, where the sun rules the day. Any form of UT does that. UT1 is by definition the solar day on the prime meridian, and all the other forms of UT closely track it. UTC isn't available for the far past, but UT1, and hence UT2R et al, are. >(such as the creation of UT1) UT1 wasn't created per se. The concept of UT1 is applicable retrospectively. (Unlike UTC, which can't exist for an era before it was defined.) The term "UT1" was devised to specifically refer to the globally-coherent form of UT, when it became necessary to correct for polar motion. The term "UT" was devised as an unambiguous and neutral name for what was already known as "GMT". There's continuity in the definitions. -zefram ---------- From: *Stephen Colebourne* Date: 3 April 2013 14:42 To: Zefram Is there a good link for UT1 as defined or implied in the far past? >From what you say, it sounds like it would be acceptable to use, as "the solar day onthe prime meridian" is exactly what I'm trying to define. Can I forward suitable sections of these emails to a public mailing list for transparancy? thanks Stephen ---------- From: *Zefram* Date: 3 April 2013 15:53 To: Stephen Colebourne Stephen Colebourne wrote: >Is there a good link for UT1 as defined or implied in the far past? The current definition of UT1, which is unfortunately a bit opaque, comes from the IAU 2000 meeting , resolution B1.8. It defines UT1 as a linear transformation of the Earth Rotation Angle (ERA), with no mention of range limits. (In this definition it is therefore not quite the same thing as solar time on the prime meridian, as it's affected by irregularities in the Earth's orbit. But the orbit is much more stable and more precisely understood than the Earth's rotation, so this is not a practical issue. Also liable to be fixed by a later redefinition.) The Earth Rotation Angle is defined (by the same resolution) in terms of the Non-Rotating Origin (NRO) reference frame. (It turns out that the Non-Rotating Origin does in fact rotate, very slowly. This too is likely to motivate a future redefinition.) The NRO is defined by a 1978 paper by Bernard Guinot . This too makes no mention of range limits. The applicability of the definitions to distant historical times is (I reckon) implicit; it's routine for astronomers to deal with large spans of time. As the definitions aren't explicit, it's useful to look at actual astronomical practice. The relevant application that immediately comes to mind is the use of ancient historical records of eclipses to determine the relationship between UT1 and TT (or other similarly uniform time scale). (Orbital calculations tell us very precisely when eclipses occurred in physical time, and a written record saying where (geographically) an eclipse was observed thus tells us which way the Earth was oriented at the time.) Steve Allen makes some mention of this at , with a nice graph at , looking back to -500 CE. He refers to a 2001 paper by Morrison & Stephenson , which refers to TT and UT for dates as far back as -1000 CE without any comment about the proleptic usage. (It does comment on the negative year number convention.) If you want a stronger answer than this, you'd better ask an astronomer. >"the solar day onthe prime meridian" is exactly what I'm trying to >define. Yes, "UT1" is the standard name for (mean) solar time on the prime meridian. >Can I forward suitable sections of these emails to a public mailing >list for transparancy? Sure. Everything I've said here can be made public. -zefram ---------- From: *Stephen Colebourne* Date: 4 April 2013 14:34 To: Zefram On 3 April 2013 15:53, Zefram wrote: >>"the solar day onthe prime meridian" is exactly what I'm trying to >>define. > > Yes, "UT1" is the standard name for (mean) solar time on the prime > meridian. OK, that should be OK then. So how about (most your text, but with a few tweaks): The Java time scale divides each calendar day into exactly 86400 subdivision, known as seconds. These seconds may differ from the SI second. It closely matches the de facto international civil time scale, the definition of which changes from time to time. The Java time scale has slightly different definitions for different segments of the time-line, each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new segment of the Java time scale must be defined for it. Each segment must meet these requirements: * the Java time scale shall closely match the underlying international civil time scale; * the Java time scale shall exactly match the international civil time scale at noon each day on the prime meridian (Greenwich); * the Java time scale shall have a precisely-defined relationship to the international civil time scale. There are currently, as of 2013, two segments in the Java time-scale. For the segment from 1972-11-03 (UTC) (exact boundary discussed below) until further notice, the consensus international time scale is UTC (with leap seconds). In this period, the Java time scale is identical to UTC-SLS [hyperlink]. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread equally over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day. Implementations of the JSR-310 API are not required to provide any clock that is sub-second accurate, or indeed accurate at all, or that progresses monotonically or smoothly. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. Only implementations that claim sub-second accuracy are obliged to distinguish between the various flavours of UT, and how conformant they are with the time-scale. For the segment prior to 1972-11-03 (UTC), extending back arbitrarily far, the consensus international time scale is defined to be UT1 extrapolated proleptically. This is equivalent to the (mean) solar time on the prime meridian (Greenwich). If implementing based on a specific set of UT1 data, then the exact boundary is where UT1 = UTC, which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) depending on the UT1 data. For the segment prior to 1972-11-03 (UTC), extending back arbitrarily far, the consensus international time scale is defined to be UT1 extrapolated proleptically. This is equivalent to the (mean) solar time on the prime meridian (Greenwich). If implementing based on a specific set of UT1 data, then the exact boundary is where UT1 = UTC, which may be up to 36 hours earlier or later than 1972-11-03T00:00Z (UTC) depending on the UT1 data. thanks Stephen From roger.riggs at oracle.com Fri Apr 5 10:47:38 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 05 Apr 2013 13:47:38 -0400 Subject: [threeten-dev] ChronoLocalDate Generic type parameters (#292) In-Reply-To: References: <515DE4A0.90200@oracle.com> Message-ID: <515F0E3A.4020804@oracle.com> Hi Stephen, There is time (at least a month) to consider this further and to make changes as needed. I would like to see some other folks experiences and I'll take a look at some date/time libraries and conversions of existing code. Thanks, Roger On 4/5/2013 5:42 AM, Stephen Colebourne wrote: > On 4 April 2013 21:37, roger riggs wrote: >> Some alternatives for include: >> >> 1. ChronoLocalDate - no parameterization >> 2. ChronoLocalDate >> 3. Removing the from return values. >> >> Though the simplicity of 1) removing the generics seems appealing, it >> disables application and library designs that can take advantage of the >> generic types because the fluent design would no longer pass through >> the generic type and all operations would return ChronoLocalDate. > Users either use a specific type, or the abstract interface, they > won't tend to fix the two, A method: > D process(D date) > will work perfectly in both cases > fooDate = process(fooDate) > clDate = process(clDate) > > The only thing "lost" is the ability to refer to one or more CLD > instances as being in the same calendar system, without specifying > which calendar system that is. This is no worse than j.u.Calendar > today, and in my view a rarer requirement. > >> 2) Removing just the constraint on the extends clause doesn't solve the >> original problem and isn't an improvement of any significance. >> >> 3) The original symptom and difficulty of using the wildcard generic types >> from >> the API has a couple alternatives for work arounds. >> The application can itself use the raw types by casting or assignment of the >> return value to take advantage of the lenient type matching of raw types. >> The code compiles and runs correctly though the compiler produces >> warnings about raw type and unchecked assignments which can be suppressed >> selectively or in an appropriate scope. > No solution involving raw types on a public API would be acceptable to me, > >> I would recommend against changing the type parameters; we're trying >> to freeze for the next build and integration. The current parameter usage >> follows the general recommendations for generic types and the alternatives >> are not clear improvements on all points. I'd like to get a bit more >> experience >> with the API before making changes. > So long as we can still make a change, its fine to leave it for now. > > Stephen From roger.riggs at oracle.com Fri Apr 5 11:20:45 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 05 Apr 2013 14:20:45 -0400 Subject: [threeten-dev] [threeten-develop] Leap seconds and the Java time-scale In-Reply-To: References: Message-ID: <515F15FD.5020208@oracle.com> Hi Stephen, It seems like a reasonable description. The lack of requirements for to be a clock (monotonic, accurate, etc), may put off some application developers. Where will they go for assurances that make their applications run reliably. The last two paragraphs seems to be duplicated except for the difference between 18 and 36 hours. Roger On 4/5/2013 11:43 AM, Stephen Colebourne wrote: > I've been corresponding with Zefram recently about the API, > specifically around leap seconds and the Java time-scale that we > define to avoid exposing leap seconds. Zerfram knows far more than I > do about UTC/UT1/UT2/.. and the alphabet soup of time-scale acronyms, > as has provided some excellent feedback, which I have permission to > publish excerpts of for transparancy (at the end of this email). > > I'm currently proposing this as the new text for the time-scale. Its > more precise than we currently have, yet doesn't change any code or > implementation behaviour, and also allows for future change. > > The current text is in the class Javadoc here: > http://hg.openjdk.java.net/threeten/threeten/jdk/file/e184e025210a/src/share/classes/java/time/Instant.java > > " > The Java time scale divides each calendar day into exactly 86400 > subdivision, known as seconds. These seconds may differ from the SI > second. It closely matches the de facto international civil time > scale, the definition of which changes from time to time. > > The Java time scale has slightly different definitions for different > segments of the time-line, each based on the consensus international > time scale that is used as the basis for civil time. Whenever the > internationally-agreed time scale is modified or replaced, a new > segment of the Java time scale must be defined for it. Each segment > must meet these requirements: > > * the Java time scale shall closely match the underlying > international civil time scale; > > * the Java time scale shall exactly match the international civil > time scale at noon each day on the prime meridian (Greenwich); > > * the Java time scale shall have a precisely-defined relationship to > the international civil time scale. > > There are currently, as of 2013, two segments in the Java time-scale. > > For the segment from 1972-11-03 (UTC) (exact boundary discussed below) > until further notice, the consensus international time scale is UTC > (with leap seconds). In this period, the Java time scale is identical > to UTC-SLS [hyperlink]. This is identical to UTC on days that do not > have a leap second. On days that do have a leap second, the leap > second is spread equally over the last 1000 seconds of the day, > maintaining the appearance of exactly 86400 seconds per day. > > Implementations of the JSR-310 API are not required to provide any > clock that is sub-second accurate, or indeed accurate at all, or that > progresses monotonically or smoothly. Implementations are therefore > not required to actually perform the UTC-SLS slew or to otherwise be > aware of leap seconds. Only implementations that claim sub-second > accuracy are obliged to distinguish between the various flavours of > UT, and how conformant they are with the time-scale. > > For the segment prior to 1972-11-03 (UTC), extending back arbitrarily > far, the consensus international time scale is defined to be UT1 > extrapolated proleptically. This is equivalent to the (mean) solar > time on the prime meridian (Greenwich). If implementing based on a > specific set of UT1 data, then the exact boundary is where UT1 = UTC, > which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) > depending on the UT1 data. > > For the segment prior to 1972-11-03 (UTC), extending back arbitrarily > far, the consensus international time scale is defined to be UT1 > extrapolated proleptically. This is equivalent to the (mean) solar > time on the prime meridian (Greenwich). If implementing based on a > specific set of UT1 data, then the exact boundary is where UT1 = UTC, > which may be up to 36 hours earlier or later than 1972-11-03T00:00Z > (UTC) depending on the UT1 data. > " > > Feedback welcome. > Stephen > > ----------------------------------------------------------------- > > > Forwarded conversation > Subject: *Java definitions* > ------------------------ > > From: *Stephen Colebourne* > > Date: 30 March 2013 00:09 > To: Zefram > > Hi Zefram, > Good to meet you on Thursday. > > I've updated the definition slightly, to require a clear algorithm as > part of the time-scale, and refer to UTC-SLS as the approved > algorithm. This seems to me to be a firmer definition than before, > without totally closing the door to other implementations and changes > (which I need to allow for). In particular, if UTC were to be changed > in 2014 to have an official smoothing algorithm other than UTC-SLS, > then I want some wiggle room to be able to adapt. > > * Given the complexity of accurate timekeeping described above, this > Java API defines > * its own time-scale with a simplification. The Java time-scale is > defined as follows: > *

    > *
  • midday will always be exactly as defined by the agreed > international civil time
  • > *
  • other times during the day will be broadly in line with the > agreed international civil time
  • > *
  • the day will be divided into exactly 86400 subdivisions, > referred to as "seconds"
  • > *
  • the Java "second" may differ from an SI second
  • > *
  • a well-defined algorithm must be specified to map each second > in the accurate agreed > * international civil time to each "second" in this time-scale
  • > *

> * Agreed international civil time is the base time-scale agreed by > international convention, > * which in 2012 is UTC (with leap-seconds). > *

> * In 2012, the definition of the Java time-scale is the same as UTC > for all days except > * those where a leap-second occurs. On days where a leap-second does > occur, the time-scale > * effectively eliminates the leap-second, maintaining the fiction of > 86400 seconds in the day. > * The approved well-defined algorithm to eliminate leap-seconds is > specified as > * UTC-SLS. > *

> * UTC-SLS is a simple algorithm that smoothes the leap-second over > the last 1000 seconds of > * the day, making each of the last 1000 seconds 1/1000th longer or > shorter than an SI second. > * Implementations built on an accurate leap-second aware time source > should use UTC-SLS. > * Use of a different algorithm risks confusion and misinterpretation > of instants around a > * leap-second and is discouraged. > > On the definition before 1972, I'm reluctant to get too deep into the > definition (especially given that it doesn't really matter to anyone > writing business software today). I'm proposing adding the final ", as > per the principles of UT1". Anything else seems like over-definition, > given that we handle dates back to one billion years BCE where no > standards apply and where the definition "the solar day" seems as good > as it can get. > > * One final problem is the definition of the agreed international > civil time before the > * introduction of modern UTC in 1972. This includes the Java epoch of > {@code 1970-01-01}. > * It is intended that instants before 1972 be interpreted based on > the solar day divided > * into 86400 subdivisions, as per the principles of UT1. > > Hope these are better! > thanks > Stephen > > ---------- > From: *Zefram* > Date: 2 April 2013 15:45 > To: Stephen Colebourne > > > > Stephen Colebourne wrote: > >I've updated the definition slightly, to require a clear algorithm as > >part of the time-scale, and refer to UTC-SLS as the approved > >algorithm. > > The wording now mixes up requirements with definitions. Most of the > old definition now constitutes requirements, and the change in status > should be reflected in the structure of the text. It could also do > with clarification about how the precise definition is to be reached, > and some other bits. > > >On the definition before 1972, I'm reluctant to get too deep into the > >definition (especially given that it doesn't really matter to anyone > >writing business software today). > > It doesn't take very much wording. It does need to be segregated out > so that it's easy for the majority to ignore. > > Here's how I'd write the definition: > > The Java time scale divides each calendar day into exactly 86400 > seconds. These seconds may differ from the SI second. It closely > matches the de facto international standard time scale, the definition > of which changes from time to time. > > The Java time scale is constructed piecewise from segments each based > on the consensus international time scale that is used as the basis > for civil time. Whenever the internationally-agreed time scale is > modified or replaced, a new piece of the Java time scale must be > defined for it. Each segment must meet these requirements: > > * the Java time scale shall closely match the underlying international > time scale; > > * the Java time scale shall exactly match the international time > scale at noon each day; > > * the Java time scale shall have a precisely-defined relationship > to the international time scale. > > For the period from 1972-10-27 (exact boundary discussed below) > until further notice, the consensus international time scale is > UTC (with leap seconds). In this period, the Java time scale is > identical to UTC-SLS. This is identical to UTC on days that do not > have a leap second. On days that do have a leap second, the leap > second is spread over the last 1000 seconds of the day, maintaining > the appearance of exactly 86400 seconds per day. > > Implementations of the JSR-310 API are not required to provide > any clock that is sub-second accurate, or indeed accurate at all, > or that progresses monotonically or smoothly. Implementations are > therefore not required to actually perform the UTC-SLS slew or to > otherwise be aware of leap seconds. Only implementations that claim > sub-second accuracy are obliged to distinguish between the various > flavours of UT. > > For the period prior to 1972-10-27, extending back arbitrarily far, > the consensus international time scale is an ambiguous selection > among UT1 and its smoothed variants, and the Java time scale is > identical to UT2R. The exact boundary between this segment and the > UTC-SLS segment is the instant when UT2R = UTC somewhere between > 1972-10-26T12 and 1972-10-28T00. > > If the earlier segment should match UT1 instead of UT2R, the boundary > would be when UT1 = UTC around 1972-11-03, specified range 1972-11-03T00 > to 1972-11-04T12. The source I'm using for this computation declares > an uncertainty of 1.9 ms in UT1-UTC, corresponding to uncertainty of > about 14 hours in the time at which the time scales cross. Annoyingly, > 1972 began with UTC already marginally ahead of both UT1 and UT2R, > so there's no crossing of the time scales until after the 1972-06-30 leap. > > -zefram > > ---------- > From: *Stephen Colebourne* > > Date: 2 April 2013 18:12 > To: Zefram > > On 2 April 2013 15:45, Zefram > wrote: > > Here's how I'd write the definition: > > I like most of this. My thoughts are interspersed: > > > The Java time scale divides each calendar day into exactly 86400 > > I think I'd say "86400 subdivisions, referred to as seconds" > > > seconds. These seconds may differ from the SI second. It closely > > matches the de facto international standard time scale, the > definition > > of which changes from time to time. > > "de facto international standard time scale" to "de facto > international civil time scale" > I still think that defining either UT1 or UR2R is wrong for the far > past. Looking into their history, neither makes much sense as even the > term UT is quite recent. I've seen other sources that suggest that UT2 > isn't much used, at least compared to UT1. > > Sticking to something that clearly links to the solar day for the far > past is more in line with actual history, where the sun rules the day. > > Perhaps the best option is to use UT1 back to an earlier point in time > (such as the creation of UT1) and then a descriptive "solar day" > before that - ie. adding another segment to the time-scale. > > thanks for your thoughts > Stephen > > ---------- > From: *Zefram* > Date: 3 April 2013 08:47 > To: Stephen Colebourne > > > Stephen Colebourne wrote: > >I think I'd say "86400 subdivisions, referred to as seconds" > > >"de facto international standard time scale" to "de facto > >international civil time scale" > > These are fine. > > >I still think that defining either UT1 or UR2R is wrong for the far > >past. Looking into their history, neither makes much sense as even the > >term UT is quite recent. > > It doesn't matter when the term was defined. The time scales are well > defined for any period when the Earth has a solid surface. > > > I've seen other sources that suggest that UT2 > >isn't much used, at least compared to UT1. > > These days UT2 is essentially historical, yes. UT1 is actual Earth > rotation, so we look at that if we're interested in Earth orientation, > and it's what UTC tracks since 1972. Prior to 1972, UTC tracked UT2. > That usage derives from the pre-atomic practice of synchronising time > signals directly to UT2. This arose because, in that era, UT2 was the > state of the art in generating a stable time scale. Note, this is a > logically distinct purpose from tracking Earth orientation. Nowadays, > the state of the art in generating a stable time scale from Earth rotation > is UT2R. (The state of the art in generating a stable time scale without > that constraint is TAI, of course.) > > >Sticking to something that clearly links to the solar day for the far > >past is more in line with actual history, where the sun rules the day. > > Any form of UT does that. UT1 is by definition the solar day on > the prime meridian, and all the other forms of UT closely track it. > UTC isn't available for the far past, but UT1, and hence UT2R et al, are. > > >(such as the creation of UT1) > > UT1 wasn't created per se. The concept of UT1 is applicable > retrospectively. (Unlike UTC, which can't exist for an era before it > was defined.) > > The term "UT1" was devised to specifically refer to the globally-coherent > form of UT, when it became necessary to correct for polar motion. > The term "UT" was devised as an unambiguous and neutral name for what > was already known as "GMT". There's continuity in the definitions. > > -zefram > > ---------- > From: *Stephen Colebourne* > > Date: 3 April 2013 14:42 > To: Zefram > > > Is there a good link for UT1 as defined or implied in the far past? > >From what you say, it sounds like it would be acceptable to use, as > "the solar day onthe prime meridian" is exactly what I'm trying to > define. > > Can I forward suitable sections of these emails to a public mailing > list for transparancy? > > thanks > Stephen > > ---------- > From: *Zefram* > Date: 3 April 2013 15:53 > To: Stephen Colebourne > > > > Stephen Colebourne wrote: > >Is there a good link for UT1 as defined or implied in the far past? > > The current definition of UT1, which is unfortunately > a bit opaque, comes from the IAU 2000 meeting > , resolution B1.8. > It defines UT1 as a linear transformation of the Earth Rotation Angle > (ERA), with no mention of range limits. (In this definition it is > therefore not quite the same thing as solar time on the prime meridian, > as it's affected by irregularities in the Earth's orbit. But the orbit is > much more stable and more precisely understood than the Earth's rotation, > so this is not a practical issue. Also liable to be fixed by a later > redefinition.) > > The Earth Rotation Angle is defined (by the same resolution) in terms of > the Non-Rotating Origin (NRO) reference frame. (It turns out that the > Non-Rotating Origin does in fact rotate, very slowly. This too is likely > to motivate a future redefinition.) The NRO is defined by a 1978 paper > by Bernard Guinot . > This too makes no mention of range limits. The applicability of the > definitions to distant historical times is (I reckon) implicit; it's > routine for astronomers to deal with large spans of time. > > As the definitions aren't explicit, it's useful to look at actual > astronomical practice. The relevant application that immediately > comes to mind is the use of ancient historical records of eclipses > to determine the relationship between UT1 and TT (or other similarly > uniform time scale). (Orbital calculations tell us very precisely when > eclipses occurred in physical time, and a written record saying where > (geographically) an eclipse was observed thus tells us which way the > Earth was oriented at the time.) Steve Allen makes some mention of > this at >, with a nice > graph at >, looking > back to -500 CE. He refers to a 2001 paper by Morrison & Stephenson > , which refers to > TT and UT for dates as far back as -1000 CE without any comment about > the proleptic usage. (It does comment on the negative year number > convention.) > > If you want a stronger answer than this, you'd better ask an astronomer. > > >"the solar day onthe prime meridian" is exactly what I'm trying to > >define. > > Yes, "UT1" is the standard name for (mean) solar time on the prime > meridian. > > >Can I forward suitable sections of these emails to a public mailing > >list for transparancy? > > Sure. Everything I've said here can be made public. > > -zefram > > ---------- > From: *Stephen Colebourne* > > Date: 4 April 2013 14:34 > To: Zefram > > On 3 April 2013 15:53, Zefram > wrote: > >>"the solar day onthe prime meridian" is exactly what I'm trying to > >>define. > > > > Yes, "UT1" is the standard name for (mean) solar time on the prime > > meridian. > > OK, that should be OK then. So how about (most your text, but with a > few tweaks): > > The Java time scale divides each calendar day into exactly 86400 > subdivision, known as seconds. These seconds may differ from the SI > second. It closely matches the de facto international civil time > scale, the definition of which changes from time to time. > > The Java time scale has slightly different definitions for different > segments of the time-line, each based on the consensus international > time scale that is used as the basis for civil time. Whenever the > internationally-agreed time scale is modified or replaced, a new > segment of the Java time scale must be defined for it. Each segment > must meet these requirements: > > * the Java time scale shall closely match the underlying > international civil time scale; > > * the Java time scale shall exactly match the international civil > time scale at noon each day on the prime meridian (Greenwich); > > * the Java time scale shall have a precisely-defined relationship to > the international civil time scale. > > There are currently, as of 2013, two segments in the Java time-scale. > > For the segment from 1972-11-03 (UTC) (exact boundary discussed below) > until further notice, the consensus international time scale is UTC > (with leap seconds). In this period, the Java time scale is identical > to UTC-SLS [hyperlink]. This is identical to UTC on days that do not > have a leap second. On days that do have a leap second, the leap > second is spread equally over the last 1000 seconds of the day, > maintaining the appearance of exactly 86400 seconds per day. > > Implementations of the JSR-310 API are not required to provide any > clock that is sub-second accurate, or indeed accurate at all, or that > progresses monotonically or smoothly. Implementations are therefore > not required to actually perform the UTC-SLS slew or to otherwise be > aware of leap seconds. Only implementations that claim sub-second > accuracy are obliged to distinguish between the various flavours of > UT, and how conformant they are with the time-scale. > > For the segment prior to 1972-11-03 (UTC), extending back arbitrarily > far, the consensus international time scale is defined to be UT1 > extrapolated proleptically. This is equivalent to the (mean) solar > time on the prime meridian (Greenwich). If implementing based on a > specific set of UT1 data, then the exact boundary is where UT1 = UTC, > which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) > depending on the UT1 data. > > For the segment prior to 1972-11-03 (UTC), extending back arbitrarily > far, the consensus international time scale is defined to be UT1 > extrapolated proleptically. This is equivalent to the (mean) solar > time on the prime meridian (Greenwich). If implementing based on a > specific set of UT1 data, then the exact boundary is where UT1 = UTC, > which may be up to 36 hours earlier or later than 1972-11-03T00:00Z > (UTC) depending on the UT1 data. > > thanks > Stephen > > > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From xueming.shen at oracle.com Fri Apr 5 11:39:54 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 05 Apr 2013 11:39:54 -0700 Subject: [threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE In-Reply-To: References: <515DF06A.8020604@oracle.com> Message-ID: <515F1A7A.6090404@oracle.com> On 04/05/2013 03:55 AM, Stephen Colebourne wrote: > > >> It appears FileTime have to have its own "format/toStrong" instant >> of leveraging the JSR310 formatting mainly because >> >> 1) it follows the existing jdk/"old" ISO 8601 formatting behavior for BCE >> years, in which dis-allows the 0000 for proleptic year 0. >> >> 2) LocalTime formats the "ss" part optionally. It appears to takes the >> "it is acceptable to omit lower order time elements..." alternative. >> >> 3) FileTime formats the "fraction of second" part as "decimal fraction" >> while LT uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips >> any tailing zero, but LD does not if it fits into the 3-letter unit. >> Stephen, any reason behind this design decision, or it is specified >> by the standard. > LocalTime has to pretend that it is multiple classes (to avoid class > combination explosion). So, it pretends to be an HourMin class, by > printing a suitable toString, it also pretends to be an HourMinSec > class. For decimal fractions it is also more consistent with > SimpleDateFormat to show all three digits for millis. > > Using DateTimeFormatterBuilder, you can easily produce a formatter > that can format/parse the FileTime format however. > > builder > .appendText(ERA, mapOfZeroToMinusSignAndOneToEmptyString) > .appendValue(YEAR_OF_ERA, 4) > ... > .appendFraction(NANO_OF_SECOND, 0, 9) > You can always use pattern, I'm a little concerned about the performance. But since it's immtable, so the formatter can be shared. Will try later after some measurement. >> Here is the "draft" of the FileTime change, comment and suggestion >> appreciated. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/ > to(TimeUnit unit) > unit.convert(instant.getEpochSecond(), TimeUnit.SECONDS) + > unit.convert(instant.getNano(), TimeUnit.NANOSECONDS); > will not saturate correctly to MIN/MAX > > toMillis() > instant.toEpochMilli(); will throw ArithmeticException, so you'll have > to catch and convert to MIN/MAX. > > hashCode() > Because toInstant() can't repesent all values of FileTime, the > hashCode's uniqueness is compromised. > > Same truncation problem in toString() > Also, you have a one line if statement which is misisng its braces. > > > An alternate approach would be to convert on input to the existing the > long+TimeUnit storage mechanism. Conversion would be immediate, and > could spot trailing zeroes in the Instant and choose a larger > TimeUnit. Truncation would be possible, but unlikely. > You will have the same "truncation" problem, though being consistent with the hash/equal...I don't think the truncation will cause real problem in real application, but might need better wording in spec to clarify. > Really, I would prefer to see the class changed to be a > TemporalAccessor. That way, it could return INSTANT_SECONDS and be > passed directly to the formatter (which handles values greater than > Instant.MAX). This would require a simple enhancement to the instant > formatter to control fractional seconds (which is needed and I'm > raising an issue for). It can be address later, we can always to implement TemporalAccessor, if desired/requested later. Who will really need a FileTime beyond Instant.MIN/MAX? :-) -Sherman > Stephen From douglas.surber at oracle.com Fri Apr 5 12:59:48 2013 From: douglas.surber at oracle.com (Douglas Surber) Date: Fri, 05 Apr 2013 12:59:48 -0700 Subject: [threeten-dev] [threeten-develop] Leap seconds and the Java time-scale In-Reply-To: <515F15FD.5020208@oracle.com> References: <515F15FD.5020208@oracle.com> Message-ID: <6.2.5.6.2.20130405124316.05bcc328@oracle.com> Given the lack of requirements for a clock it would be useful to add some methods that characterize the clock. Example: public enum Monotonicity { UNKNOWN; NONMONOTONIC; MONOTONIC_DEPENDENT; MONOTONIC_INDEPENDENT; } public Monotonicity getMonotonicity(); public Duration getPrecision(); MONOTONIC_DEPENDENT means the clock is monotonic so long as some other time source external to the JVM (the OS) is monotonic. If the sysadmin changes the system clock, time may go backwards. MONOTONIC_INDEPENDENT means the clock is monotonic regardless of any other time source. getPrecision returns the least Duration such that the passage of that amount of physical time will guarantee that now() returns a different value. The returned value is the ideal assuming MONOTONIC_INDEPENDENT. If getMonoticity returns some other value then the returned precision will be incorrect when the clock is not behaving MONOTONIC_INDEPENDENT, such as when the sysadmin is changing the system clock. Just thinking out loud. Douglas At 11:20 AM 4/5/2013, roger riggs wrote: >Hi Stephen, > >It seems like a reasonable description. >The lack of requirements for to be a clock (monotonic, accurate, >etc), >may put off some application developers. Where will they go for >assurances >that make their applications run reliably. > >The last two paragraphs seems to be duplicated except for the >difference >between 18 and 36 hours. > >Roger > > >On 4/5/2013 11:43 AM, Stephen Colebourne wrote: >>I've been corresponding with Zefram recently about the API, >>specifically around leap seconds and the Java time-scale that we >>define to avoid exposing leap seconds. Zerfram knows far more than >>I do about UTC/UT1/UT2/.. and the alphabet soup of time-scale >>acronyms, as has provided some excellent feedback, which I have >>permission to publish excerpts of for transparancy (at the end of >>this email). >> >>I'm currently proposing this as the new text for the time-scale. >>Its more precise than we currently have, yet doesn't change any >>code or implementation behaviour, and also allows for future change. >> >>The current text is in the class Javadoc here: >>http://hg.openjdk.java.net/threeten/threeten/jdk/file/e184e025210a/src/share/classes/java/time/Instant.java >> >>" >>The Java time scale divides each calendar day into exactly 86400 >>subdivision, known as seconds. These seconds may differ from the >>SI >>second. It closely matches the de facto international civil time >>scale, the definition of which changes from time to time. >> >>The Java time scale has slightly different definitions for >>different >>segments of the time-line, each based on the consensus >>international >>time scale that is used as the basis for civil time. Whenever the >>internationally-agreed time scale is modified or replaced, a new >>segment of the Java time scale must be defined for it. Each >>segment >>must meet these requirements: >> >> * the Java time scale shall closely match the underlying >>international civil time scale; >> >> * the Java time scale shall exactly match the international civil >>time scale at noon each day on the prime meridian (Greenwich); >> >> * the Java time scale shall have a precisely-defined relationship >> to >>the international civil time scale. >> >>There are currently, as of 2013, two segments in the Java >>time-scale. >> >>For the segment from 1972-11-03 (UTC) (exact boundary discussed >>below) >>until further notice, the consensus international time scale is UTC >>(with leap seconds). In this period, the Java time scale is >>identical >>to UTC-SLS [hyperlink]. This is identical to UTC on days that do >>not >>have a leap second. On days that do have a leap second, the leap >>second is spread equally over the last 1000 seconds of the day, >>maintaining the appearance of exactly 86400 seconds per day. >> >>Implementations of the JSR-310 API are not required to provide any >>clock that is sub-second accurate, or indeed accurate at all, or >>that >>progresses monotonically or smoothly. Implementations are therefore >>not required to actually perform the UTC-SLS slew or to otherwise >>be >>aware of leap seconds. Only implementations that claim sub-second >>accuracy are obliged to distinguish between the various flavours of >>UT, and how conformant they are with the time-scale. >> >>For the segment prior to 1972-11-03 (UTC), extending back >>arbitrarily >>far, the consensus international time scale is defined to be UT1 >>extrapolated proleptically. This is equivalent to the (mean) solar >>time on the prime meridian (Greenwich). If implementing based on a >>specific set of UT1 data, then the exact boundary is where UT1 = >>UTC, >>which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) >>depending on the UT1 data. >> >>For the segment prior to 1972-11-03 (UTC), extending back >>arbitrarily >>far, the consensus international time scale is defined to be UT1 >>extrapolated proleptically. This is equivalent to the (mean) solar >>time on the prime meridian (Greenwich). If implementing based on a >>specific set of UT1 data, then the exact boundary is where UT1 = >>UTC, >>which may be up to 36 hours earlier or later than 1972-11-03T00:00Z >>(UTC) depending on the UT1 data. >>" >> >>Feedback welcome. >>Stephen >> >>----------------------------------------------------------------- >> >> >>Forwarded conversation >>Subject: *Java definitions* >>------------------------ >> >>From: *Stephen Colebourne* >> >>Date: 30 March 2013 00:09 >>To: Zefram >> >>Hi Zefram, >>Good to meet you on Thursday. >> >>I've updated the definition slightly, to require a clear algorithm >>as >>part of the time-scale, and refer to UTC-SLS as the approved >>algorithm. This seems to me to be a firmer definition than before, >>without totally closing the door to other implementations and >>changes >>(which I need to allow for). In particular, if UTC were to be >>changed >>in 2014 to have an official smoothing algorithm other than UTC-SLS, >>then I want some wiggle room to be able to adapt. >> >> * Given the complexity of accurate timekeeping described above, >> this >>Java API defines >> * its own time-scale with a simplification. The Java time-scale >> is >>defined as follows: >> *

    >> *
  • midday will always be exactly as defined by the agreed >>international civil time
  • >> *
  • other times during the day will be broadly in line with the >>agreed international civil time
  • >> *
  • the day will be divided into exactly 86400 subdivisions, >>referred to as "seconds"
  • >> *
  • the Java "second" may differ from an SI second
  • >> *
  • a well-defined algorithm must be specified to map each >> second >>in the accurate agreed >> * international civil time to each "second" in this >> time-scale
  • >> *

>> * Agreed international civil time is the base time-scale agreed >> by >>international convention, >> * which in 2012 is UTC (with leap-seconds). >> *

>> * In 2012, the definition of the Java time-scale is the same as >> UTC >>for all days except >> * those where a leap-second occurs. On days where a leap-second >> does >>occur, the time-scale >> * effectively eliminates the leap-second, maintaining the fiction >> of >>86400 seconds in the day. >> * The approved well-defined algorithm to eliminate leap-seconds >> is specified as >> * UTC-SLS. >> *

>> * UTC-SLS is a simple algorithm that smoothes the leap-second >> over >>the last 1000 seconds of >> * the day, making each of the last 1000 seconds 1/1000th longer >> or >>shorter than an SI second. >> * Implementations built on an accurate leap-second aware time >> source >>should use UTC-SLS. >> * Use of a different algorithm risks confusion and >> misinterpretation >>of instants around a >> * leap-second and is discouraged. >> >>On the definition before 1972, I'm reluctant to get too deep into >>the >>definition (especially given that it doesn't really matter to >>anyone >>writing business software today). I'm proposing adding the final ", >>as >>per the principles of UT1". Anything else seems like >>over-definition, >>given that we handle dates back to one billion years BCE where no >>standards apply and where the definition "the solar day" seems as >>good >>as it can get. >> >> * One final problem is the definition of the agreed international >>civil time before the >> * introduction of modern UTC in 1972. This includes the Java >> epoch of >>{@code 1970-01-01}. >> * It is intended that instants before 1972 be interpreted based >> on >>the solar day divided >> * into 86400 subdivisions, as per the principles of UT1. >> >>Hope these are better! >>thanks >>Stephen >> >>---------- >>From: *Zefram* >>Date: 2 April 2013 15:45 >>To: Stephen Colebourne >> >> >> >>Stephen Colebourne wrote: >> >I've updated the definition slightly, to require a clear >> algorithm as >> >part of the time-scale, and refer to UTC-SLS as the approved >> >algorithm. >> >>The wording now mixes up requirements with definitions. Most of >>the >>old definition now constitutes requirements, and the change in >>status >>should be reflected in the structure of the text. It could also do >>with clarification about how the precise definition is to be >>reached, >>and some other bits. >> >> >On the definition before 1972, I'm reluctant to get too deep into >> the >> >definition (especially given that it doesn't really matter to >> anyone >> >writing business software today). >> >>It doesn't take very much wording. It does need to be segregated >>out >>so that it's easy for the majority to ignore. >> >>Here's how I'd write the definition: >> >> The Java time scale divides each calendar day into exactly >> 86400 >> seconds. These seconds may differ from the SI second. It >> closely >> matches the de facto international standard time scale, the >> definition >> of which changes from time to time. >> >> The Java time scale is constructed piecewise from segments >> each based >> on the consensus international time scale that is used as the >> basis >> for civil time. Whenever the internationally-agreed time >> scale is >> modified or replaced, a new piece of the Java time scale must >> be >> defined for it. Each segment must meet these requirements: >> >> * the Java time scale shall closely match the underlying >> international >> time scale; >> >> * the Java time scale shall exactly match the international >> time >> scale at noon each day; >> >> * the Java time scale shall have a precisely-defined >> relationship >> to the international time scale. >> >> For the period from 1972-10-27 (exact boundary discussed >> below) >> until further notice, the consensus international time scale >> is >> UTC (with leap seconds). In this period, the Java time scale >> is >> identical to UTC-SLS. This is identical to UTC on days that >> do not >> have a leap second. On days that do have a leap second, the >> leap >> second is spread over the last 1000 seconds of the day, >> maintaining >> the appearance of exactly 86400 seconds per day. >> >> Implementations of the JSR-310 API are not required to provide >> any clock that is sub-second accurate, or indeed accurate at >> all, >> or that progresses monotonically or smoothly. Implementations >> are >> therefore not required to actually perform the UTC-SLS slew or >> to >> otherwise be aware of leap seconds. Only implementations that >> claim >> sub-second accuracy are obliged to distinguish between the >> various >> flavours of UT. >> >> For the period prior to 1972-10-27, extending back arbitrarily >> far, >> the consensus international time scale is an ambiguous >> selection >> among UT1 and its smoothed variants, and the Java time scale >> is >> identical to UT2R. The exact boundary between this segment >> and the >> UTC-SLS segment is the instant when UT2R = UTC somewhere >> between >> 1972-10-26T12 and 1972-10-28T00. >> >>If the earlier segment should match UT1 instead of UT2R, the >>boundary >>would be when UT1 = UTC around 1972-11-03, specified range >>1972-11-03T00 >>to 1972-11-04T12. The source I'm using for this computation >>declares >>an uncertainty of 1.9 ms in UT1-UTC, corresponding to uncertainty >>of >>about 14 hours in the time at which the time scales >>cross. Annoyingly, >>1972 began with UTC already marginally ahead of both UT1 and UT2R, >>so there's no crossing of the time scales until after the >>1972-06-30 leap. >> >>-zefram >> >>---------- >>From: *Stephen Colebourne* >> >>Date: 2 April 2013 18:12 >>To: Zefram >> >>On 2 April 2013 15:45, Zefram >> wrote: >> > Here's how I'd write the definition: >> >>I like most of this. My thoughts are interspersed: >> >> > The Java time scale divides each calendar day into exactly >> 86400 >> >>I think I'd say "86400 subdivisions, referred to as seconds" >> >> > seconds. These seconds may differ from the SI second. It >> closely >> > matches the de facto international standard time scale, the >> definition >> > of which changes from time to time. >> >>"de facto international standard time scale" to "de facto >>international civil time scale" >>I still think that defining either UT1 or UR2R is wrong for the far >>past. Looking into their history, neither makes much sense as even >>the >>term UT is quite recent. I've seen other sources that suggest that >>UT2 >>isn't much used, at least compared to UT1. >> >>Sticking to something that clearly links to the solar day for the >>far >>past is more in line with actual history, where the sun rules the >>day. >> >>Perhaps the best option is to use UT1 back to an earlier point in >>time >>(such as the creation of UT1) and then a descriptive "solar day" >>before that - ie. adding another segment to the time-scale. >> >>thanks for your thoughts >>Stephen >> >>---------- >>From: *Zefram* >>Date: 3 April 2013 08:47 >>To: Stephen Colebourne >> >> >>Stephen Colebourne wrote: >> >I think I'd say "86400 subdivisions, referred to as seconds" >> >> >"de facto international standard time scale" to "de facto >> >international civil time scale" >> >>These are fine. >> >> >I still think that defining either UT1 or UR2R is wrong for the >> far >> >past. Looking into their history, neither makes much sense as >> even the >> >term UT is quite recent. >> >>It doesn't matter when the term was defined. The time scales are >>well >>defined for any period when the Earth has a solid surface. >> >> > I've seen other sources that suggest >> that UT2 >> >isn't much used, at least compared to UT1. >> >>These days UT2 is essentially historical, yes. UT1 is actual Earth >>rotation, so we look at that if we're interested in Earth >>orientation, >>and it's what UTC tracks since 1972. Prior to 1972, UTC tracked >>UT2. >>That usage derives from the pre-atomic practice of synchronising >>time >>signals directly to UT2. This arose because, in that era, UT2 was >>the >>state of the art in generating a stable time scale. Note, this is >>a >>logically distinct purpose from tracking Earth >>orientation. Nowadays, >>the state of the art in generating a stable time scale from Earth >>rotation >>is UT2R. (The state of the art in generating a stable time scale >>without >>that constraint is TAI, of course.) >> >> >Sticking to something that clearly links to the solar day for the >> far >> >past is more in line with actual history, where the sun rules the >> day. >> >>Any form of UT does that. UT1 is by definition the solar day on >>the prime meridian, and all the other forms of UT closely track it. >>UTC isn't available for the far past, but UT1, and hence UT2R et >>al, are. >> >> >(such as the creation of UT1) >> >>UT1 wasn't created per se. The concept of UT1 is applicable >>retrospectively. (Unlike UTC, which can't exist for an era before >>it >>was defined.) >> >>The term "UT1" was devised to specifically refer to the >>globally-coherent >>form of UT, when it became necessary to correct for polar motion. >>The term "UT" was devised as an unambiguous and neutral name for >>what >>was already known as "GMT". There's continuity in the definitions. >> >>-zefram >> >>---------- >>From: *Stephen Colebourne* >> >>Date: 3 April 2013 14:42 >>To: Zefram >> >> >>Is there a good link for UT1 as defined or implied in the far past? >> >From what you say, it sounds like it would be acceptable to use, >> as >>"the solar day onthe prime meridian" is exactly what I'm trying to >>define. >> >>Can I forward suitable sections of these emails to a public mailing >>list for transparancy? >> >>thanks >>Stephen >> >>---------- >>From: *Zefram* >>Date: 3 April 2013 15:53 >>To: Stephen Colebourne >> >> >> >>Stephen Colebourne wrote: >> >Is there a good link for UT1 as defined or implied in the far >> past? >> >>The current definition of UT1, which is unfortunately >>a bit opaque, comes from the IAU 2000 meeting >>, resolution >>B1.8. >>It defines UT1 as a linear transformation of the Earth Rotation >>Angle >>(ERA), with no mention of range limits. (In this definition it is >>therefore not quite the same thing as solar time on the prime >>meridian, >>as it's affected by irregularities in the Earth's orbit. But the >>orbit is >>much more stable and more precisely understood than the Earth's >>rotation, >>so this is not a practical issue. Also liable to be fixed by a >>later >>redefinition.) >> >>The Earth Rotation Angle is defined (by the same resolution) in >>terms of >>the Non-Rotating Origin (NRO) reference frame. (It turns out that >>the >>Non-Rotating Origin does in fact rotate, very slowly. This too is >>likely >>to motivate a future redefinition.) The NRO is defined by a 1978 >>paper >>by Bernard Guinot >>. >>This too makes no mention of range limits. The applicability of >>the >>definitions to distant historical times is (I reckon) implicit; >>it's >>routine for astronomers to deal with large spans of time. >> >>As the definitions aren't explicit, it's useful to look at actual >>astronomical practice. The relevant application that immediately >>comes to mind is the use of ancient historical records of eclipses >>to determine the relationship between UT1 and TT (or other >>similarly >>uniform time scale). (Orbital calculations tell us very precisely >>when >>eclipses occurred in physical time, and a written record saying >>where >>(geographically) an eclipse was observed thus tells us which way >>the >>Earth was oriented at the time.) Steve Allen makes some mention of >>this at >>, with a nice >>graph at >>, looking >>back to -500 CE. He refers to a 2001 paper by Morrison & >>Stephenson >>, which refers >>to >>TT and UT for dates as far back as -1000 CE without any comment >>about >>the proleptic usage. (It does comment on the negative year number >>convention.) >> >>If you want a stronger answer than this, you'd better ask an >>astronomer. >> >> >"the solar day onthe prime meridian" is exactly what I'm trying >> to >> >define. >> >>Yes, "UT1" is the standard name for (mean) solar time on the prime >>meridian. >> >> >Can I forward suitable sections of these emails to a public >> mailing >> >list for transparancy? >> >>Sure. Everything I've said here can be made public. >> >>-zefram >> >>---------- >>From: *Stephen Colebourne* >> >>Date: 4 April 2013 14:34 >>To: Zefram >> >>On 3 April 2013 15:53, Zefram >> wrote: >> >>"the solar day onthe prime meridian" is exactly what I'm trying >> to >> >>define. >> > >> > Yes, "UT1" is the standard name for (mean) solar time on the >> prime >> > meridian. >> >>OK, that should be OK then. So how about (most your text, but with >>a >>few tweaks): >> >>The Java time scale divides each calendar day into exactly 86400 >>subdivision, known as seconds. These seconds may differ from the >>SI >>second. It closely matches the de facto international civil time >>scale, the definition of which changes from time to time. >> >>The Java time scale has slightly different definitions for >>different >>segments of the time-line, each based on the consensus >>international >>time scale that is used as the basis for civil time. Whenever the >>internationally-agreed time scale is modified or replaced, a new >>segment of the Java time scale must be defined for it. Each >>segment >>must meet these requirements: >> >> * the Java time scale shall closely match the underlying >>international civil time scale; >> >> * the Java time scale shall exactly match the international civil >>time scale at noon each day on the prime meridian (Greenwich); >> >> * the Java time scale shall have a precisely-defined relationship >> to >>the international civil time scale. >> >>There are currently, as of 2013, two segments in the Java >>time-scale. >> >>For the segment from 1972-11-03 (UTC) (exact boundary discussed >>below) >>until further notice, the consensus international time scale is UTC >>(with leap seconds). In this period, the Java time scale is >>identical >>to UTC-SLS [hyperlink]. This is identical to UTC on days that do >>not >>have a leap second. On days that do have a leap second, the leap >>second is spread equally over the last 1000 seconds of the day, >>maintaining the appearance of exactly 86400 seconds per day. >> >>Implementations of the JSR-310 API are not required to provide any >>clock that is sub-second accurate, or indeed accurate at all, or >>that >>progresses monotonically or smoothly. Implementations are therefore >>not required to actually perform the UTC-SLS slew or to otherwise >>be >>aware of leap seconds. Only implementations that claim sub-second >>accuracy are obliged to distinguish between the various flavours of >>UT, and how conformant they are with the time-scale. >> >>For the segment prior to 1972-11-03 (UTC), extending back >>arbitrarily >>far, the consensus international time scale is defined to be UT1 >>extrapolated proleptically. This is equivalent to the (mean) solar >>time on the prime meridian (Greenwich). If implementing based on a >>specific set of UT1 data, then the exact boundary is where UT1 = >>UTC, >>which may be up to 18 hours later than 1972-11-03T00:00Z (UTC) >>depending on the UT1 data. >> >>For the segment prior to 1972-11-03 (UTC), extending back >>arbitrarily >>far, the consensus international time scale is defined to be UT1 >>extrapolated proleptically. This is equivalent to the (mean) solar >>time on the prime meridian (Greenwich). If implementing based on a >>specific set of UT1 data, then the exact boundary is where UT1 = >>UTC, >>which may be up to 36 hours earlier or later than 1972-11-03T00:00Z >>(UTC) depending on the UT1 data. >> >>thanks >>Stephen >> >> >> >> >>------------------------------------------------------------------------------ >>Minimize network downtime and maximize team effectiveness. >>Reduce network management and security costs.Learn how to hire >>the most talented Cisco Certified professionals. Visit the >>Employer Resources Portal >>http://www.cisco.com/web/learning/employer_resources/index.html >> >> >>_______________________________________________ >>threeten-develop mailing list >>threeten-develop at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/threeten-develop > From xueming.shen at oracle.com Sat Apr 6 00:11:39 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 06 Apr 2013 00:11:39 -0700 Subject: [threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE In-Reply-To: <515F1A7A.6090404@oracle.com> References: <515DF06A.8020604@oracle.com> <515F1A7A.6090404@oracle.com> Message-ID: <515FCAAB.4050907@oracle.com> Stephen, Webrev has been updated to saturate correctly. Is the calculation correct? http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/src/share/classes/java/nio/file/attribute/FileTime.java.sdiff.html -Sherman > >>> Here is the "draft" of the FileTime change, comment and suggestion >>> appreciated. >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/ >> to(TimeUnit unit) >> unit.convert(instant.getEpochSecond(), TimeUnit.SECONDS) + >> unit.convert(instant.getNano(), TimeUnit.NANOSECONDS); >> will not saturate correctly to MIN/MAX >> >> toMillis() >> instant.toEpochMilli(); will throw ArithmeticException, so you'll have >> to catch and convert to MIN/MAX. >> From scolebourne at joda.org Sat Apr 6 15:30:22 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 6 Apr 2013 23:30:22 +0100 Subject: [threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE In-Reply-To: <515FCAAB.4050907@oracle.com> References: <515DF06A.8020604@oracle.com> <515F1A7A.6090404@oracle.com> <515FCAAB.4050907@oracle.com> Message-ID: All looks fine to me. Stephen On 6 Apr 2013 08:12, "Xueming Shen" wrote: > Stephen, > > Webrev has been updated to saturate correctly. Is the calculation correct? > > http://cr.openjdk.java.net/~**sherman/jdk8_threeten/** > filetime/src/share/classes/**java/nio/file/attribute/** > FileTime.java.sdiff.html > > -Sherman > >> >> Here is the "draft" of the FileTime change, comment and suggestion >>>> appreciated. >>>> >>>> http://cr.openjdk.java.net/~**sherman/jdk8_threeten/**filetime/ >>>> >>> to(TimeUnit unit) >>> unit.convert(instant.**getEpochSecond(), TimeUnit.SECONDS) + >>> unit.convert(instant.getNano()**, TimeUnit.NANOSECONDS); >>> will not saturate correctly to MIN/MAX >>> >>> toMillis() >>> instant.toEpochMilli(); will throw ArithmeticException, so you'll have >>> to catch and convert to MIN/MAX. >>> >>> > From scolebourne at joda.org Sun Apr 7 03:21:19 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 7 Apr 2013 11:21:19 +0100 Subject: [threeten-dev] [threeten-develop] Leap seconds and the Java time-scale In-Reply-To: <515F15FD.5020208@oracle.com> References: <515F15FD.5020208@oracle.com> Message-ID: On 5 April 2013 19:20, roger riggs wrote: > It seems like a reasonable description. > The lack of requirements for to be a clock (monotonic, accurate, etc), > may put off some application developers. Where will they go for assurances > that make their applications run reliably. The accuracy of the clock is something for the implementation to describe. For OpenJDK it should @implNote on the Clock class. Stephen From scolebourne at joda.org Sun Apr 7 03:25:20 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 7 Apr 2013 11:25:20 +0100 Subject: [threeten-dev] [threeten-develop] Leap seconds and the Java time-scale In-Reply-To: <6.2.5.6.2.20130405124316.05bcc328@oracle.com> References: <515F15FD.5020208@oracle.com> <6.2.5.6.2.20130405124316.05bcc328@oracle.com> Message-ID: On 5 April 2013 20:59, Douglas Surber wrote: > Given the lack of requirements for a clock it would be useful to add > some methods that characterize the clock. I guess that the API you suggest is feasible, but I'm not sure when users would use it. My feeling is that users won't be iterating around a list of clocks to find one with particular characteristics, instead there wil simply be a decision during coding time to chose one. Stephen > > Example: > > public enum Monotonicity { UNKNOWN; NONMONOTONIC; > MONOTONIC_DEPENDENT; MONOTONIC_INDEPENDENT; } > public Monotonicity getMonotonicity(); > public Duration getPrecision(); > > MONOTONIC_DEPENDENT means the clock is monotonic so long as some > other time source external to the JVM (the OS) is monotonic. If the > sysadmin changes the system clock, time may go backwards. > MONOTONIC_INDEPENDENT means the clock is monotonic regardless of any > other time source. > > getPrecision returns the least Duration such that the passage of that > amount of physical time will guarantee that now() returns a different > value. The returned value is the ideal assuming > MONOTONIC_INDEPENDENT. If getMonoticity returns some other value then > the returned precision will be incorrect when the clock is not > behaving MONOTONIC_INDEPENDENT, such as when the sysadmin is changing > the system clock. > > Just thinking out loud. > > Douglas From scolebourne at joda.org Sun Apr 7 17:42:45 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 08 Apr 2013 00:42:45 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130408004328.54EA348123@hg.openjdk.java.net> Changeset: 906955cb9d58 Author: scolebourne Date: 2013-04-07 21:28 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/906955cb9d58 Test, fix and spec IsoChronology.resolve ! src/share/classes/java/time/chrono/IsoChronology.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java Changeset: 762db10e42fe Author: scolebourne Date: 2013-04-08 01:38 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/762db10e42fe Test, fix and spec IsoChronology.resolve ! src/share/classes/java/time/chrono/IsoChronology.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java From douglas.surber at oracle.com Mon Apr 8 08:22:27 2013 From: douglas.surber at oracle.com (Douglas Surber) Date: Mon, 08 Apr 2013 08:22:27 -0700 Subject: [threeten-dev] [threeten-develop] Leap seconds and the Java time-scale In-Reply-To: References: <515F15FD.5020208@oracle.com> <6.2.5.6.2.20130405124316.05bcc328@oracle.com> Message-ID: <6.2.5.6.2.20130408081636.067f6d98@oracle.com> At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >On 5 April 2013 20:59, Douglas Surber >wrote: > > Given the lack of requirements for a clock it would be useful to > add > > some methods that characterize the clock. > >I guess that the API you suggest is feasible, but I'm not sure when >users would use it. My feeling is that users won't be iterating >around >a list of clocks to find one with particular characteristics, >instead >there wil simply be a decision during coding time to chose one. Agreed but they might code differently depending on the properties of the clock. For example, it may be possible to use a quick simple algorithm with a monotonic, high precision clock but necessary to use a more complicated, slower algorithm with a possibly non-monotonic or low precision clock. At some level an implementation must specify these properties of each Clock. They can be human readable via JavaDoc or machine readable. Making them machine readable will insure that every implementation specifies them in a well defined way. It incidentally makes the information available to code. This is not a high priority item, but I think it is at least worth considering. Douglas >Stephen > > > > > > Example: > > > > public enum Monotonicity { UNKNOWN; NONMONOTONIC; > > MONOTONIC_DEPENDENT; MONOTONIC_INDEPENDENT; } > > public Monotonicity getMonotonicity(); > > public Duration getPrecision(); > > > > MONOTONIC_DEPENDENT means the clock is monotonic so long as some > > other time source external to the JVM (the OS) is monotonic. If > the > > sysadmin changes the system clock, time may go backwards. > > MONOTONIC_INDEPENDENT means the clock is monotonic regardless of > any > > other time source. > > > > getPrecision returns the least Duration such that the passage of > that > > amount of physical time will guarantee that now() returns a > different > > value. The returned value is the ideal assuming > > MONOTONIC_INDEPENDENT. If getMonoticity returns some other value > then > > the returned precision will be incorrect when the clock is not > > behaving MONOTONIC_INDEPENDENT, such as when the sysadmin is > changing > > the system clock. > > > > Just thinking out loud. > > > > Douglas > >------------------------------------------------------------------------------ >Minimize network downtime and maximize team effectiveness. >Reduce network management and security costs.Learn how to hire >the most talented Cisco Certified professionals. Visit the >Employer Resources Portal >http://www.cisco.com/web/learning/employer_resources/index.html >_______________________________________________ >threeten-develop mailing list >threeten-develop at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/threeten-develop From roger.riggs at oracle.com Mon Apr 8 08:57:34 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 08 Apr 2013 11:57:34 -0400 Subject: [threeten-dev] Leap seconds and the Java time-scale In-Reply-To: <6.2.5.6.2.20130408081636.067f6d98@oracle.com> References: <515F15FD.5020208@oracle.com> <6.2.5.6.2.20130405124316.05bcc328@oracle.com> <6.2.5.6.2.20130408081636.067f6d98@oracle.com> Message-ID: <5162E8EE.5050805@oracle.com> Hi, I expect most developers to make optimistic assumptions and ignore the odd cases. For those that care, they can implement Clocks that behave to meet the more detailed requirements. I would suggest allowing the Clock to throw an exception in the case where it is not monotonic; that's the most likely application assumption that is likely to cause bugs. Either the application can handle it or at least not proceed. Roger On 4/8/2013 11:22 AM, Douglas Surber wrote: > At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >> On 5 April 2013 20:59, Douglas Surber >> wrote: >>> Given the lack of requirements for a clock it would be useful to >> add >>> some methods that characterize the clock. >> I guess that the API you suggest is feasible, but I'm not sure when >> users would use it. My feeling is that users won't be iterating >> around >> a list of clocks to find one with particular characteristics, >> instead >> there wil simply be a decision during coding time to chose one. > Agreed but they might code differently depending on the properties of > the clock. For example, it may be possible to use a quick simple > algorithm with a monotonic, high precision clock but necessary to use > a more complicated, slower algorithm with a possibly non-monotonic or > low precision clock. > > At some level an implementation must specify these properties of each > Clock. They can be human readable via JavaDoc or machine readable. > Making them machine readable will insure that every implementation > specifies them in a well defined way. It incidentally makes the > information available to code. > > This is not a high priority item, but I think it is at least worth > considering. > > Douglas > From roger.riggs at oracle.com Mon Apr 8 12:05:32 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 08 Apr 2013 15:05:32 -0400 Subject: [threeten-dev] Leap seconds and the Java time-scale In-Reply-To: <5162E8EE.5050805@oracle.com> References: <515F15FD.5020208@oracle.com> <6.2.5.6.2.20130405124316.05bcc328@oracle.com> <6.2.5.6.2.20130408081636.067f6d98@oracle.com> <5162E8EE.5050805@oracle.com> Message-ID: <516314FC.7070204@oracle.com> Hi, Practically, I think the default is that Java time uses by the system clock and does not modify its time keeping behavior. The Java APIs are unaware of and do not try to compensate for or correct to improve the accuracy, monotonicity or other aspects of the system clock. It might also be constructive to say that the default Clock uses or stays in sync with System.currentTimeMillis. Following the last leap year incident and NNTP glitches I think we concluded that drift between java.time and System.currentTimeMillis or the system clock would be counter productive in general and cause more problems that it solves. Roger On 4/8/2013 11:57 AM, roger riggs wrote: > Hi, > > I expect most developers to make optimistic assumptions and ignore the > odd cases. > > For those that care, they can implement Clocks that behave to meet the > more detailed requirements. > > I would suggest allowing the Clock to throw an exception in the case > where it is > not monotonic; that's the most likely application assumption that is > likely to > cause bugs. Either the application can handle it or at least not > proceed. > > Roger > > On 4/8/2013 11:22 AM, Douglas Surber wrote: >> At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >>> On 5 April 2013 20:59, Douglas Surber >>> wrote: >>>> Given the lack of requirements for a clock it would be useful to >>> add >>>> some methods that characterize the clock. >>> I guess that the API you suggest is feasible, but I'm not sure when >>> users would use it. My feeling is that users won't be iterating >>> around >>> a list of clocks to find one with particular characteristics, >>> instead >>> there wil simply be a decision during coding time to chose one. >> Agreed but they might code differently depending on the properties of >> the clock. For example, it may be possible to use a quick simple >> algorithm with a monotonic, high precision clock but necessary to use >> a more complicated, slower algorithm with a possibly non-monotonic or >> low precision clock. >> >> At some level an implementation must specify these properties of each >> Clock. They can be human readable via JavaDoc or machine readable. >> Making them machine readable will insure that every implementation >> specifies them in a well defined way. It incidentally makes the >> information available to code. >> >> This is not a high priority item, but I think it is at least worth >> considering. >> >> Douglas >> > From xueming.shen at oracle.com Mon Apr 8 12:51:50 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 08 Apr 2013 12:51:50 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JJSR 310: DateTime API Updates II, Message-ID: <51631FD6.6090800@oracle.com> Hi, JSR 310 has continued to refine and update the java.time API. Please help review the proposed changeset as showed in webrev: http://cr.openjdk.java.net/~sherman/8011172/webrev/ In addition to general javadoc improvements, the changes include: java.time * Duration - added a static from(temporalAmount) method to simplify conversions from other amounts * Renamed the toString(Formatter) method to format(Formatter) in all classes * Period - added a static from(temporalAmount) method to simplify conversions * ZoneId - - Added getAvailableZoneIds method, a simpler mechanism than going to the provider - Added normalized() method to ease conversion to a fixed offset - renamed predefined static fields of timezone names java.time.chrono * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime - changed xxx_COMPARATORs to static methods returning the Time Line Order comparators - Added a from(TemporalAcessor) method to ease conversions * Chronology - Added method to create a Date from EpochDay (And in each calendar subclass) - Added resolveDate to allow resolving date components by the Chronology - Serialization fixes - Replaced raw return types with wildcard type * Era - Removed factory methods and getChronology - they did not work correctly in all cases - Declared Era as a functional interface * Hijrah calendar variations - - Supporting the Umm alQura calendar * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra making the enums public * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method to return the concrete Era type. java.time.format * DateTimeFormatter - - Added fields for the predefined formatters (moved from DateTimeFormatters class) - Updated patterns to be CLDR compatible - Moved documentation for the pattern letters to the class javadoc - Added support for Zone default and conversion * DateTimeFormatterBuilder - Updated documentation of patterns and corresponding equivalents to builder methods. - Added a method to append the localized offset. java.time.temporal * Adjusters - class removed; all static adjusters moved to static methods in TemporalAdjuster * ChronoField - - Renamed EPOCH_MONTH to PROLEPTIC_MONTH - Added getDisplayName - for locale specific field name * Queries - class removed; all static query method moved to static methods in TemporalQuery * TemporalField - added getDisplayName method * UnsupportedTemporalTypeException - new subtype of DateTimeException to reflect no support for a unit or field * WeekFields - Added fields for week and year of week-Based-Years to match CLDR fields "Y", "W" From Alan.Bateman at oracle.com Tue Apr 9 03:49:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Apr 2013 11:49:11 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51631FD6.6090800@oracle.com> References: <51631FD6.6090800@oracle.com> Message-ID: <5163F227.5070109@oracle.com> On 08/04/2013 20:51, Xueming Shen wrote: > Hi, > > JSR 310 has continued to refine and update the java.time API. > Please help review the proposed changeset as showed in webrev: > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ I skimmed through the changes (not a detailed review, there's way too much and I don't have time at the moment). I focused mostly on the zoneId -> TZ mapping and the initialization of the HashMap because that is hurting jdk8 startup since JSR-310 was pushed. The approach looks good to me and it's good to have this regression (probably mostly) resolved. In ZoneInfoFile then I don't see how load(DataInputStream) can throw CNFE (I might have missed something) so maybe that could be removed and the exception handling in the static initializer cleaned up. In passing, I see Duration.between(Temporal,Temporal) using exceptions for control flow but perhaps it's so rare that it's not an issue. A typo in passing in ResolverStyle's javadoc: "will perform the a sensible default". -Alan. From david.holmes at oracle.com Tue Apr 9 05:00:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 22:00:56 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51631FD6.6090800@oracle.com> References: <51631FD6.6090800@oracle.com> Message-ID: <516402F8.5020302@oracle.com> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar file or not; if not then it should not be built using CreateJars.gmk and shouldn't listed on the JAR variables in profile-includes.txt David On 9/04/2013 5:51 AM, Xueming Shen wrote: > Hi, > > JSR 310 has continued to refine and update the java.time API. > Please help review the proposed changeset as showed in webrev: > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > In addition to general javadoc improvements, the changes include: > > java.time > > * Duration - added a static from(temporalAmount) method to simplify > conversions from other amounts > * Renamed the toString(Formatter) method to format(Formatter) in all > classes > * Period - added a static from(temporalAmount) method to simplify > conversions > * ZoneId - > - Added getAvailableZoneIds method, a simpler mechanism than going > to the provider > - Added normalized() method to ease conversion to a fixed offset > - renamed predefined static fields of timezone names > > java.time.chrono > > * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime > - changed xxx_COMPARATORs to static methods returning the Time Line > Order comparators > - Added a from(TemporalAcessor) method to ease conversions > * Chronology > - Added method to create a Date from EpochDay (And in each > calendar subclass) > - Added resolveDate to allow resolving date components by the > Chronology > - Serialization fixes > - Replaced raw return types with wildcard type > * Era > - Removed factory methods and getChronology - they did not work > correctly in all cases > - Declared Era as a functional interface > * Hijrah calendar variations - > - Supporting the Umm alQura calendar > * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra > making the enums public > * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method > to return the concrete Era type. > > java.time.format > > * DateTimeFormatter - > - Added fields for the predefined formatters > (moved from DateTimeFormatters class) > - Updated patterns to be CLDR compatible > - Moved documentation for the pattern letters to the class javadoc > - Added support for Zone default and conversion > * DateTimeFormatterBuilder > - Updated documentation of patterns and corresponding equivalents > to builder methods. > - Added a method to append the localized offset. > > java.time.temporal > > * Adjusters - class removed; all static adjusters moved to static methods > in TemporalAdjuster > * ChronoField - > - Renamed EPOCH_MONTH to PROLEPTIC_MONTH > - Added getDisplayName - for locale specific field name > * Queries - class removed; all static query method moved to static methods > in TemporalQuery > * TemporalField - added getDisplayName method > * UnsupportedTemporalTypeException - new subtype of DateTimeException > to reflect no support for a unit or field > * WeekFields - Added fields for week and year of week-Based-Years to match > CLDR fields "Y", "W" From xueming.shen at oracle.com Tue Apr 9 08:08:35 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Apr 2013 08:08:35 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <516402F8.5020302@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> Message-ID: <51642EF3.1040701@oracle.com> On 4/9/13 5:00 AM, David Holmes wrote: > I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar > file or not; if not then it should not be built using CreateJars.gmk > and shouldn't listed on the JAR variables in profile-includes.txt tzdb.dat now is NOT a jar file for performance (decompression slows down startup). So which gmk file is the best fit for this kind of "file building"? We may be able to update it to the appropriate place with a follow up push. -Sherman > > David > > On 9/04/2013 5:51 AM, Xueming Shen wrote: >> Hi, >> >> JSR 310 has continued to refine and update the java.time API. >> Please help review the proposed changeset as showed in webrev: >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> In addition to general javadoc improvements, the changes include: >> >> java.time >> >> * Duration - added a static from(temporalAmount) method to simplify >> conversions from other amounts >> * Renamed the toString(Formatter) method to format(Formatter) in all >> classes >> * Period - added a static from(temporalAmount) method to simplify >> conversions >> * ZoneId - >> - Added getAvailableZoneIds method, a simpler mechanism than going >> to the provider >> - Added normalized() method to ease conversion to a fixed offset >> - renamed predefined static fields of timezone names >> >> java.time.chrono >> >> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >> - changed xxx_COMPARATORs to static methods returning the Time Line >> Order comparators >> - Added a from(TemporalAcessor) method to ease conversions >> * Chronology >> - Added method to create a Date from EpochDay (And in each >> calendar subclass) >> - Added resolveDate to allow resolving date components by the >> Chronology >> - Serialization fixes >> - Replaced raw return types with wildcard type >> * Era >> - Removed factory methods and getChronology - they did not work >> correctly in all cases >> - Declared Era as a functional interface >> * Hijrah calendar variations - >> - Supporting the Umm alQura calendar >> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >> making the enums public >> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >> to return the concrete Era type. >> >> java.time.format >> >> * DateTimeFormatter - >> - Added fields for the predefined formatters >> (moved from DateTimeFormatters class) >> - Updated patterns to be CLDR compatible >> - Moved documentation for the pattern letters to the class javadoc >> - Added support for Zone default and conversion >> * DateTimeFormatterBuilder >> - Updated documentation of patterns and corresponding equivalents >> to builder methods. >> - Added a method to append the localized offset. >> >> java.time.temporal >> >> * Adjusters - class removed; all static adjusters moved to static >> methods >> in TemporalAdjuster >> * ChronoField - >> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >> - Added getDisplayName - for locale specific field name >> * Queries - class removed; all static query method moved to static >> methods >> in TemporalQuery >> * TemporalField - added getDisplayName method >> * UnsupportedTemporalTypeException - new subtype of DateTimeException >> to reflect no support for a unit or field >> * WeekFields - Added fields for week and year of week-Based-Years to >> match >> CLDR fields "Y", "W" From xueming.shen at oracle.com Tue Apr 9 13:22:36 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 09 Apr 2013 20:22:36 +0000 Subject: [threeten-dev] hg: threeten/threeten/nashorn: 151 new changesets Message-ID: <20130409202404.51EAE48188@hg.openjdk.java.net> Changeset: b8a1b238c77c Author: duke Date: 2007-12-01 00:00 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b8a1b238c77c Initial load + .hgignore + .jcheck/conf Changeset: 6031a0bc0ae2 Author: jcoomes Date: 2012-12-20 14:16 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/6031a0bc0ae2 8005364: initial hg tags for nashorn repo Reviewed-by: amurillo + .hgtags Changeset: da1e581c933b Author: jlaskey Date: 2012-12-21 16:36 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/da1e581c933b 8005403: Open-source Nashorn Reviewed-by: attila, hannesw, lagergren, sundar Contributed-by: james.laskey at oracle.com, akhil.arora at oracle.com, andreas.woess at jku.at, attila.szegedi at oracle.com, hannes.wallnoefer at oracle.com, henry.jen at oracle.com, marcus.lagergren at oracle.com, pavel.semenov at oracle.com, pavel.stepanov at oracle.com, petr.hejl at oracle.com, petr.pisl at oracle.com, sundararajan.athijegannathan at oracle.com ! .hgignore + ASSEMBLY_EXCEPTION + LICENSE + README + RELEASE_README + THIRD_PARTY_README + bin/checkintest.sh + bin/fixorphantests.sh + bin/fixwhitespace.sh + bin/jjs + bin/jjs.bat + bin/jjssecure + bin/jjssecure.bat + bin/nashorn + bin/nashorn.bat + bin/rm-non-tracked.sh + bin/verbose_octane.bat + bin/verbose_octane.sh + buildtools/nasgen/README + buildtools/nasgen/build.xml + buildtools/nasgen/nasgen.iml + buildtools/nasgen/project.properties + buildtools/nasgen/src/META-INF/MANIFEST.MF + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + docs/DEVELOPER_README + docs/genshelldoc.js + make/Makefile + make/build-benchmark.xml + make/build-nasgen.xml + make/build.xml + make/nbproject/ide-file-targets.xml + make/nbproject/ide-targets.xml + make/nbproject/jdk.xml + make/nbproject/nbjdk.properties + make/nbproject/nbjdk.xml + make/nbproject/project.xml + make/project.properties + samples/counters.js + samples/letter.js + samples/parser.js + samples/shell.js + samples/test.js + samples/uniq.js + src/META-INF/MANIFEST.MF + src/META-INF/services/javax.script.ScriptEngineFactory + src/jdk/nashorn/api/scripting/NashornException.java + src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/package-info.java + src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/BranchOptimizer.java + src/jdk/nashorn/internal/codegen/ClassEmitter.java + src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompileUnit.java + src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/Emitter.java + src/jdk/nashorn/internal/codegen/Frame.java + src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Lower.java + src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/Namespace.java + src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/codegen/SharedScopeCall.java + src/jdk/nashorn/internal/codegen/Splitter.java + src/jdk/nashorn/internal/codegen/Transform.java + src/jdk/nashorn/internal/codegen/WeighNodes.java + src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/MapCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java + src/jdk/nashorn/internal/codegen/types/ArrayType.java + src/jdk/nashorn/internal/codegen/types/BitwiseType.java + src/jdk/nashorn/internal/codegen/types/BooleanType.java + src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeOps.java + src/jdk/nashorn/internal/codegen/types/IntType.java + src/jdk/nashorn/internal/codegen/types/LongType.java + src/jdk/nashorn/internal/codegen/types/NumberType.java + src/jdk/nashorn/internal/codegen/types/NumericType.java + src/jdk/nashorn/internal/codegen/types/ObjectType.java + src/jdk/nashorn/internal/codegen/types/Type.java + src/jdk/nashorn/internal/ir/AccessNode.java + src/jdk/nashorn/internal/ir/Assignment.java + src/jdk/nashorn/internal/ir/BaseNode.java + src/jdk/nashorn/internal/ir/BinaryNode.java + src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BreakNode.java + src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/CallNode.java + src/jdk/nashorn/internal/ir/CaseNode.java + src/jdk/nashorn/internal/ir/CatchNode.java + src/jdk/nashorn/internal/ir/ContinueNode.java + src/jdk/nashorn/internal/ir/DoWhileNode.java + src/jdk/nashorn/internal/ir/EmptyNode.java + src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/ForNode.java + src/jdk/nashorn/internal/ir/FunctionCall.java + src/jdk/nashorn/internal/ir/FunctionNode.java + src/jdk/nashorn/internal/ir/IdentNode.java + src/jdk/nashorn/internal/ir/IfNode.java + src/jdk/nashorn/internal/ir/IndexNode.java + src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LabeledNode.java + src/jdk/nashorn/internal/ir/LineNumberNode.java + src/jdk/nashorn/internal/ir/LiteralNode.java + src/jdk/nashorn/internal/ir/Location.java + src/jdk/nashorn/internal/ir/Node.java + src/jdk/nashorn/internal/ir/ObjectNode.java + src/jdk/nashorn/internal/ir/PropertyKey.java + src/jdk/nashorn/internal/ir/PropertyNode.java + src/jdk/nashorn/internal/ir/ReferenceNode.java + src/jdk/nashorn/internal/ir/ReturnNode.java + src/jdk/nashorn/internal/ir/RuntimeNode.java + src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/SwitchNode.java + src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TernaryNode.java + src/jdk/nashorn/internal/ir/ThrowNode.java + src/jdk/nashorn/internal/ir/TryNode.java + src/jdk/nashorn/internal/ir/TypeOverride.java + src/jdk/nashorn/internal/ir/UnaryNode.java + src/jdk/nashorn/internal/ir/VarNode.java + src/jdk/nashorn/internal/ir/WhileNode.java + src/jdk/nashorn/internal/ir/WithNode.java + src/jdk/nashorn/internal/ir/annotations/ChildNode.java + src/jdk/nashorn/internal/ir/annotations/Ignore.java + src/jdk/nashorn/internal/ir/annotations/ParentNode.java + src/jdk/nashorn/internal/ir/annotations/Reference.java + src/jdk/nashorn/internal/ir/debug/ASTWriter.java + src/jdk/nashorn/internal/ir/debug/JSONWriter.java + src/jdk/nashorn/internal/ir/debug/PrintVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java + src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java + src/jdk/nashorn/internal/objects/ArrayBufferView.java + src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java + src/jdk/nashorn/internal/objects/DateParser.java + src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java + src/jdk/nashorn/internal/objects/Global.java + src/jdk/nashorn/internal/objects/NativeArguments.java + src/jdk/nashorn/internal/objects/NativeArray.java + src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeBoolean.java + src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/objects/NativeDebug.java + src/jdk/nashorn/internal/objects/NativeError.java + src/jdk/nashorn/internal/objects/NativeEvalError.java + src/jdk/nashorn/internal/objects/NativeFloat32Array.java + src/jdk/nashorn/internal/objects/NativeFloat64Array.java + src/jdk/nashorn/internal/objects/NativeFunction.java + src/jdk/nashorn/internal/objects/NativeInt16Array.java + src/jdk/nashorn/internal/objects/NativeInt32Array.java + src/jdk/nashorn/internal/objects/NativeInt8Array.java + src/jdk/nashorn/internal/objects/NativeJSAdapter.java + src/jdk/nashorn/internal/objects/NativeJSON.java + src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/objects/NativeJavaImporter.java + src/jdk/nashorn/internal/objects/NativeMath.java + src/jdk/nashorn/internal/objects/NativeNumber.java + src/jdk/nashorn/internal/objects/NativeObject.java + src/jdk/nashorn/internal/objects/NativeRangeError.java + src/jdk/nashorn/internal/objects/NativeReferenceError.java + src/jdk/nashorn/internal/objects/NativeRegExp.java + src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + src/jdk/nashorn/internal/objects/NativeStrictArguments.java + src/jdk/nashorn/internal/objects/NativeString.java + src/jdk/nashorn/internal/objects/NativeSyntaxError.java + src/jdk/nashorn/internal/objects/NativeTypeError.java + src/jdk/nashorn/internal/objects/NativeURIError.java + src/jdk/nashorn/internal/objects/NativeUint16Array.java + src/jdk/nashorn/internal/objects/NativeUint32Array.java + src/jdk/nashorn/internal/objects/NativeUint8Array.java + src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + src/jdk/nashorn/internal/objects/PrototypeObject.java + src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Attribute.java + src/jdk/nashorn/internal/objects/annotations/Constructor.java + src/jdk/nashorn/internal/objects/annotations/Function.java + src/jdk/nashorn/internal/objects/annotations/Getter.java + src/jdk/nashorn/internal/objects/annotations/Property.java + src/jdk/nashorn/internal/objects/annotations/ScriptClass.java + src/jdk/nashorn/internal/objects/annotations/Setter.java + src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java + src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java + src/jdk/nashorn/internal/objects/annotations/Where.java + src/jdk/nashorn/internal/objects/package-info.java + src/jdk/nashorn/internal/parser/AbstractParser.java + src/jdk/nashorn/internal/parser/JSONParser.java + src/jdk/nashorn/internal/parser/Lexer.java + src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/parser/RegExp.java + src/jdk/nashorn/internal/parser/RegExpScanner.java + src/jdk/nashorn/internal/parser/Scanner.java + src/jdk/nashorn/internal/parser/Token.java + src/jdk/nashorn/internal/parser/TokenKind.java + src/jdk/nashorn/internal/parser/TokenLookup.java + src/jdk/nashorn/internal/parser/TokenStream.java + src/jdk/nashorn/internal/parser/TokenType.java + src/jdk/nashorn/internal/runtime/AccessorProperty.java + src/jdk/nashorn/internal/runtime/BitVector.java + src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/ConsString.java + src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/Debug.java + src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java + src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/ErrorManager.java + src/jdk/nashorn/internal/runtime/FindProperty.java + src/jdk/nashorn/internal/runtime/FunctionScope.java + src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/GlobalObject.java + src/jdk/nashorn/internal/runtime/JSErrorType.java + src/jdk/nashorn/internal/runtime/JSType.java + src/jdk/nashorn/internal/runtime/Logging.java + src/jdk/nashorn/internal/runtime/NashornLoader.java + src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/NumberToString.java + src/jdk/nashorn/internal/runtime/ParserException.java + src/jdk/nashorn/internal/runtime/Property.java + src/jdk/nashorn/internal/runtime/PropertyAccess.java + src/jdk/nashorn/internal/runtime/PropertyDescriptor.java + src/jdk/nashorn/internal/runtime/PropertyHashMap.java + src/jdk/nashorn/internal/runtime/PropertyListener.java + src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyMap.java + src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java + src/jdk/nashorn/internal/runtime/RegExpMatch.java + src/jdk/nashorn/internal/runtime/Scope.java + src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptLoader.java + src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Source.java + src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StructureLoader.java + src/jdk/nashorn/internal/runtime/URIUtils.java + src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + src/jdk/nashorn/internal/runtime/Version.java + src/jdk/nashorn/internal/runtime/WithObject.java + src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java + src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java + src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java + src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java + src/jdk/nashorn/internal/runtime/linker/Lookup.java + src/jdk/nashorn/internal/runtime/linker/Mangler.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java + src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java + src/jdk/nashorn/internal/runtime/linker/NashornGuards.java + src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/Option.java + src/jdk/nashorn/internal/runtime/options/OptionTemplate.java + src/jdk/nashorn/internal/runtime/options/Options.java + src/jdk/nashorn/internal/runtime/options/ValueOption.java + src/jdk/nashorn/internal/runtime/resources/Messages.properties + src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + src/jdk/nashorn/internal/runtime/resources/parser.js + src/jdk/nashorn/internal/runtime/resources/version.properties-template + src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/tools/Shell.java + src/jdk/nashorn/tools/resources/Shell.properties + src/jdk/nashorn/tools/resources/shell.js + src/netscape/javascript/JSObject.java + src/overview.html + test/README + test/examples/dual-fields-micro.js + test/examples/innerbench.js + test/examples/typechain.js + test/lib/benchmark.js + test/opt/add.js + test/opt/add_constant.js + test/opt/add_reuse_callsite.js + test/opt/add_revert2.js + test/opt/cascade_specialize.js + test/script/assert.js + test/script/basic/NASHORN-100.js + test/script/basic/NASHORN-100.js.EXPECTED + test/script/basic/NASHORN-101.js + test/script/basic/NASHORN-101.js.EXPECTED + test/script/basic/NASHORN-102.js + test/script/basic/NASHORN-102.js.EXPECTED + test/script/basic/NASHORN-103.js + test/script/basic/NASHORN-104.js + test/script/basic/NASHORN-104.js.EXPECTED + test/script/basic/NASHORN-105.js + test/script/basic/NASHORN-105.js.EXPECTED + test/script/basic/NASHORN-106.js + test/script/basic/NASHORN-106.js.EXPECTED + test/script/basic/NASHORN-107.js + test/script/basic/NASHORN-108.js + test/script/basic/NASHORN-108.js.EXPECTED + test/script/basic/NASHORN-109.js + test/script/basic/NASHORN-109.js.EXPECTED + test/script/basic/NASHORN-11.js + test/script/basic/NASHORN-11.js.EXPECTED + test/script/basic/NASHORN-111.js + test/script/basic/NASHORN-111.js.EXPECTED + test/script/basic/NASHORN-113.js + test/script/basic/NASHORN-113.js.EXPECTED + test/script/basic/NASHORN-114.js + test/script/basic/NASHORN-115.js + test/script/basic/NASHORN-115.js.EXPECTED + test/script/basic/NASHORN-117.js + test/script/basic/NASHORN-118.js + test/script/basic/NASHORN-118.js.EXPECTED + test/script/basic/NASHORN-119.js + test/script/basic/NASHORN-119.js.EXPECTED + test/script/basic/NASHORN-12.js + test/script/basic/NASHORN-120.js + test/script/basic/NASHORN-122.js + test/script/basic/NASHORN-122.js.EXPECTED + test/script/basic/NASHORN-126.js + test/script/basic/NASHORN-126.js.EXPECTED + test/script/basic/NASHORN-127.js + test/script/basic/NASHORN-127.js.EXPECTED + test/script/basic/NASHORN-130.js + test/script/basic/NASHORN-132.js + test/script/basic/NASHORN-132.js.EXPECTED + test/script/basic/NASHORN-133.js + test/script/basic/NASHORN-133.js.EXPECTED + test/script/basic/NASHORN-135.js + test/script/basic/NASHORN-136.js + test/script/basic/NASHORN-136.js.EXPECTED + test/script/basic/NASHORN-14.js + test/script/basic/NASHORN-14.js.EXPECTED + test/script/basic/NASHORN-148.js + test/script/basic/NASHORN-148.js.EXPECTED + test/script/basic/NASHORN-15.js + test/script/basic/NASHORN-15.js.EXPECTED + test/script/basic/NASHORN-153.js + test/script/basic/NASHORN-156.js + test/script/basic/NASHORN-157.js + test/script/basic/NASHORN-163.js + test/script/basic/NASHORN-163.js.EXPECTED + test/script/basic/NASHORN-164.js + test/script/basic/NASHORN-165.js + test/script/basic/NASHORN-166.js + test/script/basic/NASHORN-168.js + test/script/basic/NASHORN-168.js.EXPECTED + test/script/basic/NASHORN-169.js + test/script/basic/NASHORN-172.js + test/script/basic/NASHORN-173.js + test/script/basic/NASHORN-173.js.EXPECTED + test/script/basic/NASHORN-174.js + test/script/basic/NASHORN-175.js + test/script/basic/NASHORN-176.js + test/script/basic/NASHORN-177.js + test/script/basic/NASHORN-177.js.EXPECTED + test/script/basic/NASHORN-178.js + test/script/basic/NASHORN-178.js.EXPECTED + test/script/basic/NASHORN-179.js + test/script/basic/NASHORN-18.js + test/script/basic/NASHORN-18.js.EXPECTED + test/script/basic/NASHORN-181.js + test/script/basic/NASHORN-182.js + test/script/basic/NASHORN-183.js + test/script/basic/NASHORN-184.js + test/script/basic/NASHORN-184.js.EXPECTED + test/script/basic/NASHORN-185.js + test/script/basic/NASHORN-185.js.EXPECTED + test/script/basic/NASHORN-187.js + test/script/basic/NASHORN-188.js + test/script/basic/NASHORN-188.js.EXPECTED + test/script/basic/NASHORN-19.js + test/script/basic/NASHORN-19.js.EXPECTED + test/script/basic/NASHORN-190.js + test/script/basic/NASHORN-192.js + test/script/basic/NASHORN-194.js + test/script/basic/NASHORN-196.js + test/script/basic/NASHORN-198.js + test/script/basic/NASHORN-20.js + test/script/basic/NASHORN-20.js.EXPECTED + test/script/basic/NASHORN-201.js + test/script/basic/NASHORN-202.js + test/script/basic/NASHORN-203.js + test/script/basic/NASHORN-204.js + test/script/basic/NASHORN-205.js + test/script/basic/NASHORN-206.js + test/script/basic/NASHORN-207.js + test/script/basic/NASHORN-207_2.js + test/script/basic/NASHORN-208.js + test/script/basic/NASHORN-208.js.EXPECTED + test/script/basic/NASHORN-209.js + test/script/basic/NASHORN-209.js.EXPECTED + test/script/basic/NASHORN-21.js + test/script/basic/NASHORN-21.js.EXPECTED + test/script/basic/NASHORN-211.js + test/script/basic/NASHORN-212.js + test/script/basic/NASHORN-213.js + test/script/basic/NASHORN-215.js + test/script/basic/NASHORN-215.js.EXPECTED + test/script/basic/NASHORN-216.js + test/script/basic/NASHORN-217.js + test/script/basic/NASHORN-217.js.EXPECTED + test/script/basic/NASHORN-219.js + test/script/basic/NASHORN-219.js.EXPECTED + test/script/basic/NASHORN-22.js + test/script/basic/NASHORN-22.js.EXPECTED + test/script/basic/NASHORN-221.js + test/script/basic/NASHORN-222.js + test/script/basic/NASHORN-223.js + test/script/basic/NASHORN-225.js + test/script/basic/NASHORN-226.js + test/script/basic/NASHORN-227.js + test/script/basic/NASHORN-228.js + test/script/basic/NASHORN-229.js + test/script/basic/NASHORN-229_subtest.js + test/script/basic/NASHORN-23.js + test/script/basic/NASHORN-23.js.EXPECTED + test/script/basic/NASHORN-232.js + test/script/basic/NASHORN-234.js + test/script/basic/NASHORN-235.js + test/script/basic/NASHORN-236.js + test/script/basic/NASHORN-237.js + test/script/basic/NASHORN-239.js + test/script/basic/NASHORN-24.js + test/script/basic/NASHORN-24.js.EXPECTED + test/script/basic/NASHORN-241.js + test/script/basic/NASHORN-242.js + test/script/basic/NASHORN-245.js + test/script/basic/NASHORN-247.js + test/script/basic/NASHORN-25.js + test/script/basic/NASHORN-25.js.EXPECTED + test/script/basic/NASHORN-251.js + test/script/basic/NASHORN-252.js + test/script/basic/NASHORN-253.js + test/script/basic/NASHORN-256.js + test/script/basic/NASHORN-258.js + test/script/basic/NASHORN-258.js.EXPECTED + test/script/basic/NASHORN-26.js + test/script/basic/NASHORN-26.js.EXPECTED + test/script/basic/NASHORN-260.js + test/script/basic/NASHORN-261.js + test/script/basic/NASHORN-262.js + test/script/basic/NASHORN-263.js + test/script/basic/NASHORN-264.js + test/script/basic/NASHORN-265.js + test/script/basic/NASHORN-265.js.EXPECTED + test/script/basic/NASHORN-266.js + test/script/basic/NASHORN-269.js + test/script/basic/NASHORN-27.js + test/script/basic/NASHORN-27.js.EXPECTED + test/script/basic/NASHORN-270.js + test/script/basic/NASHORN-271.js + test/script/basic/NASHORN-275.js + test/script/basic/NASHORN-276.js + test/script/basic/NASHORN-277.js + test/script/basic/NASHORN-278.js + test/script/basic/NASHORN-28.js + test/script/basic/NASHORN-28.js.EXPECTED + test/script/basic/NASHORN-281.js + test/script/basic/NASHORN-284.js + test/script/basic/NASHORN-284.js.EXPECTED + test/script/basic/NASHORN-285.js + test/script/basic/NASHORN-285.js.EXPECTED + test/script/basic/NASHORN-288.js + test/script/basic/NASHORN-29.js + test/script/basic/NASHORN-29.js.EXPECTED + test/script/basic/NASHORN-293.js + test/script/basic/NASHORN-293.js.EXPECTED + test/script/basic/NASHORN-294.js + test/script/basic/NASHORN-296.js + test/script/basic/NASHORN-297.js + test/script/basic/NASHORN-30.js + test/script/basic/NASHORN-30.js.EXPECTED + test/script/basic/NASHORN-300.js + test/script/basic/NASHORN-301.js + test/script/basic/NASHORN-301.js.EXPECTED + test/script/basic/NASHORN-304.js + test/script/basic/NASHORN-310.js + test/script/basic/NASHORN-310.js.EXPECTED + test/script/basic/NASHORN-318.js + test/script/basic/NASHORN-318.js.EXPECTED + test/script/basic/NASHORN-32.js + test/script/basic/NASHORN-32.js.EXPECTED + test/script/basic/NASHORN-321.js + test/script/basic/NASHORN-321.js.EXPECTED + test/script/basic/NASHORN-323.js + test/script/basic/NASHORN-323.js.EXPECTED + test/script/basic/NASHORN-324.js + test/script/basic/NASHORN-33.js + test/script/basic/NASHORN-33.js.EXPECTED + test/script/basic/NASHORN-331.js + test/script/basic/NASHORN-331.js.EXPECTED + test/script/basic/NASHORN-337.js + test/script/basic/NASHORN-337.js.EXPECTED + test/script/basic/NASHORN-34.js + test/script/basic/NASHORN-34.js.EXPECTED + test/script/basic/NASHORN-340.js + test/script/basic/NASHORN-340.js.EXPECTED + test/script/basic/NASHORN-349.js + test/script/basic/NASHORN-354.js + test/script/basic/NASHORN-354.js.EXPECTED + test/script/basic/NASHORN-355.js + test/script/basic/NASHORN-355.js.EXPECTED + test/script/basic/NASHORN-36.js + test/script/basic/NASHORN-36.js.EXPECTED + test/script/basic/NASHORN-365.js + test/script/basic/NASHORN-366.js + test/script/basic/NASHORN-366.js.EXPECTED + test/script/basic/NASHORN-368.js + test/script/basic/NASHORN-368.js.EXPECTED + test/script/basic/NASHORN-37.js + test/script/basic/NASHORN-37.js.EXPECTED + test/script/basic/NASHORN-375.js + test/script/basic/NASHORN-376.js + test/script/basic/NASHORN-377.js + test/script/basic/NASHORN-377.js.EXPECTED + test/script/basic/NASHORN-378.js + test/script/basic/NASHORN-38.js + test/script/basic/NASHORN-38.js.EXPECTED + test/script/basic/NASHORN-380.js + test/script/basic/NASHORN-380.js.EXPECTED + test/script/basic/NASHORN-381.js + test/script/basic/NASHORN-382.js + test/script/basic/NASHORN-383.js + test/script/basic/NASHORN-384.js + test/script/basic/NASHORN-384.js.EXPECTED + test/script/basic/NASHORN-385.js + test/script/basic/NASHORN-385.js.EXPECTED + test/script/basic/NASHORN-389.js + test/script/basic/NASHORN-389.js.EXPECTED + test/script/basic/NASHORN-393.js + test/script/basic/NASHORN-393.js.EXPECTED + test/script/basic/NASHORN-394.js + test/script/basic/NASHORN-394.js.EXPECTED + test/script/basic/NASHORN-396.js + test/script/basic/NASHORN-397.js + test/script/basic/NASHORN-398.js + test/script/basic/NASHORN-40.js + test/script/basic/NASHORN-40.js.EXPECTED + test/script/basic/NASHORN-400.js + test/script/basic/NASHORN-400.js.EXPECTED + test/script/basic/NASHORN-401.js + test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/NASHORN-402.js + test/script/basic/NASHORN-402.js.EXPECTED + test/script/basic/NASHORN-404.js + test/script/basic/NASHORN-405.js + test/script/basic/NASHORN-405.js.EXPECTED + test/script/basic/NASHORN-406.js + test/script/basic/NASHORN-408.js + test/script/basic/NASHORN-408.js.EXPECTED + test/script/basic/NASHORN-415.js + test/script/basic/NASHORN-415.js.EXPECTED + test/script/basic/NASHORN-416.js + test/script/basic/NASHORN-417.js + test/script/basic/NASHORN-418.js + test/script/basic/NASHORN-420.js + test/script/basic/NASHORN-421.js + test/script/basic/NASHORN-423.js + test/script/basic/NASHORN-423.js.EXPECTED + test/script/basic/NASHORN-423a.js + test/script/basic/NASHORN-424.js + test/script/basic/NASHORN-424.js.EXPECTED + test/script/basic/NASHORN-425.js + test/script/basic/NASHORN-425.js.EXPECTED + test/script/basic/NASHORN-426.js + test/script/basic/NASHORN-427.js + test/script/basic/NASHORN-428.js + test/script/basic/NASHORN-429.js + test/script/basic/NASHORN-432.js + test/script/basic/NASHORN-433.js + test/script/basic/NASHORN-434.js + test/script/basic/NASHORN-435.js + test/script/basic/NASHORN-437.js + test/script/basic/NASHORN-44.js + test/script/basic/NASHORN-44.js.EXPECTED + test/script/basic/NASHORN-441.js + test/script/basic/NASHORN-441.js.EXPECTED + test/script/basic/NASHORN-442.js + test/script/basic/NASHORN-443.js + test/script/basic/NASHORN-444.js + test/script/basic/NASHORN-444.js.EXPECTED + test/script/basic/NASHORN-445.js + test/script/basic/NASHORN-446.js + test/script/basic/NASHORN-447.js + test/script/basic/NASHORN-448.js + test/script/basic/NASHORN-449.js + test/script/basic/NASHORN-449.js.EXPECTED + test/script/basic/NASHORN-45.js + test/script/basic/NASHORN-45.js.EXPECTED + test/script/basic/NASHORN-450.js + test/script/basic/NASHORN-452.js + test/script/basic/NASHORN-459.js + test/script/basic/NASHORN-46.js + test/script/basic/NASHORN-46.js.EXPECTED + test/script/basic/NASHORN-462.js + test/script/basic/NASHORN-463.js + test/script/basic/NASHORN-468.js + test/script/basic/NASHORN-47.js + test/script/basic/NASHORN-473.js + test/script/basic/NASHORN-473.js.EXPECTED + test/script/basic/NASHORN-474.js + test/script/basic/NASHORN-474.js.EXPECTED + test/script/basic/NASHORN-478.js + test/script/basic/NASHORN-48.js + test/script/basic/NASHORN-48.js.EXPECTED + test/script/basic/NASHORN-481.js + test/script/basic/NASHORN-481.js.EXPECTED + test/script/basic/NASHORN-482.js + test/script/basic/NASHORN-484.js + test/script/basic/NASHORN-484.js.EXPECTED + test/script/basic/NASHORN-486.js + test/script/basic/NASHORN-487.js + test/script/basic/NASHORN-488.js + test/script/basic/NASHORN-49.js + test/script/basic/NASHORN-49.js.EXPECTED + test/script/basic/NASHORN-490.js + test/script/basic/NASHORN-494.js + test/script/basic/NASHORN-497.js + test/script/basic/NASHORN-498.js + test/script/basic/NASHORN-499.js + test/script/basic/NASHORN-50.js + test/script/basic/NASHORN-50.js.EXPECTED + test/script/basic/NASHORN-500.js + test/script/basic/NASHORN-503.js + test/script/basic/NASHORN-503.js.EXPECTED + test/script/basic/NASHORN-51.js + test/script/basic/NASHORN-51.js.EXPECTED + test/script/basic/NASHORN-511.js + test/script/basic/NASHORN-515.js + test/script/basic/NASHORN-515.js.EXPECTED + test/script/basic/NASHORN-516.js + test/script/basic/NASHORN-52.js + test/script/basic/NASHORN-534.js + test/script/basic/NASHORN-534.js.EXPECTED + test/script/basic/NASHORN-535.js + test/script/basic/NASHORN-535.js.EXPECTED + test/script/basic/NASHORN-544.js + test/script/basic/NASHORN-55.js + test/script/basic/NASHORN-554.js + test/script/basic/NASHORN-554.js.EXPECTED + test/script/basic/NASHORN-556.js + test/script/basic/NASHORN-556.js.EXPECTED + test/script/basic/NASHORN-56.js + test/script/basic/NASHORN-56.js.EXPECTED + test/script/basic/NASHORN-562.js + test/script/basic/NASHORN-565.js + test/script/basic/NASHORN-565.js.EXPECTED + test/script/basic/NASHORN-575.js + test/script/basic/NASHORN-575.js.EXPECTED + test/script/basic/NASHORN-58.js + test/script/basic/NASHORN-58.js.EXPECTED + test/script/basic/NASHORN-59.js + test/script/basic/NASHORN-59.js.EXPECTED + test/script/basic/NASHORN-592.js + test/script/basic/NASHORN-592.js.EXPECTED + test/script/basic/NASHORN-597.js + test/script/basic/NASHORN-597.js.EXPECTED + test/script/basic/NASHORN-60.js + test/script/basic/NASHORN-60.js.EXPECTED + test/script/basic/NASHORN-609.js + test/script/basic/NASHORN-609.js.EXPECTED + test/script/basic/NASHORN-61.js + test/script/basic/NASHORN-61.js.EXPECTED + test/script/basic/NASHORN-62.js + test/script/basic/NASHORN-62.js.EXPECTED + test/script/basic/NASHORN-620.js + test/script/basic/NASHORN-620.js.EXPECTED + test/script/basic/NASHORN-623.js + test/script/basic/NASHORN-623.js.EXPECTED + test/script/basic/NASHORN-627.js + test/script/basic/NASHORN-627.js.EXPECTED + test/script/basic/NASHORN-63.js + test/script/basic/NASHORN-631.js.EXPECTED + test/script/basic/NASHORN-637.js + test/script/basic/NASHORN-637.js.EXPECTED + test/script/basic/NASHORN-638.js + test/script/basic/NASHORN-638.js.EXPECTED + test/script/basic/NASHORN-639.js + test/script/basic/NASHORN-64.js + test/script/basic/NASHORN-642.js + test/script/basic/NASHORN-642.js.EXPECTED + test/script/basic/NASHORN-646.js + test/script/basic/NASHORN-653.js + test/script/basic/NASHORN-658.js + test/script/basic/NASHORN-659.js + test/script/basic/NASHORN-66.js + test/script/basic/NASHORN-66.js.EXPECTED + test/script/basic/NASHORN-664.js + test/script/basic/NASHORN-665.js + test/script/basic/NASHORN-67.js + test/script/basic/NASHORN-67.js.EXPECTED + test/script/basic/NASHORN-678.js + test/script/basic/NASHORN-68.js + test/script/basic/NASHORN-68.js.EXPECTED + test/script/basic/NASHORN-689.js + test/script/basic/NASHORN-689.js.EXPECTED + test/script/basic/NASHORN-69.js + test/script/basic/NASHORN-69.js.EXPECTED + test/script/basic/NASHORN-691.js + test/script/basic/NASHORN-691.js.EXPECTED + test/script/basic/NASHORN-694.js + test/script/basic/NASHORN-694.js.EXPECTED + test/script/basic/NASHORN-697.js + test/script/basic/NASHORN-703.js + test/script/basic/NASHORN-703.js.EXPECTED + test/script/basic/NASHORN-703a.js + test/script/basic/NASHORN-703a.js.EXPECTED + test/script/basic/NASHORN-705.js + test/script/basic/NASHORN-71.js + test/script/basic/NASHORN-71.js.EXPECTED + test/script/basic/NASHORN-710.js + test/script/basic/NASHORN-711.js + test/script/basic/NASHORN-711.js.EXPECTED + test/script/basic/NASHORN-72.js + test/script/basic/NASHORN-72.js.EXPECTED + test/script/basic/NASHORN-722.js + test/script/basic/NASHORN-73.js + test/script/basic/NASHORN-73.js.EXPECTED + test/script/basic/NASHORN-737.js + test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/NASHORN-74.js + test/script/basic/NASHORN-74.js.EXPECTED + test/script/basic/NASHORN-740.js + test/script/basic/NASHORN-740.js.EXPECTED + test/script/basic/NASHORN-75.js + test/script/basic/NASHORN-75.js.EXPECTED + test/script/basic/NASHORN-758.js + test/script/basic/NASHORN-759.js + test/script/basic/NASHORN-759.js.EXPECTED + test/script/basic/NASHORN-760.js + test/script/basic/NASHORN-768.js + test/script/basic/NASHORN-778.js + test/script/basic/NASHORN-78.js + test/script/basic/NASHORN-79.js + test/script/basic/NASHORN-79.js.EXPECTED + test/script/basic/NASHORN-792.js + test/script/basic/NASHORN-792.js.EXPECTED + test/script/basic/NASHORN-80.js + test/script/basic/NASHORN-80.js.EXPECTED + test/script/basic/NASHORN-81.js + test/script/basic/NASHORN-833.js + test/script/basic/NASHORN-833.js.EXPECTED + test/script/basic/NASHORN-85.js + test/script/basic/NASHORN-85.js.EXPECTED + test/script/basic/NASHORN-86.js + test/script/basic/NASHORN-87.js + test/script/basic/NASHORN-89.js + test/script/basic/NASHORN-90.js + test/script/basic/NASHORN-90.js.EXPECTED + test/script/basic/NASHORN-91.js + test/script/basic/NASHORN-91.js.EXPECTED + test/script/basic/NASHORN-92.js + test/script/basic/NASHORN-92.js.EXPECTED + test/script/basic/NASHORN-93.js + test/script/basic/NASHORN-95.js + test/script/basic/NASHORN-95.js.EXPECTED + test/script/basic/NASHORN-96.js + test/script/basic/NASHORN-96.js.EXPECTED + test/script/basic/NASHORN-97.js + test/script/basic/NASHORN-98.js + test/script/basic/NASHORN-98.js.EXPECTED + test/script/basic/NASHORN-99.js + test/script/basic/addition.js + test/script/basic/addition.js.EXPECTED + test/script/basic/allgettersetters.js + test/script/basic/andor.js + test/script/basic/andor.js.EXPECTED + test/script/basic/anonrecur.js + test/script/basic/anonrecur.js.EXPECTED + test/script/basic/applycall.js + test/script/basic/applycall.js.EXPECTED + test/script/basic/args.js + test/script/basic/args.js.EXPECTED + test/script/basic/arity.js + test/script/basic/arity.js.EXPECTED + test/script/basic/arrayprotoclass.js + test/script/basic/arrayprotoclass.js.EXPECTED + test/script/basic/arrays.js + test/script/basic/arrays.js.EXPECTED + test/script/basic/arrays2.js + test/script/basic/arrays2.js.EXPECTED + test/script/basic/arraysIntKey.js + test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrayset.js + test/script/basic/arrayset.js.EXPECTED + test/script/basic/arrayundefined.js + test/script/basic/arrayundefined.js.EXPECTED + test/script/basic/assign.js + test/script/basic/assign.js.EXPECTED + test/script/basic/bitwise_and.js + test/script/basic/bitwise_and.js.EXPECTED + test/script/basic/booleangetter.js + test/script/basic/booleangetter.js.EXPECTED + test/script/basic/builtin.js + test/script/basic/builtin.js.EXPECTED + test/script/basic/builtin_assign.js + test/script/basic/builtin_assign.js.EXPECTED + test/script/basic/builtinchain.js + test/script/basic/builtinchain.js.EXPECTED + test/script/basic/calllink.js + test/script/basic/calllink.js.EXPECTED + test/script/basic/closure.js + test/script/basic/closure.js.EXPECTED + test/script/basic/commandargs.js + test/script/basic/commandargs.js.EXPECTED + test/script/basic/compile-octane.js + test/script/basic/compile-octane.js.EXPECTED + test/script/basic/condassign.js + test/script/basic/condassign.js.EXPECTED + test/script/basic/construct.js + test/script/basic/construct.js.EXPECTED + test/script/basic/constructorname.js + test/script/basic/constructorname.js.EXPECTED + test/script/basic/date.js + test/script/basic/date.js.EXPECTED + test/script/basic/dateparse.js + test/script/basic/dateparse.js.EXPECTED + test/script/basic/decinc.js + test/script/basic/decinc.js.EXPECTED + test/script/basic/delete.js + test/script/basic/delete.js.EXPECTED + test/script/basic/delete2.js + test/script/basic/delete2.js.EXPECTED + test/script/basic/dotpropname.js + test/script/basic/dotpropname.js.EXPECTED + test/script/basic/doublecache.js + test/script/basic/doublecache.js.EXPECTED + test/script/basic/enumeration.js + test/script/basic/enumeration.js.EXPECTED + test/script/basic/errors.js + test/script/basic/errors.js.EXPECTED + test/script/basic/errorstack.js + test/script/basic/errorstack.js.EXPECTED + test/script/basic/eval.js + test/script/basic/eval.js.EXPECTED + test/script/basic/evalreturn.js + test/script/basic/evalreturn.js.EXPECTED + test/script/basic/exprclosure.js + test/script/basic/exprclosure.js.EXPECTED + test/script/basic/extensibility.js + test/script/basic/extensibility.js.EXPECTED + test/script/basic/fileline.js + test/script/basic/fileline.js.EXPECTED + test/script/basic/finally-catchalls.js + test/script/basic/finally-catchalls.js.EXPECTED + test/script/basic/finallyreturn.js + test/script/basic/finallyreturn.js.EXPECTED + test/script/basic/forin.js + test/script/basic/forin.js.EXPECTED + test/script/basic/forin2.js + test/script/basic/forin2.js.EXPECTED + test/script/basic/funcarray.js + test/script/basic/funcarray.js.EXPECTED + test/script/basic/funcbind.js + test/script/basic/funcbind.js.EXPECTED + test/script/basic/funcconstructor.js + test/script/basic/funcconstructor.js.EXPECTED + test/script/basic/getclassname.js + test/script/basic/getenv.js + test/script/basic/getenv.js.EXPECTED + test/script/basic/getter_callsite.js + test/script/basic/getter_callsite.js.EXPECTED + test/script/basic/gettercalls.js + test/script/basic/gettercalls.js.EXPECTED + test/script/basic/getterfunc.js + test/script/basic/getterfunc.js.EXPECTED + test/script/basic/gettersetter.js + test/script/basic/gettersetter.js.EXPECTED + test/script/basic/globalaccess.js + test/script/basic/globalaccess.js.EXPECTED + test/script/basic/globals.js + test/script/basic/globals.js.EXPECTED + test/script/basic/globalscope.js + test/script/basic/globalscope.js.EXPECTED + test/script/basic/hello.js + test/script/basic/hello.js.EXPECTED + test/script/basic/herestr_operator.js + test/script/basic/herestr_operator.js.EXPECTED + test/script/basic/illegaljavaname.js + test/script/basic/illegaljavaname.js.EXPECTED + test/script/basic/incheck.js + test/script/basic/incheck.js.EXPECTED + test/script/basic/indexedcall.js + test/script/basic/indexedcall.js.EXPECTED + test/script/basic/info.js + test/script/basic/info.js.EXPECTED + test/script/basic/inherited_nonwritable.js + test/script/basic/instanceof.js + test/script/basic/instanceof.js.EXPECTED + test/script/basic/instanceof2.js + test/script/basic/instanceof2.js.EXPECTED + test/script/basic/interfaces.js + test/script/basic/interfaces.js.EXPECTED + test/script/basic/iterator.js + test/script/basic/iterator.js.EXPECTED + test/script/basic/java.js + test/script/basic/java.js.EXPECTED + test/script/basic/javaarray.js + test/script/basic/javaarray.js.EXPECTED + test/script/basic/javaarrayconversion.js + test/script/basic/javaarrayconversion.js.EXPECTED + test/script/basic/javaexceptions.js + test/script/basic/javaexceptions.js.EXPECTED + test/script/basic/javaimporter.js + test/script/basic/javaimporter.js.EXPECTED + test/script/basic/javainnerclasses.js + test/script/basic/javainnerclasses.js.EXPECTED + test/script/basic/javasigcall.js + test/script/basic/javasigcall.js.EXPECTED + test/script/basic/jquery.js + test/script/basic/jquery.js.EXPECTED + test/script/basic/jsadapter.js + test/script/basic/jsadapter.js.EXPECTED + test/script/basic/jsadapterlink.js + test/script/basic/jsadapterlink.js.EXPECTED + test/script/basic/json.js + test/script/basic/json.js.EXPECTED + test/script/basic/list.js + test/script/basic/list.js.EXPECTED + test/script/basic/literal.js + test/script/basic/literal.js.EXPECTED + test/script/basic/load.js + test/script/basic/load.js.EXPECTED + test/script/basic/loadedfile.js + test/script/basic/localundef.js + test/script/basic/localundef.js.EXPECTED + test/script/basic/map.js + test/script/basic/map.js.EXPECTED + test/script/basic/math.js + test/script/basic/math.js.EXPECTED + test/script/basic/minuszero.js + test/script/basic/minuszero.js.EXPECTED + test/script/basic/module.js + test/script/basic/moduleload.js + test/script/basic/moduleload.js.EXPECTED + test/script/basic/nashorn2.js + test/script/basic/nashorn2.js.EXPECTED + test/script/basic/natives.js + test/script/basic/natives.js.EXPECTED + test/script/basic/new.js + test/script/basic/new.js.EXPECTED + test/script/basic/newexpr.js + test/script/basic/newexpr.js.EXPECTED + test/script/basic/newnew.js + test/script/basic/newnew.js.EXPECTED + test/script/basic/nonconstructors.js + test/script/basic/nonconstructors.js.EXPECTED + test/script/basic/nosuchmethod.js + test/script/basic/nosuchmethod.js.EXPECTED + test/script/basic/nosuchproperty.js + test/script/basic/nosuchproperty.js.EXPECTED + test/script/basic/number.js + test/script/basic/number.js.EXPECTED + test/script/basic/numberstring.js + test/script/basic/numberstring.js.EXPECTED + test/script/basic/objectprops.js + test/script/basic/objectprops.js.EXPECTED + test/script/basic/objects.js + test/script/basic/objects.js.EXPECTED + test/script/basic/options.js + test/script/basic/options.js.EXPECTED + test/script/basic/propchange.js + test/script/basic/propchange.js.EXPECTED + test/script/basic/propertycheck.js + test/script/basic/propertycheck.js.EXPECTED + test/script/basic/proto.js.EXPECTED + test/script/basic/prototype.js + test/script/basic/prototype.js.EXPECTED + test/script/basic/pushpull.js + test/script/basic/pushpull.js.EXPECTED + test/script/basic/regex.js + test/script/basic/regex.js.EXPECTED + test/script/basic/regexp_flags.js + test/script/basic/run-octane.js + test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED + test/script/basic/samfunc.js + test/script/basic/samfunc.js.EXPECTED + test/script/basic/scripting.js + test/script/basic/scripting.js.EXPECTED + test/script/basic/sealfreeze.js + test/script/basic/sealfreeze.js.EXPECTED + test/script/basic/setlength.js + test/script/basic/setlength.js.EXPECTED + test/script/basic/stdin.js + test/script/basic/stdin.js.EXPECTED + test/script/basic/strings.js + test/script/basic/strings.js.EXPECTED + test/script/basic/throws.js + test/script/basic/throws.js.EXPECTED + test/script/basic/tosource.js + test/script/basic/tosource.js.EXPECTED + test/script/basic/tostring.js + test/script/basic/tostring.js.EXPECTED + test/script/basic/try.js + test/script/basic/try.js.EXPECTED + test/script/basic/trybreakcont.js + test/script/basic/trybreakcont.js.EXPECTED + test/script/basic/trycatch.js + test/script/basic/trycatch.js.EXPECTED + test/script/basic/trycatchfor.js + test/script/basic/trycatchfor.js.EXPECTED + test/script/basic/tryfinallyreturn.js + test/script/basic/tryfinallyreturn.js.EXPECTED + test/script/basic/tryforbreak.js + test/script/basic/tryforbreak.js.EXPECTED + test/script/basic/typechange.js + test/script/basic/typechange.js.EXPECTED + test/script/basic/typeof.js + test/script/basic/typeof.js.EXPECTED + test/script/basic/typeof2.js + test/script/basic/typeof2.js.EXPECTED + test/script/basic/undefined.js + test/script/basic/undefined.js.EXPECTED + test/script/basic/underscore.js + test/script/basic/underscore.js.EXPECTED + test/script/basic/varargs.js + test/script/basic/varargs.js.EXPECTED + test/script/basic/void.js + test/script/basic/void.js.EXPECTED + test/script/basic/with.js + test/script/basic/with.js.EXPECTED + test/script/basic/withprimitive.js + test/script/basic/withprimitive.js.EXPECTED + test/script/basic/writable_relink.js + test/script/basic/writable_relink.js.EXPECTED + test/script/basic/xmlStrings.js.EXPECTED + test/script/basic/xorassign.js + test/script/basic/xorassign.js.EXPECTED + test/script/basic/yui.js + test/script/basic/yui.js.EXPECTED + test/script/error/NASHORN-154/README + test/script/error/NASHORN-154/function_mult_params_in_strict.js + test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED + test/script/error/NASHORN-154/improper_return_break_continue.js + test/script/error/NASHORN-154/improper_return_break_continue.js.EXPECTED + test/script/error/NASHORN-154/invalid_lvalue.js + test/script/error/NASHORN-154/invalid_lvalue.js.EXPECTED + test/script/error/NASHORN-154/literal_data_and_accessor.js + test/script/error/NASHORN-154/literal_data_and_accessor.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_getters.js + test/script/error/NASHORN-154/literal_mult_getters.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js.EXPECTED + test/script/error/NASHORN-154/with_in_strict.js + test/script/error/NASHORN-154/with_in_strict.js.EXPECTED + test/script/error/NASHORN-214.js + test/script/error/NASHORN-214.js.EXPECTED + test/script/error/NASHORN-35.js + test/script/error/NASHORN-35.js.EXPECTED + test/script/error/NASHORN-39.js + test/script/error/NASHORN-39.js.EXPECTED + test/script/error/NASHORN-568.js + test/script/error/NASHORN-568.js.EXPECTED + test/script/error/NASHORN-57.js + test/script/error/NASHORN-57.js.EXPECTED + test/script/error/NASHORN-668.js + test/script/error/NASHORN-668.js.EXPECTED + test/script/error/quotemissing.js + test/script/error/quotemissing.js.EXPECTED + test/script/error/strictmode.js + test/script/error/strictmode.js.EXPECTED + test/script/representations/NASHORN-592a.js + test/script/sandbox/NASHORN-525.js + test/script/sandbox/README + test/script/sandbox/classloader.js + test/script/sandbox/classloader.js.EXPECTED + test/script/sandbox/doprivileged.js + test/script/sandbox/doprivileged.js.EXPECTED + test/script/sandbox/exit.js + test/script/sandbox/exit.js.EXPECTED + test/script/sandbox/file.js + test/script/sandbox/file.js.EXPECTED + test/script/sandbox/javaextend.js + test/script/sandbox/javaextend.js.EXPECTED + test/script/sandbox/loadLibrary.js + test/script/sandbox/net.js + test/script/sandbox/net.js.EXPECTED + test/script/sandbox/property.js + test/script/sandbox/property.js.EXPECTED + test/script/sandbox/reflection.js + test/script/sandbox/reflection.js.EXPECTED + test/script/sandbox/runnable.js + test/script/sandbox/runnable.js.EXPECTED + test/script/sandbox/unsafe.js + test/script/sandbox/unsafe.js.EXPECTED + test/script/test262.js + test/script/test262_single.js + test/src/UnnamedPackageTestCallback.java + test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/Window.java + test/src/jdk/nashorn/api/scripting/WindowEventHandler.java + test/src/jdk/nashorn/internal/access/BooleanAccessTest.java + test/src/jdk/nashorn/internal/access/MethodAccessTest.java + test/src/jdk/nashorn/internal/access/NumberAccessTest.java + test/src/jdk/nashorn/internal/access/NumberBoxingTest.java + test/src/jdk/nashorn/internal/access/ObjectAccessTest.java + test/src/jdk/nashorn/internal/access/Person.java + test/src/jdk/nashorn/internal/access/SharedObject.java + test/src/jdk/nashorn/internal/access/StringAccessTest.java + test/src/jdk/nashorn/internal/codegen/CompilerTest.java + test/src/jdk/nashorn/internal/parser/ParserTest.java + test/src/jdk/nashorn/internal/performance/AuroraWrapper.java + test/src/jdk/nashorn/internal/performance/OctaneTest.java + test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java + test/src/jdk/nashorn/internal/performance/SplayTest.java + test/src/jdk/nashorn/internal/runtime/ContextTest.java + test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java + test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java + test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java + test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java + test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java + test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/ScriptTest.java + test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/TestConfig.java + test/src/jdk/nashorn/internal/test/framework/TestFinder.java + test/src/jdk/nashorn/internal/test/framework/TestHelper.java + test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java + test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/internal/test/models/FinalClass.java + test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/internal/test/models/NonPublicClass.java + test/src/jdk/nashorn/internal/test/models/OuterClass.java + test/src/jdk/nashorn/internal/test/models/OverloadedSam.java + test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: b4b05457b8b2 Author: jlaskey Date: 2012-12-22 08:49 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b4b05457b8b2 8005440: Improve .hgignore filtering for Nashorn repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: 3a7e1580bc0a Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3a7e1580bc0a 8005666: Add webrev to .hgignore Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: c6e194450af7 Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c6e194450af7 8005665: JavaDoc should only display public interfaces Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/build.xml Changeset: 5a1b0714df0e Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5a1b0714df0e 8005663: Update copyright year to 2013 Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! bin/checkintest.sh ! bin/fixorphantests.sh ! bin/fixwhitespace.sh ! bin/jjs ! bin/jjs.bat ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashorn ! bin/nashorn.bat ! bin/rm-non-tracked.sh ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! buildtools/nasgen/build.xml ! buildtools/nasgen/nasgen.iml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! docs/genshelldoc.js ! make/Makefile ! make/build-benchmark.xml ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-file-targets.xml ! make/nbproject/ide-targets.xml ! make/nbproject/jdk.xml ! make/nbproject/nbjdk.properties ! make/nbproject/nbjdk.xml ! make/nbproject/project.xml ! make/project.properties ! samples/counters.js ! samples/letter.js ! samples/parser.js ! samples/shell.js ! samples/test.js ! samples/uniq.js ! src/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/package-info.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/Emitter.java ! src/jdk/nashorn/internal/codegen/Frame.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/ArrayType.java ! src/jdk/nashorn/internal/codegen/types/BitwiseType.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/NumericType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyKey.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/annotations/ChildNode.java ! src/jdk/nashorn/internal/ir/annotations/Ignore.java ! src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk/nashorn/internal/objects/annotations/Constructor.java ! src/jdk/nashorn/internal/objects/annotations/Function.java ! src/jdk/nashorn/internal/objects/annotations/Getter.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/objects/annotations/ScriptClass.java ! src/jdk/nashorn/internal/objects/annotations/Setter.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk/nashorn/internal/objects/annotations/Where.java ! src/jdk/nashorn/internal/objects/package-info.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/RegExp.java ! src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/parser/Token.java ! src/jdk/nashorn/internal/parser/TokenKind.java ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSErrorType.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/NumberToString.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/Version.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Mangler.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/options/ValueOption.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! src/jdk/nashorn/internal/runtime/resources/version.properties-template ! src/jdk/nashorn/internal/scripts/JO$.java ! src/jdk/nashorn/internal/scripts/JS$.java ! src/jdk/nashorn/tools/Shell.java ! src/jdk/nashorn/tools/resources/Shell.properties ! src/jdk/nashorn/tools/resources/shell.js ! src/netscape/javascript/JSObject.java ! src/overview.html ! test/examples/dual-fields-micro.js ! test/examples/innerbench.js ! test/examples/typechain.js ! test/lib/benchmark.js ! test/opt/add.js ! test/opt/add_constant.js ! test/opt/add_reuse_callsite.js ! test/opt/add_revert2.js ! test/opt/cascade_specialize.js ! test/script/assert.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-101.js ! test/script/basic/NASHORN-102.js ! test/script/basic/NASHORN-103.js ! test/script/basic/NASHORN-104.js ! test/script/basic/NASHORN-105.js ! test/script/basic/NASHORN-106.js ! test/script/basic/NASHORN-107.js ! test/script/basic/NASHORN-108.js ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-11.js ! test/script/basic/NASHORN-111.js ! test/script/basic/NASHORN-113.js ! test/script/basic/NASHORN-114.js ! test/script/basic/NASHORN-115.js ! test/script/basic/NASHORN-117.js ! test/script/basic/NASHORN-118.js ! test/script/basic/NASHORN-119.js ! test/script/basic/NASHORN-12.js ! test/script/basic/NASHORN-120.js ! test/script/basic/NASHORN-122.js ! test/script/basic/NASHORN-126.js ! test/script/basic/NASHORN-127.js ! test/script/basic/NASHORN-130.js ! test/script/basic/NASHORN-132.js ! test/script/basic/NASHORN-133.js ! test/script/basic/NASHORN-135.js ! test/script/basic/NASHORN-136.js ! test/script/basic/NASHORN-14.js ! test/script/basic/NASHORN-148.js ! test/script/basic/NASHORN-15.js ! test/script/basic/NASHORN-153.js ! test/script/basic/NASHORN-156.js ! test/script/basic/NASHORN-157.js ! test/script/basic/NASHORN-163.js ! test/script/basic/NASHORN-164.js ! test/script/basic/NASHORN-165.js ! test/script/basic/NASHORN-166.js ! test/script/basic/NASHORN-168.js ! test/script/basic/NASHORN-169.js ! test/script/basic/NASHORN-172.js ! test/script/basic/NASHORN-173.js ! test/script/basic/NASHORN-174.js ! test/script/basic/NASHORN-175.js ! test/script/basic/NASHORN-176.js ! test/script/basic/NASHORN-177.js ! test/script/basic/NASHORN-178.js ! test/script/basic/NASHORN-179.js ! test/script/basic/NASHORN-18.js ! test/script/basic/NASHORN-181.js ! test/script/basic/NASHORN-182.js ! test/script/basic/NASHORN-183.js ! test/script/basic/NASHORN-184.js ! test/script/basic/NASHORN-185.js ! test/script/basic/NASHORN-187.js ! test/script/basic/NASHORN-188.js ! test/script/basic/NASHORN-19.js ! test/script/basic/NASHORN-190.js ! test/script/basic/NASHORN-192.js ! test/script/basic/NASHORN-194.js ! test/script/basic/NASHORN-196.js ! test/script/basic/NASHORN-198.js ! test/script/basic/NASHORN-20.js ! test/script/basic/NASHORN-201.js ! test/script/basic/NASHORN-202.js ! test/script/basic/NASHORN-203.js ! test/script/basic/NASHORN-204.js ! test/script/basic/NASHORN-205.js ! test/script/basic/NASHORN-206.js ! test/script/basic/NASHORN-207.js ! test/script/basic/NASHORN-207_2.js ! test/script/basic/NASHORN-208.js ! test/script/basic/NASHORN-209.js ! test/script/basic/NASHORN-21.js ! test/script/basic/NASHORN-211.js ! test/script/basic/NASHORN-212.js ! test/script/basic/NASHORN-213.js ! test/script/basic/NASHORN-215.js ! test/script/basic/NASHORN-216.js ! test/script/basic/NASHORN-217.js ! test/script/basic/NASHORN-219.js ! test/script/basic/NASHORN-22.js ! test/script/basic/NASHORN-221.js ! test/script/basic/NASHORN-222.js ! test/script/basic/NASHORN-223.js ! test/script/basic/NASHORN-225.js ! test/script/basic/NASHORN-226.js ! test/script/basic/NASHORN-227.js ! test/script/basic/NASHORN-228.js ! test/script/basic/NASHORN-229.js ! test/script/basic/NASHORN-229_subtest.js ! test/script/basic/NASHORN-23.js ! test/script/basic/NASHORN-232.js ! test/script/basic/NASHORN-234.js ! test/script/basic/NASHORN-235.js ! test/script/basic/NASHORN-236.js ! test/script/basic/NASHORN-237.js ! test/script/basic/NASHORN-239.js ! test/script/basic/NASHORN-24.js ! test/script/basic/NASHORN-241.js ! test/script/basic/NASHORN-242.js ! test/script/basic/NASHORN-245.js ! test/script/basic/NASHORN-247.js ! test/script/basic/NASHORN-25.js ! test/script/basic/NASHORN-251.js ! test/script/basic/NASHORN-252.js ! test/script/basic/NASHORN-253.js ! test/script/basic/NASHORN-256.js ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-26.js ! test/script/basic/NASHORN-260.js ! test/script/basic/NASHORN-261.js ! test/script/basic/NASHORN-262.js ! test/script/basic/NASHORN-263.js ! test/script/basic/NASHORN-264.js ! test/script/basic/NASHORN-265.js ! test/script/basic/NASHORN-266.js ! test/script/basic/NASHORN-269.js ! test/script/basic/NASHORN-27.js ! test/script/basic/NASHORN-270.js ! test/script/basic/NASHORN-271.js ! test/script/basic/NASHORN-275.js ! test/script/basic/NASHORN-276.js ! test/script/basic/NASHORN-277.js ! test/script/basic/NASHORN-278.js ! test/script/basic/NASHORN-28.js ! test/script/basic/NASHORN-281.js ! test/script/basic/NASHORN-284.js ! test/script/basic/NASHORN-285.js ! test/script/basic/NASHORN-288.js ! test/script/basic/NASHORN-29.js ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-294.js ! test/script/basic/NASHORN-296.js ! test/script/basic/NASHORN-297.js ! test/script/basic/NASHORN-30.js ! test/script/basic/NASHORN-300.js ! test/script/basic/NASHORN-301.js ! test/script/basic/NASHORN-304.js ! test/script/basic/NASHORN-310.js ! test/script/basic/NASHORN-318.js ! test/script/basic/NASHORN-32.js ! test/script/basic/NASHORN-321.js ! test/script/basic/NASHORN-323.js ! test/script/basic/NASHORN-324.js ! test/script/basic/NASHORN-33.js ! test/script/basic/NASHORN-331.js ! test/script/basic/NASHORN-337.js ! test/script/basic/NASHORN-34.js ! test/script/basic/NASHORN-340.js ! test/script/basic/NASHORN-349.js ! test/script/basic/NASHORN-354.js ! test/script/basic/NASHORN-355.js ! test/script/basic/NASHORN-36.js ! test/script/basic/NASHORN-365.js ! test/script/basic/NASHORN-366.js ! test/script/basic/NASHORN-368.js ! test/script/basic/NASHORN-37.js ! test/script/basic/NASHORN-375.js ! test/script/basic/NASHORN-376.js ! test/script/basic/NASHORN-377.js ! test/script/basic/NASHORN-378.js ! test/script/basic/NASHORN-38.js ! test/script/basic/NASHORN-380.js ! test/script/basic/NASHORN-381.js ! test/script/basic/NASHORN-382.js ! test/script/basic/NASHORN-383.js ! test/script/basic/NASHORN-384.js ! test/script/basic/NASHORN-385.js ! test/script/basic/NASHORN-389.js ! test/script/basic/NASHORN-393.js ! test/script/basic/NASHORN-394.js ! test/script/basic/NASHORN-396.js ! test/script/basic/NASHORN-397.js ! test/script/basic/NASHORN-398.js ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-400.js ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-402.js ! test/script/basic/NASHORN-404.js ! test/script/basic/NASHORN-405.js ! test/script/basic/NASHORN-406.js ! test/script/basic/NASHORN-408.js ! test/script/basic/NASHORN-415.js ! test/script/basic/NASHORN-416.js ! test/script/basic/NASHORN-417.js ! test/script/basic/NASHORN-418.js ! test/script/basic/NASHORN-420.js ! test/script/basic/NASHORN-421.js ! test/script/basic/NASHORN-423.js ! test/script/basic/NASHORN-423a.js ! test/script/basic/NASHORN-424.js ! test/script/basic/NASHORN-425.js ! test/script/basic/NASHORN-426.js ! test/script/basic/NASHORN-427.js ! test/script/basic/NASHORN-428.js ! test/script/basic/NASHORN-429.js ! test/script/basic/NASHORN-432.js ! test/script/basic/NASHORN-433.js ! test/script/basic/NASHORN-434.js ! test/script/basic/NASHORN-435.js ! test/script/basic/NASHORN-437.js ! test/script/basic/NASHORN-44.js ! test/script/basic/NASHORN-441.js ! test/script/basic/NASHORN-442.js ! test/script/basic/NASHORN-443.js ! test/script/basic/NASHORN-444.js ! test/script/basic/NASHORN-445.js ! test/script/basic/NASHORN-446.js ! test/script/basic/NASHORN-447.js ! test/script/basic/NASHORN-448.js ! test/script/basic/NASHORN-449.js ! test/script/basic/NASHORN-45.js ! test/script/basic/NASHORN-450.js ! test/script/basic/NASHORN-452.js ! test/script/basic/NASHORN-459.js ! test/script/basic/NASHORN-46.js ! test/script/basic/NASHORN-462.js ! test/script/basic/NASHORN-463.js ! test/script/basic/NASHORN-468.js ! test/script/basic/NASHORN-47.js ! test/script/basic/NASHORN-473.js ! test/script/basic/NASHORN-474.js ! test/script/basic/NASHORN-478.js ! test/script/basic/NASHORN-48.js ! test/script/basic/NASHORN-481.js ! test/script/basic/NASHORN-482.js ! test/script/basic/NASHORN-484.js ! test/script/basic/NASHORN-486.js ! test/script/basic/NASHORN-487.js ! test/script/basic/NASHORN-488.js ! test/script/basic/NASHORN-49.js ! test/script/basic/NASHORN-490.js ! test/script/basic/NASHORN-494.js ! test/script/basic/NASHORN-497.js ! test/script/basic/NASHORN-498.js ! test/script/basic/NASHORN-499.js ! test/script/basic/NASHORN-50.js ! test/script/basic/NASHORN-500.js ! test/script/basic/NASHORN-503.js ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-511.js ! test/script/basic/NASHORN-515.js ! test/script/basic/NASHORN-516.js ! test/script/basic/NASHORN-52.js ! test/script/basic/NASHORN-534.js ! test/script/basic/NASHORN-535.js ! test/script/basic/NASHORN-544.js ! test/script/basic/NASHORN-55.js ! test/script/basic/NASHORN-554.js ! test/script/basic/NASHORN-556.js ! test/script/basic/NASHORN-56.js ! test/script/basic/NASHORN-562.js ! test/script/basic/NASHORN-565.js ! test/script/basic/NASHORN-575.js ! test/script/basic/NASHORN-58.js ! test/script/basic/NASHORN-59.js ! test/script/basic/NASHORN-592.js ! test/script/basic/NASHORN-597.js ! test/script/basic/NASHORN-60.js ! test/script/basic/NASHORN-609.js ! test/script/basic/NASHORN-61.js ! test/script/basic/NASHORN-62.js ! test/script/basic/NASHORN-620.js ! test/script/basic/NASHORN-623.js ! test/script/basic/NASHORN-627.js ! test/script/basic/NASHORN-63.js ! test/script/basic/NASHORN-637.js ! test/script/basic/NASHORN-638.js ! test/script/basic/NASHORN-639.js ! test/script/basic/NASHORN-64.js ! test/script/basic/NASHORN-642.js ! test/script/basic/NASHORN-646.js ! test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-658.js ! test/script/basic/NASHORN-659.js ! test/script/basic/NASHORN-66.js ! test/script/basic/NASHORN-664.js ! test/script/basic/NASHORN-665.js ! test/script/basic/NASHORN-67.js ! test/script/basic/NASHORN-678.js ! test/script/basic/NASHORN-68.js ! test/script/basic/NASHORN-689.js ! test/script/basic/NASHORN-69.js ! test/script/basic/NASHORN-691.js ! test/script/basic/NASHORN-694.js ! test/script/basic/NASHORN-697.js ! test/script/basic/NASHORN-703.js ! test/script/basic/NASHORN-703a.js ! test/script/basic/NASHORN-705.js ! test/script/basic/NASHORN-71.js ! test/script/basic/NASHORN-710.js ! test/script/basic/NASHORN-711.js ! test/script/basic/NASHORN-72.js ! test/script/basic/NASHORN-722.js ! test/script/basic/NASHORN-73.js ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-74.js ! test/script/basic/NASHORN-740.js ! test/script/basic/NASHORN-75.js ! test/script/basic/NASHORN-758.js ! test/script/basic/NASHORN-759.js ! test/script/basic/NASHORN-760.js ! test/script/basic/NASHORN-768.js ! test/script/basic/NASHORN-778.js ! test/script/basic/NASHORN-78.js ! test/script/basic/NASHORN-79.js ! test/script/basic/NASHORN-792.js ! test/script/basic/NASHORN-80.js ! test/script/basic/NASHORN-81.js ! test/script/basic/NASHORN-833.js ! test/script/basic/NASHORN-85.js ! test/script/basic/NASHORN-86.js ! test/script/basic/NASHORN-87.js ! test/script/basic/NASHORN-89.js ! test/script/basic/NASHORN-90.js ! test/script/basic/NASHORN-91.js ! test/script/basic/NASHORN-92.js ! test/script/basic/NASHORN-93.js ! test/script/basic/NASHORN-95.js ! test/script/basic/NASHORN-96.js ! test/script/basic/NASHORN-97.js ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-99.js ! test/script/basic/addition.js ! test/script/basic/allgettersetters.js ! test/script/basic/andor.js ! test/script/basic/anonrecur.js ! test/script/basic/applycall.js ! test/script/basic/args.js ! test/script/basic/arity.js ! test/script/basic/arrayprotoclass.js ! test/script/basic/arrays.js ! test/script/basic/arrays2.js ! test/script/basic/arraysIntKey.js ! test/script/basic/arrayset.js ! test/script/basic/arrayundefined.js ! test/script/basic/assign.js ! test/script/basic/bitwise_and.js ! test/script/basic/booleangetter.js ! test/script/basic/builtin.js ! test/script/basic/builtin_assign.js ! test/script/basic/builtinchain.js ! test/script/basic/calllink.js ! test/script/basic/closure.js ! test/script/basic/commandargs.js ! test/script/basic/compile-octane.js ! test/script/basic/condassign.js ! test/script/basic/construct.js ! test/script/basic/constructorname.js ! test/script/basic/date.js ! test/script/basic/dateparse.js ! test/script/basic/decinc.js ! test/script/basic/delete.js ! test/script/basic/delete2.js ! test/script/basic/dotpropname.js ! test/script/basic/doublecache.js ! test/script/basic/enumeration.js ! test/script/basic/errors.js ! test/script/basic/errorstack.js ! test/script/basic/eval.js ! test/script/basic/evalreturn.js ! test/script/basic/exprclosure.js ! test/script/basic/extensibility.js ! test/script/basic/fileline.js ! test/script/basic/finally-catchalls.js ! test/script/basic/finallyreturn.js ! test/script/basic/forin.js ! test/script/basic/forin2.js ! test/script/basic/funcarray.js ! test/script/basic/funcbind.js ! test/script/basic/funcconstructor.js ! test/script/basic/getclassname.js ! test/script/basic/getenv.js ! test/script/basic/getter_callsite.js ! test/script/basic/gettercalls.js ! test/script/basic/getterfunc.js ! test/script/basic/gettersetter.js ! test/script/basic/globalaccess.js ! test/script/basic/globals.js ! test/script/basic/globalscope.js ! test/script/basic/hello.js ! test/script/basic/herestr_operator.js ! test/script/basic/illegaljavaname.js ! test/script/basic/incheck.js ! test/script/basic/indexedcall.js ! test/script/basic/info.js ! test/script/basic/inherited_nonwritable.js ! test/script/basic/instanceof.js ! test/script/basic/instanceof2.js ! test/script/basic/interfaces.js ! test/script/basic/iterator.js ! test/script/basic/java.js ! test/script/basic/javaarray.js ! test/script/basic/javaarrayconversion.js ! test/script/basic/javaexceptions.js ! test/script/basic/javaimporter.js ! test/script/basic/javainnerclasses.js ! test/script/basic/javasigcall.js ! test/script/basic/jquery.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapterlink.js ! test/script/basic/json.js ! test/script/basic/list.js ! test/script/basic/literal.js ! test/script/basic/load.js ! test/script/basic/loadedfile.js ! test/script/basic/localundef.js ! test/script/basic/map.js ! test/script/basic/math.js ! test/script/basic/minuszero.js ! test/script/basic/module.js ! test/script/basic/moduleload.js ! test/script/basic/nashorn2.js ! test/script/basic/natives.js ! test/script/basic/new.js ! test/script/basic/newexpr.js ! test/script/basic/newnew.js ! test/script/basic/nonconstructors.js ! test/script/basic/nosuchmethod.js ! test/script/basic/nosuchproperty.js ! test/script/basic/number.js ! test/script/basic/numberstring.js ! test/script/basic/objectprops.js ! test/script/basic/objects.js ! test/script/basic/options.js ! test/script/basic/propchange.js ! test/script/basic/propertycheck.js ! test/script/basic/prototype.js ! test/script/basic/pushpull.js ! test/script/basic/regex.js ! test/script/basic/regexp_flags.js ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/basic/samfunc.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED ! test/script/basic/sealfreeze.js ! test/script/basic/setlength.js ! test/script/basic/stdin.js ! test/script/basic/strings.js ! test/script/basic/throws.js ! test/script/basic/tosource.js ! test/script/basic/tostring.js ! test/script/basic/try.js ! test/script/basic/trybreakcont.js ! test/script/basic/trycatch.js ! test/script/basic/trycatchfor.js ! test/script/basic/tryfinallyreturn.js ! test/script/basic/tryforbreak.js ! test/script/basic/typechange.js ! test/script/basic/typeof.js ! test/script/basic/typeof2.js ! test/script/basic/undefined.js ! test/script/basic/underscore.js ! test/script/basic/varargs.js ! test/script/basic/void.js ! test/script/basic/with.js ! test/script/basic/withprimitive.js ! test/script/basic/writable_relink.js ! test/script/basic/xorassign.js ! test/script/basic/yui.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js ! test/script/error/NASHORN-154/improper_return_break_continue.js ! test/script/error/NASHORN-154/invalid_lvalue.js ! test/script/error/NASHORN-154/literal_data_and_accessor.js ! test/script/error/NASHORN-154/literal_mult_getters.js ! test/script/error/NASHORN-154/literal_mult_prop_in_strict.js ! test/script/error/NASHORN-154/with_in_strict.js ! test/script/error/NASHORN-214.js ! test/script/error/NASHORN-35.js ! test/script/error/NASHORN-39.js ! test/script/error/NASHORN-568.js ! test/script/error/NASHORN-57.js ! test/script/error/NASHORN-668.js ! test/script/error/quotemissing.js ! test/script/error/strictmode.js ! test/script/representations/NASHORN-592a.js ! test/script/sandbox/NASHORN-525.js ! test/script/sandbox/classloader.js ! test/script/sandbox/doprivileged.js ! test/script/sandbox/exit.js ! test/script/sandbox/file.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/loadLibrary.js ! test/script/sandbox/net.js ! test/script/sandbox/property.js ! test/script/sandbox/reflection.js ! test/script/sandbox/runnable.js ! test/script/sandbox/unsafe.js ! test/script/test262.js ! test/script/test262_single.js ! test/src/UnnamedPackageTestCallback.java ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/api/scripting/WindowEventHandler.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/access/MethodAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberBoxingTest.java ! test/src/jdk/nashorn/internal/access/ObjectAccessTest.java ! test/src/jdk/nashorn/internal/access/Person.java ! test/src/jdk/nashorn/internal/access/SharedObject.java ! test/src/jdk/nashorn/internal/access/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/performance/AuroraWrapper.java ! test/src/jdk/nashorn/internal/performance/OctaneTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/performance/SplayTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java ! test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptTest.java ! test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java ! test/src/jdk/nashorn/internal/test/framework/TestHelper.java ! test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java ! test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java ! test/src/jdk/nashorn/internal/test/models/FinalClass.java ! test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java ! test/src/jdk/nashorn/internal/test/models/NonPublicClass.java ! test/src/jdk/nashorn/internal/test/models/OuterClass.java ! test/src/jdk/nashorn/internal/test/models/OverloadedSam.java ! test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: 1e3f411f47bf Author: lagergren Date: 2013-01-07 19:31 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1e3f411f47bf 8005789: Forgot to document -Dnashorn.unstable.relink.threshold Summary: Added documentation to DEVELOPER_README, fixed code convention warnings Reviewed-by: attila ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 41c7093477ae Author: jlaskey Date: 2013-01-07 14:41 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/41c7093477ae 8005703: Offsets miscalculated for blocks Reviewed-by: lagergren Contributed-by: petr.hejl at oracle.com ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: d14da0d0c577 Author: sundar Date: 2013-01-08 08:51 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d14da0d0c577 8005782: get rid of javadoc errors, warnings in nashorn build Reviewed-by: lagergren ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 0e7da548ef6a Author: lagergren Date: 2013-01-08 09:59 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/0e7da548ef6a 8005788: Loggers and their corresponding system properties not working correctly Summary: 1-1 mapping now maintained. Used Context err instead of System.err in several places (after bootstrapping Context). Problematic closing of err stream replaced by @SuppressWarnings("resource") Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 5f2db2d8a7fa Author: sundar Date: 2013-01-08 15:02 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5f2db2d8a7fa 8005835: NASHORN-668 output fails to compare with the corresponding .EXPECTED file Reviewed-by: lagergren, hannesw ! test/script/error/NASHORN-668.js.EXPECTED Changeset: d8e4d66f1a06 Author: lagergren Date: 2013-01-08 10:52 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d8e4d66f1a06 8005843: refSymbols lookup of unbound variable could cause NullPointerException in Lower Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/NASHORN-837.js Changeset: c5a321205f49 Author: attila Date: 2013-01-08 13:50 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c5a321205f49 8005846: Remove Mangler in favor of Dynalink's NameCodec Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 4620ac94e7dc Author: attila Date: 2013-01-08 14:14 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4620ac94e7dc 8005801: Refactor findSetMethod Summary: findSetMethod() was a very large single method, very unreadable and unmaintainable. It was broken into easy-to-understand pieces. The refactoring required introduction of a comand-object like entity, SetMethodCreator, to contain the nontrivial transient state of the algorithm that made the original big method so resistant to refactoring in the first place. Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java - src/jdk/nashorn/internal/runtime/linker/Mangler.java Changeset: 69a4f0363d0f Author: lagergren Date: 2013-01-08 15:20 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/69a4f0363d0f 8005842: Loops in ASTWriter. Corrected @Reference and @Ignore node annotation for IR nodes Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 548587cfb065 Author: sundar Date: 2013-01-08 21:16 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/548587cfb065 8005848: assigning to global toString variable affects Object.prototype.toString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK_8005848.js Changeset: 812b9963b1c7 Author: attila Date: 2013-01-09 15:02 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/812b9963b1c7 8005777: Bug in the FacetIntrospector of Dynalink - non-public class should search super Reviewed-by: lagergren, sundar ! make/project.properties Changeset: 4cd65798ec70 Author: sundar Date: 2013-01-09 22:32 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4cd65798ec70 8005940: provide ant targets to get and update external test scripts Reviewed-by: jlaskey, lagergren ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! make/Makefile ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 9f59ba5090f2 Author: lagergren Date: 2013-01-10 10:28 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/9f59ba5090f2 8005971: runsunspider.js should check results of benchmarks Reviewed-by: attila, hannesw ! test/script/basic/runsunspider.js Changeset: a7f177d6639c Author: sundar Date: 2013-01-10 19:03 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a7f177d6639c 8005987: ant octane tries to run non-benchmark scripts Reviewed-by: lagergren, attila, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 0362d36d3dd6 Author: sundar Date: 2013-01-10 19:55 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/0362d36d3dd6 8005982: NASHORN-71.js failing in nightlys Reviewed-by: attila, lagergren, jlaskey ! test/script/basic/NASHORN-71.js - test/script/basic/NASHORN-71.js.EXPECTED Changeset: 2a5c2258827b Author: attila Date: 2013-01-10 15:28 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/2a5c2258827b 8005983: JavaAdapterFactory generated proxy classes should take extra constructor arguments at the end Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED Changeset: 2a4769fcd13f Author: lagergren Date: 2013-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/2a4769fcd13f 8005976: Break out AccessSpecializer into one pass before CodeGenerator instead of iterative applications from CodeGenerator Summary: Now scope and slot information is guaranteed to be fixed AND NOT CHANGE before CodeGeneration. We want to keep it that way to build future type specializations and bring all type work out of CodeGenerator. Reviewed-by: attila, hannesw + bin/dump_octane_code.sh ! bin/verbose_octane.sh ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f67bf56495ca Author: sundar Date: 2013-01-11 18:26 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f67bf56495ca 8006082: Provide option to run octane benchmarks in separate processes Reviewed-by: lagergren, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 8a5922638ff0 Author: sundar Date: 2013-01-11 20:34 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/8a5922638ff0 8006093: Add a makefile target to run all tests (test, test262, perf tests) Reviewed-by: attila, hannesw ! make/Makefile ! make/build.xml Changeset: eda69555239a Author: attila Date: 2013-01-14 16:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/eda69555239a 8006168: ability to generate multi-type Java adapters Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/DessertTopping.java + test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/internal/test/models/FloorWax.java + test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 3c6db5ea0ecc Author: sundar Date: 2013-01-14 21:30 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3c6db5ea0ecc 8006181: nashorn script engine does not run jrunscript's initialization script Reviewed-by: lagergren, jlaskey Contributed-by: rieberandreas at gmail.com + src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/api/scripting/resources/init.js Changeset: 1d0307c2bb4c Author: attila Date: 2013-01-15 13:10 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1d0307c2bb4c 8006293: Reduce ScriptObject.findCallMethodMethod Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java Changeset: ee73d7378e3e Author: attila Date: 2013-01-15 17:09 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ee73d7378e3e 8005958: invoking a function through INVOKESTATIC with more arguments than it declares resulted in malformed bytecode being generated Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8005958.js Changeset: 9088170e68df Author: attila Date: 2013-01-15 18:08 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/9088170e68df 8006337: Discarded arguments for INVOKESTATIC must still be evaluated for side effects Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006337.js + test/script/basic/JDK-8006337.js.EXPECTED Changeset: 617313881c55 Author: jlaskey Date: 2013-01-16 07:06 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/617313881c55 8006304: Remove pre-population of maps for constructor produced maps Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + test/script/basic/JDK-8006304.js + test/script/basic/JDK-8006304.js.EXPECTED Changeset: 80447df16322 Author: sundar Date: 2013-01-16 17:58 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/80447df16322 8006412: Improve toString method of ScriptObjectMirror class Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cd5b684ce7b2 Author: sundar Date: 2013-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/cd5b684ce7b2 8006424: Passing null or undefined to adapter class constructors results in NPE or ClassCastException Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/basic/JDK-8006424.js Changeset: 4acebfe9e504 Author: jlaskey Date: 2013-01-17 10:33 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4acebfe9e504 8006517: PropertyHashMap.Element.equals() compares to Property Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java Changeset: f8136c060914 Author: sundar Date: 2013-01-18 08:45 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f8136c060914 8006527: nashorn jsr223 engine does not work in sandbox Reviewed-by: jlaskey, attila, lagergren + bin/nashornsecure + bin/nashornsecure.bat ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/sandbox/engine.js + test/script/sandbox/engine.js.EXPECTED + test/script/sandbox/jsadapter.js Changeset: 4361e8cd6a02 Author: sundar Date: 2013-01-18 17:55 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4361e8cd6a02 8006562: findOwnMH in nashorn "objects" package should be cleaned up Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: c887baec012a Author: sundar Date: 2013-01-19 09:14 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c887baec012a 8006584: improve variable handling in NashornScriptEngine Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a8966074d4e9 Author: sundar Date: 2013-01-19 22:35 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a8966074d4e9 8006557: JDK8/Lambda build clashes on Map.replace() Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 0cee498b330d Author: attila Date: 2013-01-21 11:03 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/0cee498b330d 8006525: Give StaticClass objects their own linker Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 8b3cc4ad1810 Author: sundar Date: 2013-01-21 21:17 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/8b3cc4ad1810 8006635: Reduce access levels as much as possible Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 935dcec38e9a Author: hannesw Date: 2013-01-22 14:14 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/935dcec38e9a 8006570: This-value for non-strict functions should be converted to object Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8006570.js + test/script/basic/JDK-8006570.js.EXPECTED Changeset: e43d1013d871 Author: attila Date: 2013-01-22 14:36 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e43d1013d871 8006677: Remove unused FunctionNode flags Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: e62dba3ce52b Author: sundar Date: 2013-01-22 22:07 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e62dba3ce52b 8006678: Avoid too many Context.getGlobal() calls Reviewed-by: lagergren, jlaskey ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 0dbcb7350595 Author: sundar Date: 2013-01-23 17:04 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/0dbcb7350595 8006736: nashorn script engine should support the usage multiple global objects with same engine instance Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d4a968ca8953 Author: sundar Date: 2013-01-24 16:21 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d4a968ca8953 8006575: Error in codegen for element access on primitive value Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006575.js Changeset: 3f528769aee1 Author: sundar Date: 2013-01-24 17:49 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3f528769aee1 8006755: Functions inside with statements dont get correct scope Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8006755.js Changeset: edfa73d9fde7 Author: hannesw Date: 2013-01-24 14:55 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/edfa73d9fde7 8006408: Clean up and specialize NativeString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/examples/string-micro.js Changeset: f336aee22e85 Author: jlaskey Date: 2013-01-24 12:15 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f336aee22e85 8006852: Move tests from JIRA for prepopulated map failures Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8006852a.js + test/script/basic/JDK-8006852a.js.EXPECTED + test/script/basic/JDK-8006852b.js Changeset: bff7087396d7 Author: sundar Date: 2013-01-24 22:38 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/bff7087396d7 8006857: ClassCastException when interface implementing function uses arguments object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8006857.js + test/script/basic/JDK-8006857.js.EXPECTED Changeset: f52d7294536f Author: hannesw Date: 2013-01-25 17:35 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f52d7294536f 8006766: Array-like access to characters of a string is slow Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: 8f7a86f82376 Author: sundar Date: 2013-01-28 18:10 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/8f7a86f82376 8006983: Introduce a command line option to switch off syntactic extensions of nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8006983.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED Changeset: 265c46dbcf43 Author: sundar Date: 2013-01-28 21:29 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/265c46dbcf43 8007004: nashorn script engine should not use thread context class loader as script 'application loader' Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java Changeset: b6c69beebde6 Author: jlaskey Date: 2013-01-28 16:22 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b6c69beebde6 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! make/Makefile + makefiles/BuildNashorn.gmk + makefiles/Makefile Changeset: 333748665588 Author: sundar Date: 2013-01-29 19:57 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/333748665588 8007091: Provide private API to pass application class loader for nashorn script engine Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 755404d7d189 Author: jlaskey Date: 2013-01-29 14:25 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/755404d7d189 8007094: Apply version to nashorn.jar manifest Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 59970b70ebb5 Author: lagergren Date: 2013-01-30 12:26 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/59970b70ebb5 8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate ti ers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/b asic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila ! docs/DEVELOPER_README ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java - src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/FinalizeTypes.java + src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/access-specializer.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/typecoerce.js + test/script/basic/typecoerce.js.EXPECTED Changeset: ca6d5e4b8170 Author: sundar Date: 2013-01-30 17:52 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ca6d5e4b8170 8007132: Java objects returned from constructor functions are lost Reviewed-by: hannesw, lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8007132.js Changeset: 9f913c1843c8 Author: hannesw Date: 2013-01-30 14:57 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/9f913c1843c8 8007109: Regression: String(ConsString) does not flatten argument to String Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/consstring.js + test/src/jdk/nashorn/internal/test/models/StringArgs.java Changeset: c04f54d5b672 Author: sundar Date: 2013-01-30 21:15 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c04f54d5b672 8007140: Java.extend crashes when attempting to extend java.lang.Object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8006424.js + test/script/basic/JDK-8007140.js Changeset: 9c1e7ae975db Author: sundar Date: 2013-01-31 20:07 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/9c1e7ae975db 8007286: Add JavaAdapter and importPackage to compatibility script Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/importpackage.js + test/script/basic/javaadapter.js Changeset: f7825c1a11d3 Author: attila Date: 2013-01-31 18:34 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f7825c1a11d3 8006529: Methods always get callee - it should be conditional Summary: This commit streamlines the bytecode function signatures, prologue, local variable use, scope creation, and invocation. It started out quite innocently when we noticed that we always emit __callee__ parameters for all functions even when they are not needed, but it turned out to be quite a deep rabbit hole. In the end, I identified exact conditions when functions need to have a callee parameter, when they need to receive parent scope, when they need to create their own scope, when they need to have variable arity signature, and when they need to have an "arguments" object, and made sure that callee parameters in signatures only show up when they are needed, that parent function's scope is only passed to a child function when it is needed, that the function only creates its own scope when it is needed. In crypto.js, the number of scopes dropped from 446 to 244, and the number of callees dropped from 315 to 145. Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8006529-b.js + test/script/basic/JDK-8006529-b.js.EXPECTED + test/script/basic/JDK-8006529.js + test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 697f700d90c0 Author: hannesw Date: 2013-02-01 02:24 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/697f700d90c0 8007060: Primitive wrap filter throws ClassCastException in test262parallel Reviewed-by: sundar, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8007060.js + test/script/basic/JDK-8007060.js.EXPECTED Changeset: a704700470fb Author: jlaskey Date: 2013-02-04 08:13 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a704700470fb 8007455: Extraneous $(ECHO) in make/Makefile Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: bb86bf840f9f Author: attila Date: 2013-02-04 15:59 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/bb86bf840f9f 8007460: var assignment to a parameter in a varargs method causes compilation error Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8007460.js + test/script/basic/JDK-8007460.js.EXPECTED Changeset: bee7c8a45a04 Author: lagergren Date: 2013-02-04 16:20 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/bee7c8a45a04 8007215: Varargs broken for the case of passing more than the arg limit arguments. Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007215.js + test/script/basic/JDK-8007215.js.EXPECTED Changeset: 6f58c28c4faa Author: jlaskey Date: 2013-02-04 14:48 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/6f58c28c4faa 8006191: `cmd` -> exec("cmd") in script mode Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8006191.js + test/script/basic/JDK-8006191.js.EXPECTED Changeset: 5c2ed5d89524 Author: sundar Date: 2013-02-05 09:11 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5c2ed5d89524 8007452: add scripting programmers doc changes for nashorn Reviewed-by: jlaskey, hannesw + docs/JavaScriptingProgrammersGuide.html + docs/source/EvalFile.java + docs/source/EvalScript.java + docs/source/InvokeScriptFunction.java + docs/source/InvokeScriptMethod.java + docs/source/MultiScopes.java + docs/source/RunnableImpl.java + docs/source/RunnableImplObject.java + docs/source/ScriptVars.java + docs/source/importpackageclass.js + docs/source/javaarray.js + docs/source/javaextend.js + docs/source/javaimporter.js + docs/source/javatypes.js + docs/source/overload.js + docs/source/runnable.js + docs/source/samfunc.js + docs/source/test.js ! src/jdk/nashorn/internal/objects/NativeJava.java Changeset: c48e8a28da90 Author: sundar Date: 2013-02-05 18:44 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c48e8a28da90 8007521: $ENV should be undefined when security manager is present Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java - test/script/basic/JDK-8006191.js - test/script/basic/JDK-8006191.js.EXPECTED + test/script/currently-failing/JDK-8006191.js + test/script/currently-failing/JDK-8006191.js.EXPECTED + test/script/sandbox/env.js + test/script/sandbox/exec.js Changeset: 819b5485949d Author: sundar Date: 2013-02-05 21:00 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/819b5485949d 8007522: IllegalStateException thrown from String.prototype.search function Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8007522.js Changeset: f05d4dae30f7 Author: sundar Date: 2013-02-05 22:07 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f05d4dae30f7 8007523: VerifyError on script that uses regular expression literals with ternary operator Reviewed-by: lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java ! test/script/basic/JDK-8007522.js + test/script/basic/JDK-8007523.js Changeset: f6fae6de6f4f Author: hannesw Date: 2013-02-06 10:31 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f6fae6de6f4f 8007273: Creation of ScriptFunctions can be refactored Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: fcf541418304 Author: sundar Date: 2013-02-06 17:56 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/fcf541418304 8007619: Add support for deprecated properties of RegExp constructor Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007619.js + test/script/basic/JDK-8007619.js.EXPECTED Changeset: ec4d59c9b8d2 Author: jlaskey Date: 2013-02-06 08:42 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ec4d59c9b8d2 8007545: jjs input evalinput need to be NOT_ENUMERABLE Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/tools/resources/shell.js Changeset: 2ca25bf25d0c Author: jlaskey Date: 2013-02-06 11:57 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/2ca25bf25d0c 8007629: Remove extraneous quit from shell.js Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/resources/shell.js Changeset: 02f810c26ff9 Author: jlaskey Date: 2013-02-06 12:51 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/02f810c26ff9 8007643: Add testing for quit and exit Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/sandbox/exit.js ! test/script/sandbox/exit.js.EXPECTED Changeset: d7e83be6e7aa Author: sundar Date: 2013-02-07 17:17 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d7e83be6e7aa 8007715: Make sure that not all tests run with AllPermission Reviewed-by: lagergren, attila ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/README - test/script/basic/JDK-8006424.js - test/script/basic/JDK-8006529.js - test/script/basic/NASHORN-638.js - test/script/basic/NASHORN-638.js.EXPECTED - test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-758.js - test/script/basic/getenv.js - test/script/basic/getenv.js.EXPECTED ! test/script/basic/javaexceptions.js ! test/script/basic/newexpr.js + test/script/sandbox/interfaceimpl.js + test/script/sandbox/loadcompat.js + test/script/trusted/JDK-8006424.js + test/script/trusted/JDK-8006529.js + test/script/trusted/NASHORN-638.js + test/script/trusted/NASHORN-638.js.EXPECTED + test/script/trusted/NASHORN-653.js + test/script/trusted/README + test/script/trusted/getenv.js + test/script/trusted/getenv.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: bca3a64a4a82 Author: hannesw Date: 2013-02-07 14:58 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/bca3a64a4a82 8007627: Support @Getter annotation on constructor Reviewed-by: attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java Changeset: d5130a5803d1 Author: hannesw Date: 2013-02-07 15:33 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d5130a5803d1 8007718: Make static RegExp properties fully compatible to other engines Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007718.js + test/script/basic/JDK-8007718.js.EXPECTED Changeset: 8742be332c8a Author: jlaskey Date: 2013-02-08 09:19 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/8742be332c8a 8006222: Move slot from SpillProperty to Property Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java Changeset: 5ead5333fa59 Author: attila Date: 2013-02-09 16:58 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5ead5333fa59 8006943: Fix order of function method arguments to be (callee, thisObject) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: abea4ba28901 Author: sundar Date: 2013-02-11 21:26 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/abea4ba28901 8007915: Nashorn IR, codegen, parser packages and Context instance should be inaccessible to user code Reviewed-by: lagergren, jlaskey, attila ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashornsecure ! bin/nashornsecure.bat ! make/Makefile ! make/build.xml + make/java.security.override ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java - src/jdk/nashorn/internal/parser/RegExp.java - src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/RegExp.java + src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/resources/parser.js + test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js + test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java + test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java + test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java + test/src/jdk/nashorn/api/javaaccess/Person.java + test/src/jdk/nashorn/api/javaaccess/SharedObject.java + test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java - test/src/jdk/nashorn/internal/access/BooleanAccessTest.java - test/src/jdk/nashorn/internal/access/MethodAccessTest.java - test/src/jdk/nashorn/internal/access/NumberAccessTest.java - test/src/jdk/nashorn/internal/access/NumberBoxingTest.java - test/src/jdk/nashorn/internal/access/ObjectAccessTest.java - test/src/jdk/nashorn/internal/access/Person.java - test/src/jdk/nashorn/internal/access/SharedObject.java - test/src/jdk/nashorn/internal/access/StringAccessTest.java - test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 774a0f349cc0 Author: hannesw Date: 2013-02-12 13:55 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/774a0f349cc0 8007956: Wrong or obsolete system properties in docs/DEVELOPER_README Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README Changeset: d50e1752f59b Author: attila Date: 2013-02-12 12:47 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d50e1752f59b 8007900: Function binding is inefficient Reviewed-by: jlaskey, lagergren + src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java + test/script/basic/funcbind2.js + test/script/basic/funcbind2.js.EXPECTED + test/script/basic/funcbind3.js + test/script/basic/funcbind3.js.EXPECTED Changeset: a3dc1b180ce7 Author: hannesw Date: 2013-02-13 13:30 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a3dc1b180ce7 8008096: TokenStream buffer should grow exponentially Reviewed-by: attila, lagergren, sundar ! src/jdk/nashorn/internal/parser/TokenStream.java Changeset: 38c44687e4bd Author: sundar Date: 2013-02-13 19:59 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/38c44687e4bd 8008103: Source object should maintain URL of the script source as a private field Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 222b9f32b674 Author: sundar Date: 2013-02-14 09:14 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/222b9f32b674 8008193: test262 tests should be run with security manager enabled Reviewed-by: jlaskey ! make/build.xml Changeset: 8c72a2bec1be Author: sundar Date: 2013-02-14 14:16 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/8c72a2bec1be 8008197: Cross script engine function calls do not work as expected Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8008197.js ! test/script/basic/jquery.js Changeset: 43e32b36153c Author: lagergren Date: 2013-02-14 13:01 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/43e32b36153c 8008199: Lazy compilation and trampoline implementation Summary: The code pipeline now supports lazy compilation, which can be used to only compile certain FunctionNodes and leave others be, saving startup time. When these uncompiled nodes are hit, a trampoline will force them to be recompiled. This can also be used to specialize compilation fixing parameter types and return types to a callsite specific compilation. This will give performance. Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java - src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5a820fb11814 Author: attila Date: 2013-02-14 13:22 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5a820fb11814 8008085: Integrate Dynalink source code into Nashorn codebase Reviewed-by: jlaskey, lagergren, sundar ! THIRD_PARTY_README ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk/internal/dynalink/ChainedCallSite.java + src/jdk/internal/dynalink/DefaultBootstrapper.java + src/jdk/internal/dynalink/DynamicLinker.java + src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/MonomorphicCallSite.java + src/jdk/internal/dynalink/NoSuchDynamicMethodException.java + src/jdk/internal/dynalink/RelinkableCallSite.java + src/jdk/internal/dynalink/beans/AbstractJavaLinker.java + src/jdk/internal/dynalink/beans/AccessibleMembersLookup.java + src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/BeanIntrospector.java + src/jdk/internal/dynalink/beans/BeanLinker.java + src/jdk/internal/dynalink/beans/BeansLinker.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java + src/jdk/internal/dynalink/beans/ClassLinker.java + src/jdk/internal/dynalink/beans/ClassString.java + src/jdk/internal/dynalink/beans/DynamicMethod.java + src/jdk/internal/dynalink/beans/DynamicMethodLinker.java + src/jdk/internal/dynalink/beans/FacetIntrospector.java + src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java + src/jdk/internal/dynalink/beans/MaximallySpecific.java + src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/StaticClass.java + src/jdk/internal/dynalink/beans/StaticClassIntrospector.java + src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/messages.properties + src/jdk/internal/dynalink/beans/package.html + src/jdk/internal/dynalink/linker/ConversionComparator.java + src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk/internal/dynalink/linker/LinkRequest.java + src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/package.html + src/jdk/internal/dynalink/package.html + src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java + src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java + src/jdk/internal/dynalink/support/AutoDiscovery.java + src/jdk/internal/dynalink/support/Backport.java + src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java + src/jdk/internal/dynalink/support/ClassMap.java + src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java + src/jdk/internal/dynalink/support/Guards.java + src/jdk/internal/dynalink/support/LinkRequestImpl.java + src/jdk/internal/dynalink/support/LinkerServicesImpl.java + src/jdk/internal/dynalink/support/Lookup.java + src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java + src/jdk/internal/dynalink/support/NameCodec.java + src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk/internal/dynalink/support/TypeConverterFactory.java + src/jdk/internal/dynalink/support/TypeUtilities.java + src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/messages.properties + src/jdk/internal/dynalink/support/package.html ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! test/script/sandbox/nashorninternals.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: d086c3eead6b Author: lagergren Date: 2013-02-14 13:52 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d086c3eead6b 8008206: The allInteger case for SwitchNode generation in CodeGenerator assumes integer LITERALS only. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8008206.js + test/script/basic/JDK-8008206.js.EXPECTED Changeset: 3df0a0d62d60 Author: attila Date: 2013-02-14 13:51 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3df0a0d62d60 8007990: No access to interface methods on a restricted class Reviewed-by: jlaskey, lagergren, sundar ! make/build.xml + test/script/basic/JDK-8007990.js + test/script/basic/JDK-8007990.js.EXPECTED Changeset: d1ce4e09e4ba Author: hannesw Date: 2013-02-14 14:07 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d1ce4e09e4ba 8008198: java.lang.AssertionError: Invalid break target class jdk.nashorn.internal.ir.TryNode Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008198.js + test/script/basic/JDK-8008198.js.EXPECTED Changeset: d41d7cf9ab8b Author: jlaskey Date: 2013-02-14 11:32 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d41d7cf9ab8b 8008231: Fix build system to accommodate integration of dynalink Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 36065e5ea3d1 Author: hannesw Date: 2013-02-15 09:18 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/36065e5ea3d1 8008215: break in catch clause causes java.lang.VerifyError: Inconsistent stackmap Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008215.js + test/script/basic/JDK-8008215.js.EXPECTED Changeset: e478708faa22 Author: lagergren Date: 2013-02-15 09:44 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e478708faa22 8008239: Unpublicized parts of the code generator package that were only package internal. Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/Condition.java + src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/MapCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java - src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: 757a49aaad02 Author: sundar Date: 2013-02-15 18:30 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/757a49aaad02 8008291: Add more tests for better coverage of objects, scripting and parser packages Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/assign_builtin_func_props.js + test/script/basic/debugger.js + test/script/basic/yield.js ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 5851c5dac260 Author: sundar Date: 2013-02-15 20:40 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5851c5dac260 8008298: Add tests to cover specialized versions of Math functions. Reviewed-by: jlaskey, lagergren + test/script/basic/JDK-8008298.js Changeset: d5f74bd2dc20 Author: sundar Date: 2013-02-18 14:41 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d5f74bd2dc20 8008305: ScriptEngine.eval should offer the ability to provide a codebase Reviewed-by: lagergren, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/URLReader.java + test/script/trusted/JDK-8008305.js + test/script/trusted/JDK-8008305_subtest.js + test/script/trusted/urlreader.js Changeset: 3245e174fe3a Author: hannesw Date: 2013-02-18 10:36 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3245e174fe3a 8008351: Avoid using String.replace(String, String) in codegen Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java Changeset: f8221ce53c2e Author: attila Date: 2013-02-18 16:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f8221ce53c2e 8008371: Fix Dynalink compiler warnings and whitespace Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk/internal/dynalink/support/AutoDiscovery.java ! src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 4738de1bd57f Author: sundar Date: 2013-02-18 20:41 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4738de1bd57f 8008387: Improve code coverage tests for JSObjectLinker and NashornBottomLinker Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/javamethodcallerrors.js + test/script/basic/jsobject.js Changeset: b6798a83dbd4 Author: jlaskey Date: 2013-02-19 09:46 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b6798a83dbd4 8008420: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: b228e3cdbfc3 Author: jlaskey Date: 2013-02-19 09:47 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b228e3cdbfc3 Merge Changeset: b632446ba138 Author: sundar Date: 2013-02-19 20:33 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/b632446ba138 8008448: Add coverage test for jdk.nashorn.internal.ir.debug.JSONWriter Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + test/script/basic/JDK-8008448.js Changeset: 58eea0e8f369 Author: sundar Date: 2013-02-20 17:08 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/58eea0e8f369 8008207: Make constants array and source fields private Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 671852e35ced Author: lagergren Date: 2013-02-20 16:43 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/671852e35ced 8008166: URL handling was broken on windows, causing "load" to malfunction Reviewed-by: attila, jlaskey Contributed-by: klara.ward at oracle.com ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java Changeset: a971adb68f38 Author: lagergren Date: 2013-02-21 16:57 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a971adb68f38 8008648: Lazy JIT scope and callee semantics bugfixes. Broke out wallclock timer. Reviewed-by: attila, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationException.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Timing.java ! test/script/trusted/JDK-8006529.js Changeset: ae1c9716685b Author: jlaskey Date: 2013-02-21 15:24 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ae1c9716685b 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: 678da59a29b3 Author: lagergren Date: 2013-02-22 08:57 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/678da59a29b3 8008554: load was broken for URLs Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8008554.js Changeset: 230a711062c1 Author: lagergren Date: 2013-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/230a711062c1 8008575: Re-integrate code coverage Reviewed-by: attila, hannesw Contributed-by: eugene.drobitko at oracle.com, ilya.dergalin at oracle.com ! make/build.xml + make/code_coverage.xml ! make/project.properties Changeset: 267cc4c85160 Author: lagergren Date: 2013-02-22 12:22 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/267cc4c85160 8007002: Replace implicit exception throwing methods with explicit throws - simplify control flow and remove useless code Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 3f0ff84aaf36 Author: jlaskey Date: 2013-02-22 10:39 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3f0ff84aaf36 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 508da3c7fc3a Author: hannesw Date: 2013-02-22 16:31 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/508da3c7fc3a 8008093: Make RegExp engine pluggable Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java - src/jdk/nashorn/internal/runtime/RegExp.java - src/jdk/nashorn/internal/runtime/RegExpMatch.java - src/jdk/nashorn/internal/runtime/RegExpScanner.java + src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/RegExpMatcher.java + src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java + src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: e42fd1640ff9 Author: hannesw Date: 2013-02-22 17:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e42fd1640ff9 8006028: Integrate Joni regexp engine with Nashorn Reviewed-by: lagergren, attila ! THIRD_PARTY_README ! docs/DEVELOPER_README + src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFold.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFoldArg.java + src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java + src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/Config.java + src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java + src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java + src/jdk/nashorn/internal/runtime/regexp/joni/MatcherFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/MinMaxLen.java + src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/NodeOptInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptAnchorInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptExactInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptMapInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/Option.java + src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + src/jdk/nashorn/internal/runtime/regexp/joni/Region.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java + src/jdk/nashorn/internal/runtime/regexp/joni/Token.java + src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java + src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java + src/jdk/nashorn/internal/runtime/regexp/joni/Warnings.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnchorNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnyCharNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AnchorType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Arguments.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AsmConstants.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCSTATE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCVALTYPE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/EncloseType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/MetaChar.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPSize.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/RegexState.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackPopLevel.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StringType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/SyntaxProperties.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TargetInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TokenType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Traverse.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/CharacterType.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/IntHolder.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/InternalException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/JOniException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/SyntaxException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java Changeset: 7f5b7c6859d7 Author: sundar Date: 2013-02-22 22:39 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/7f5b7c6859d7 8008729: Make sure that we can run basic jsr223 tests using jtreg Reviewed-by: jlaskey, hannesw, lagergren + test/TEST.ROOT ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 5452f82eb2ce Author: jlaskey Date: 2013-02-22 23:33 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5452f82eb2ce 8008776: Revise BuildNashorn.gmk for changes in new build system Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 927fba6785b0 Author: sundar Date: 2013-02-25 16:58 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/927fba6785b0 8008731: Separate configuration environment (options, error/output writer etc.) from Context Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java - src/jdk/nashorn/internal/runtime/OptionsObject.java + src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5610ac25d8ff Author: sundar Date: 2013-02-25 18:13 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5610ac25d8ff 8008789: Enable java access and nashorn runtime tests for jtreg Reviewed-by: lagergren, jlaskey, hannesw ! make/build.xml ! test/TEST.ROOT ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 1654918e0612 Author: attila Date: 2013-02-25 16:51 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1654918e0612 8006984: Introducing local into a function inside with statement confuses its scope Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8006984.js + test/script/basic/JDK-8006984.js.EXPECTED Changeset: a90094ae5be3 Author: sundar Date: 2013-02-26 22:57 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/a90094ae5be3 8009021: nasgen should be run on boot jdk rather than currenly built jdk Reviewed-by: jlaskey ! makefiles/BuildNashorn.gmk Changeset: 1d3dca059b3e Author: alanb Date: 2013-02-27 14:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1d3dca059b3e 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Reviewed-by: chegar, sundar ! makefiles/BuildNashorn.gmk Changeset: 071e859b371e Author: attila Date: 2013-02-27 15:20 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/071e859b371e 8009143: Eliminate Dynalink dependency on java.beans Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java Changeset: 928ea3d8faf0 Author: attila Date: 2013-02-27 15:49 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/928ea3d8faf0 8009146: Eliminate some dead code in preparation for immutable AST Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: 1da9e37697f6 Author: attila Date: 2013-02-27 16:25 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1da9e37697f6 8009150: Previous dead code elimination was incomplete Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/BinaryNode.java Changeset: 1e03be240534 Author: sundar Date: 2013-02-28 20:31 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/1e03be240534 8009229: ant makefile default target should be "test" Reviewed-by: lagergren, jlaskey ! make/build.xml Changeset: 037e1de7ab1a Author: hannesw Date: 2013-02-28 22:59 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/037e1de7ab1a 8009240: RegExpScanner code is inefficient and too complex Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 7e9fbe621d87 Author: sundar Date: 2013-03-01 15:58 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/7e9fbe621d87 8009263: Fix all javadoc errors in nashorn code Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java Changeset: 3b222c90b7de Author: jlaskey Date: 2013-03-02 11:26 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3b222c90b7de Merge Changeset: f90810d79b57 Author: hannesw Date: 2013-03-04 11:44 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/f90810d79b57 8008370: coffee script compiler doesn't work with Nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8008370.js + test/script/basic/JDK-8008370.js.EXPECTED Changeset: fe5211fc3114 Author: jlaskey Date: 2013-03-04 11:01 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/fe5211fc3114 8009379: Remove $ from generated class names Reviewed-by: attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java - src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JO.java - src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/internal/scripts/JS.java Changeset: 3d57f57acd9c Author: sundar Date: 2013-03-06 22:38 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3d57f57acd9c 8009553: Object.create(Array.prototype) doesn't respect reset length Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8009553.js Changeset: 5759f600fcf7 Author: sundar Date: 2013-03-09 21:49 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/5759f600fcf7 8009559: clean up method handle lookup code. Reviewed-by: ahgross, jlaskey, attila, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/java.security.override ! src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java - src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SafeUnreflector.java + src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java + src/jdk/internal/dynalink/beans/SandboxClassLoader.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/sandbox/Unreflector.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/lookup/Lookup.java + src/jdk/nashorn/internal/lookup/MethodHandleFactory.java + src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - src/jdk/nashorn/internal/runtime/linker/Lookup.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/currently-failing/JDK-8006529.js - test/script/trusted/JDK-8006529.js Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags Changeset: fbbdef940138 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/fbbdef940138 Added tag jdk8-b83 for changeset 053d7c55dc82 ! .hgtags Changeset: c54e218333be Author: sundar Date: 2013-03-12 18:12 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/c54e218333be 8009757: Package access clean up and refactoring Reviewed-by: jlaskey, lagergren, attila ! docs/JavaScriptingProgrammersGuide.html ! docs/source/javaarray.js ! make/build.xml ! make/java.security.override ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! test/script/basic/JDK-8008448.js ! test/script/basic/NASHORN-401.js ! test/script/basic/consstring.js ! test/script/basic/fileline.js ! test/script/basic/javainnerclasses.js ! test/script/basic/list.js ! test/script/basic/map.js ! test/script/basic/stdin.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/script/sandbox/reflection.js - test/script/sandbox/reflection.js.EXPECTED ! test/script/sandbox/unsafe.js - test/script/sandbox/unsafe.js.EXPECTED ! test/script/trusted/urlreader.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java + test/src/jdk/nashorn/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/test/models/DessertTopping.java + test/src/jdk/nashorn/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/test/models/FinalClass.java + test/src/jdk/nashorn/test/models/FloorWax.java + test/src/jdk/nashorn/test/models/Nashorn401TestSubject.java + test/src/jdk/nashorn/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/test/models/NonPublicClass.java + test/src/jdk/nashorn/test/models/OuterClass.java + test/src/jdk/nashorn/test/models/OverloadedSam.java + test/src/jdk/nashorn/test/models/OverrideObject.java + test/src/jdk/nashorn/test/models/SourceHelper.java + test/src/jdk/nashorn/test/models/StringArgs.java + test/src/jdk/nashorn/test/models/Toothpaste.java Changeset: e15806b9d716 Author: lagergren Date: 2013-03-12 15:30 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e15806b9d716 8009718: Lazy execution architecture continued - ScriptFunctionData is either final or recompilable. Moved ScriptFunctionData creation logic away from runtime to compile time. Prepared for method generation/specialization. Got rid of ScriptFunctionImplTrampoline whose semantics could be done as part of the relinking anyway. Merge with the lookup package change. Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/CompiledFunction.java + src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java + src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/script/currently-failing/JDK-8006529.js + test/script/currently-failing/clone_ir.js Changeset: 60684aeba89c Author: sundar Date: 2013-03-12 21:17 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/60684aeba89c 8009868: For loop with "true" as condition results in AssertionError in codegen Reviewed-by: jlaskey, hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8009868.js Changeset: 390d44ba90cf Author: lagergren Date: 2013-03-14 14:49 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/390d44ba90cf 8009982: Lazy execution bugfix. Added lazy sunspider unit test. Added mandreel to compile-octane test. Fixed warnings Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/runsunspider-eager.js + test/script/basic/runsunspider-lazy.js ! test/script/basic/runsunspider.js Changeset: d5d80b52cf1c Author: lagergren Date: 2013-03-15 16:07 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/d5d80b52cf1c 8010147: Forgot to add EXPECTED files for lazy and eager sunspider test Reviewed-by: sundar, jlaskey + test/script/basic/runsunspider-eager.js.EXPECTED + test/script/basic/runsunspider-lazy.js.EXPECTED - test/script/basic/runsunspider.js.EXPECTED Changeset: 4daacf8a25ef Author: sundar Date: 2013-03-15 21:52 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4daacf8a25ef 8010145: removed workaround "init.js" in nashorn repo Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/api/scripting/resources/engine.js - src/jdk/nashorn/api/scripting/resources/init.js Changeset: 3b0a0d9d51f0 Author: sundar Date: 2013-03-18 21:03 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/3b0a0d9d51f0 8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing Reviewed-by: lagergren, jlaskey ! bin/jjs ! bin/jjssecure ! bin/nashorn ! bin/nashornsecure ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + test/script/basic/JDK-8010199.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 606a1946e3e2 Author: jlaskey Date: 2013-03-19 11:03 -0300 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/606a1946e3e2 8009969: CodeCoverage should use template Reviewed-by: jlaskey, sundar Contributed-by: pavel.stepanov at oracle.com ! make/build.xml ! make/code_coverage.xml ! make/project.properties Changeset: 4be452026847 Author: attila Date: 2013-03-23 00:58 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/4be452026847 8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java - src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8006755.js ! test/script/basic/NASHORN-837.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java Changeset: ae4ef3102d9c Author: lagergren Date: 2013-03-25 12:01 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ae4ef3102d9c 8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + test/script/basic/JDK-8017010.js + test/script/basic/JDK-8017010.js.EXPECTED ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-258.js.EXPECTED Changeset: 15dac7439921 Author: sundar Date: 2013-03-25 18:20 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/15dac7439921 8010709: org on the top level doesn't resolve Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8010709.js Changeset: 43e40c08e7f8 Author: lagergren Date: 2013-03-26 08:42 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/43e40c08e7f8 8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s Reviewed-by: hannesw, sundar ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: ed60078f0a80 Author: sundar Date: 2013-03-26 18:26 +0530 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/ed60078f0a80 8010720: Linkage problem with java.lang.String.length() Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8010720.js Changeset: db8a33cb22b8 Author: lana Date: 2013-03-26 12:08 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/db8a33cb22b8 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 999cc1bf5520 Author: lana Date: 2013-04-01 21:42 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/999cc1bf5520 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: e0378f0a50da Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/nashorn/rev/e0378f0a50da Added tag jdk8-b84 for changeset 999cc1bf5520 ! .hgtags From david.holmes at oracle.com Tue Apr 9 17:13:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 10:13:49 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51642EF3.1040701@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> Message-ID: <5164AEBD.1070003@oracle.com> Hi Sherman, On 10/04/2013 1:08 AM, Xueming Shen wrote: > On 4/9/13 5:00 AM, David Holmes wrote: >> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >> file or not; if not then it should not be built using CreateJars.gmk >> and shouldn't listed on the JAR variables in profile-includes.txt > > tzdb.dat now is NOT a jar file for performance (decompression slows down > startup). So which gmk file is the best fit for this kind of "file building"? We > may be able to update it to the appropriate place with a follow up push. So given it is no longer a jar file, the target in the CreateJars.gmk $(IMAGES_OUTPUTDIR)/lib/tzdb.dat: $(JDK_OUTPUTDIR)/lib/tzdb.dat $(install-file) should not be needed. The generic copying routine in Images.gmk: # Find all files to copy from $(JDK_OUTPUTDIR)/lib # Jar files are not expected to be here ALL_JDKOUT_LIB_LIST := $(call not-containing,_the.,$(filter-out %.jar,\ $(call CacheFind,$(JDK_OUTPUTDIR)/lib))) should now pick it up by default. David > -Sherman > >> >> David >> >> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>> Hi, >>> >>> JSR 310 has continued to refine and update the java.time API. >>> Please help review the proposed changeset as showed in webrev: >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>> >>> In addition to general javadoc improvements, the changes include: >>> >>> java.time >>> >>> * Duration - added a static from(temporalAmount) method to simplify >>> conversions from other amounts >>> * Renamed the toString(Formatter) method to format(Formatter) in all >>> classes >>> * Period - added a static from(temporalAmount) method to simplify >>> conversions >>> * ZoneId - >>> - Added getAvailableZoneIds method, a simpler mechanism than going >>> to the provider >>> - Added normalized() method to ease conversion to a fixed offset >>> - renamed predefined static fields of timezone names >>> >>> java.time.chrono >>> >>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>> - changed xxx_COMPARATORs to static methods returning the Time Line >>> Order comparators >>> - Added a from(TemporalAcessor) method to ease conversions >>> * Chronology >>> - Added method to create a Date from EpochDay (And in each >>> calendar subclass) >>> - Added resolveDate to allow resolving date components by the >>> Chronology >>> - Serialization fixes >>> - Replaced raw return types with wildcard type >>> * Era >>> - Removed factory methods and getChronology - they did not work >>> correctly in all cases >>> - Declared Era as a functional interface >>> * Hijrah calendar variations - >>> - Supporting the Umm alQura calendar >>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>> making the enums public >>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>> to return the concrete Era type. >>> >>> java.time.format >>> >>> * DateTimeFormatter - >>> - Added fields for the predefined formatters >>> (moved from DateTimeFormatters class) >>> - Updated patterns to be CLDR compatible >>> - Moved documentation for the pattern letters to the class javadoc >>> - Added support for Zone default and conversion >>> * DateTimeFormatterBuilder >>> - Updated documentation of patterns and corresponding equivalents >>> to builder methods. >>> - Added a method to append the localized offset. >>> >>> java.time.temporal >>> >>> * Adjusters - class removed; all static adjusters moved to static >>> methods >>> in TemporalAdjuster >>> * ChronoField - >>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>> - Added getDisplayName - for locale specific field name >>> * Queries - class removed; all static query method moved to static >>> methods >>> in TemporalQuery >>> * TemporalField - added getDisplayName method >>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>> to reflect no support for a unit or field >>> * WeekFields - Added fields for week and year of week-Based-Years to >>> match >>> CLDR fields "Y", "W" > From roger.riggs at oracle.com Wed Apr 10 14:04:22 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 10 Apr 2013 21:04:22 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Removed a poor test that referred to an internal sun.util API preventing a clean test run Message-ID: <20130410210459.1B388481CF@hg.openjdk.java.net> Changeset: ac0d8949bec1 Author: rriggs Date: 2013-04-10 17:03 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ac0d8949bec1 Removed a poor test that referred to an internal sun.util API preventing a clean test run ! test/java/time/test/java/time/temporal/TestChronoField.java From xueming.shen at oracle.com Thu Apr 11 11:40:39 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 11:40:39 -0700 Subject: [threeten-dev] To remove tzdb.dat from CreateJars.gmk Message-ID: <516703A7.9010707@oracle.com> One of the review feedback is to remove the tzdb.dat from the CreateJars.gmk, since it's no longer a "jar" files. While we are still waiting for that "verifier" hotspot fix to get the JSR310 into TL, I'm updating the repo with the changes for the review comment. http://cr.openjdk.java.net/~sherman/jdk8_threeten/b88_feedback/ -sherman From scolebourne at joda.org Thu Apr 11 11:48:37 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 11 Apr 2013 19:48:37 +0100 Subject: [threeten-dev] To remove tzdb.dat from CreateJars.gmk In-Reply-To: <516703A7.9010707@oracle.com> References: <516703A7.9010707@oracle.com> Message-ID: Fine by me. Stephen On 11 April 2013 19:40, Xueming Shen wrote: > > One of the review feedback is to remove the tzdb.dat from the > CreateJars.gmk, > since it's no longer a "jar" files. While we are still waiting for that > "verifier" hotspot > fix to get the JSR310 into TL, I'm updating the repo with the changes for > the > review comment. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/b88_feedback/ > > -sherman From roger.riggs at oracle.com Thu Apr 11 13:30:15 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 11 Apr 2013 16:30:15 -0400 Subject: [threeten-dev] Fix coding conventions of default methods Message-ID: <51671D57.20406@oracle.com> Hi, With a brief window before we can integrate JSR 310 I propose to fix #302: Fix coding conventions of default methods Please review: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-nopublicdefault-302/ If needed the javadoc: javadoc:http://cr.openjdk.java.net/~rriggs/javadoc-nopublicdefault-302/ Thanks, Roger From xueming.shen at oracle.com Thu Apr 11 13:47:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 13:47:01 -0700 Subject: [threeten-dev] Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime Message-ID: <51672145.3080504@oracle.com> Hi As part of the JSR310 Date/Time project, following methods are proposed to be added into java.nio.file.attribute.FileTime to interoperate with the new JSR310 time class Instant. public static FileTime from(Instant instant); public Instant toInstant(); http://cr.openjdk.java.net/~sherman/8011647/webrev Here are some notes regarding the changes. (1) With its design, the FileTime can store the time point on the time-line further in the future and further in the past than the Instant. To be consistent with the spec and implementation of existing to(TimeUnit)/ toMillis(), the proposed toInstant() saturates to the Instant.MIN/MAX when converting from a FileTime object that is beyond the supported time range of Instant (instead of throwing a "conversion failure" exception, such as a DateTimeException). Time points beyond the Instant range are not interesting in practical cases. (2) The internal supporting class DaysAndNanos is replaced by using the threeten Instant class directly. As the direct consequence, the hashCode() for those time points beyond the Instant.MIN/MAX range will be "compromised/saturated" into the hashCode value of Instant.MIN/MAX. As mentioned in (1), since those time points are not the interest of the FileTime class in real world use scenario, so we believe this is an acceptable compromise. The hashCode/equal contract still holds, though the usages of those "extra time points" may trigger worse performance. (3) compareTo() still provides correct ordering for all supported "time points", including those beyond Instant.MIN/MAX range. (4) toString() has been rewritten to use the threeten LocalDateTime class together with the "home-made" formatting code for better performance. Differences of the spec/implementation of FileTime and JSR310 date/time class listed below prevents us from using the new JSR310 formatter to format the FileTime directly. a) FileTime uses "old" ISO8601 version, in which it dis-allows the '0000' for proleptic year 0, while the JSR310 formats "0000" (which is supported in new version of 8601), so the format for all BCE years are different. b) LocalTime formats the "ss" part optionally. It appears to takes the "it is acceptable to omit lower order time elements..." alternative, while the "ss" part is mandated in FileTime toString(), even the second part is 0. c) FileTime formats the "fraction of second" part as "decimal fraction" while LocalTime uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips any tailing zero, but LocalDate does not if it fits into the 3-dit unit. Two addition tests have been used to provide more confidence for the "compatibility" and performance. http://cr.openjdk.java.net/~sherman/8011647/TestFileTime.java http://cr.openjdk.java.net/~sherman/8011647/TestFileTimeBM.java It is also suggested that it might be convenient for FileTime to implement java.time.TemporalAccessor, so the FileTime can be directly formatted by the JSR310 formatter. This is not included in this proposal. I may consider to add this in a later round of update. Thanks, -Sherman From xueming.shen at oracle.com Thu Apr 11 14:01:06 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 11 Apr 2013 21:01:06 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: tzdb.dat makefile update Message-ID: <20130411210153.39FD248220@hg.openjdk.java.net> Changeset: bc3c6f8eb320 Author: sherman Date: 2013-04-11 13:57 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bc3c6f8eb320 tzdb.dat makefile update ! makefiles/CreateJars.gmk ! makefiles/profile-includes.txt ! src/share/classes/java/time/format/ResolverStyle.java From xueming.shen at oracle.com Thu Apr 11 14:21:52 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 14:21:52 -0700 Subject: [threeten-dev] Fix coding conventions of default methods In-Reply-To: <51671D57.20406@oracle.com> References: <51671D57.20406@oracle.com> Message-ID: <51672970.8060804@oracle.com> On 04/11/2013 01:30 PM, roger riggs wrote: > Hi, > > With a brief window before we can integrate JSR 310 I propose to fix > #302: Fix coding conventions of default methods > > Please review: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-nopublicdefault-302/ > > If needed the javadoc: > javadoc:http://cr.openjdk.java.net/~rriggs/javadoc-nopublicdefault-302/ > > Thanks, Roger > Changes look fine. Do we have confirmation that the "static method" should not use "public" as well? -Sherman From xueming.shen at oracle.com Thu Apr 11 16:31:25 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 11 Apr 2013 23:31:25 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix coding conventions of default methods Message-ID: <20130411233154.D367048229@hg.openjdk.java.net> Changeset: 71b630833339 Author: sherman Date: 2013-04-11 16:27 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/71b630833339 Fix coding conventions of default methods ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/TemporalUnit.java From xueming.shen at oracle.com Thu Apr 11 22:46:31 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 22:46:31 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51642EF3.1040701@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> Message-ID: <51679FB7.6050904@oracle.com> David, webrev has been updated to removed the tzdb.dat from the CreateJars.gmk as suggested. http://cr.openjdk.java.net/~sherman/8011172/webrev/ Thanks! -Sherman On 04/09/2013 08:08 AM, Xueming Shen wrote: > On 4/9/13 5:00 AM, David Holmes wrote: >> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar file or not; if not then it should not be built using CreateJars.gmk and shouldn't listed on the JAR variables in profile-includes.txt > > tzdb.dat now is NOT a jar file for performance (decompression slows down startup). > So which gmk file is the best fit for this kind of "file building"? We may be able to > update it to the appropriate place with a follow up push. > > -Sherman > >> >> David >> >> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>> Hi, >>> >>> JSR 310 has continued to refine and update the java.time API. >>> Please help review the proposed changeset as showed in webrev: >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>> >>> In addition to general javadoc improvements, the changes include: >>> >>> java.time >>> >>> * Duration - added a static from(temporalAmount) method to simplify >>> conversions from other amounts >>> * Renamed the toString(Formatter) method to format(Formatter) in all >>> classes >>> * Period - added a static from(temporalAmount) method to simplify >>> conversions >>> * ZoneId - >>> - Added getAvailableZoneIds method, a simpler mechanism than going >>> to the provider >>> - Added normalized() method to ease conversion to a fixed offset >>> - renamed predefined static fields of timezone names >>> >>> java.time.chrono >>> >>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>> - changed xxx_COMPARATORs to static methods returning the Time Line >>> Order comparators >>> - Added a from(TemporalAcessor) method to ease conversions >>> * Chronology >>> - Added method to create a Date from EpochDay (And in each >>> calendar subclass) >>> - Added resolveDate to allow resolving date components by the >>> Chronology >>> - Serialization fixes >>> - Replaced raw return types with wildcard type >>> * Era >>> - Removed factory methods and getChronology - they did not work >>> correctly in all cases >>> - Declared Era as a functional interface >>> * Hijrah calendar variations - >>> - Supporting the Umm alQura calendar >>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>> making the enums public >>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>> to return the concrete Era type. >>> >>> java.time.format >>> >>> * DateTimeFormatter - >>> - Added fields for the predefined formatters >>> (moved from DateTimeFormatters class) >>> - Updated patterns to be CLDR compatible >>> - Moved documentation for the pattern letters to the class javadoc >>> - Added support for Zone default and conversion >>> * DateTimeFormatterBuilder >>> - Updated documentation of patterns and corresponding equivalents >>> to builder methods. >>> - Added a method to append the localized offset. >>> >>> java.time.temporal >>> >>> * Adjusters - class removed; all static adjusters moved to static methods >>> in TemporalAdjuster >>> * ChronoField - >>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>> - Added getDisplayName - for locale specific field name >>> * Queries - class removed; all static query method moved to static methods >>> in TemporalQuery >>> * TemporalField - added getDisplayName method >>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>> to reflect no support for a unit or field >>> * WeekFields - Added fields for week and year of week-Based-Years to match >>> CLDR fields "Y", "W" > From xueming.shen at oracle.com Thu Apr 11 23:27:51 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 23:27:51 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167A23B.3080607@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> Message-ID: <5167A967.9000704@oracle.com> Good catch. webrev updated. It appears none of the tests catched this error, if I just build the jdk normally (?), either local fresh new build and jprt job. http://cr.openjdk.java.net/~sherman/8011172/webrev/ -Sherman. On 4/11/13 10:57 PM, David Holmes wrote: > Hi Sherman, > > On 12/04/2013 3:46 PM, Xueming Shen wrote: >> David, >> >> webrev has been updated to removed the tzdb.dat from the CreateJars.gmk >> as suggested. >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > In profile-includes.txt this change is wrong: > > ** 77,88 **** > security/blacklist \ > security/cacerts \ > security/java.policy \ > security/java.security \ > security/local_policy.jar \ > ! security/trusted.libraries \ > ! tzdb.jar > > PROFILE_1_JRE_OTHER_FILES := \ > COPYRIGHT \ > LICENSE \ > README \ > --- 77,87 ---- > security/blacklist \ > security/cacerts \ > security/java.policy \ > security/java.security \ > security/local_policy.jar \ > ! security/trusted.libraries > > we need tzdb.dat listed here. > > Thanks, > David > >> Thanks! >> -Sherman >> >> On 04/09/2013 08:08 AM, Xueming Shen wrote: >>> On 4/9/13 5:00 AM, David Holmes wrote: >>>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>>> file or not; if not then it should not be built using CreateJars.gmk >>>> and shouldn't listed on the JAR variables in profile-includes.txt >>> >>> tzdb.dat now is NOT a jar file for performance (decompression slows >>> down startup). >>> So which gmk file is the best fit for this kind of "file building"? We >>> may be able to >>> update it to the appropriate place with a follow up push. >>> >>> -Sherman >>> >>>> >>>> David >>>> >>>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> JSR 310 has continued to refine and update the java.time API. >>>>> Please help review the proposed changeset as showed in webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>>> >>>>> In addition to general javadoc improvements, the changes include: >>>>> >>>>> java.time >>>>> >>>>> * Duration - added a static from(temporalAmount) method to simplify >>>>> conversions from other amounts >>>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>>> classes >>>>> * Period - added a static from(temporalAmount) method to simplify >>>>> conversions >>>>> * ZoneId - >>>>> - Added getAvailableZoneIds method, a simpler mechanism than >>>>> going >>>>> to the provider >>>>> - Added normalized() method to ease conversion to a fixed offset >>>>> - renamed predefined static fields of timezone names >>>>> >>>>> java.time.chrono >>>>> >>>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>>> - changed xxx_COMPARATORs to static methods returning the Time >>>>> Line >>>>> Order comparators >>>>> - Added a from(TemporalAcessor) method to ease conversions >>>>> * Chronology >>>>> - Added method to create a Date from EpochDay (And in each >>>>> calendar subclass) >>>>> - Added resolveDate to allow resolving date components by the >>>>> Chronology >>>>> - Serialization fixes >>>>> - Replaced raw return types with wildcard type >>>>> * Era >>>>> - Removed factory methods and getChronology - they did not work >>>>> correctly in all cases >>>>> - Declared Era as a functional interface >>>>> * Hijrah calendar variations - >>>>> - Supporting the Umm alQura calendar >>>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>>> making the enums public >>>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>>> to return the concrete Era type. >>>>> >>>>> java.time.format >>>>> >>>>> * DateTimeFormatter - >>>>> - Added fields for the predefined formatters >>>>> (moved from DateTimeFormatters class) >>>>> - Updated patterns to be CLDR compatible >>>>> - Moved documentation for the pattern letters to the class >>>>> javadoc >>>>> - Added support for Zone default and conversion >>>>> * DateTimeFormatterBuilder >>>>> - Updated documentation of patterns and corresponding >>>>> equivalents >>>>> to builder methods. >>>>> - Added a method to append the localized offset. >>>>> >>>>> java.time.temporal >>>>> >>>>> * Adjusters - class removed; all static adjusters moved to static >>>>> methods >>>>> in TemporalAdjuster >>>>> * ChronoField - >>>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>>> - Added getDisplayName - for locale specific field name >>>>> * Queries - class removed; all static query method moved to static >>>>> methods >>>>> in TemporalQuery >>>>> * TemporalField - added getDisplayName method >>>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>>> to reflect no support for a unit or field >>>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>>> match >>>>> CLDR fields "Y", "W" >>> >> From Alan.Bateman at oracle.com Fri Apr 12 05:55:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 13:55:36 +0100 Subject: [threeten-dev] Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51672145.3080504@oracle.com> References: <51672145.3080504@oracle.com> Message-ID: <51680448.6020303@oracle.com> On 11/04/2013 21:47, Xueming Shen wrote: > Hi > > As part of the JSR310 Date/Time project, following methods are proposed > to be added into java.nio.file.attribute.FileTime to interoperate with > the > new JSR310 time class Instant. > > public static FileTime from(Instant instant); > public Instant toInstant(); > > http://cr.openjdk.java.net/~sherman/8011647/webrev Sherman and I chatted about adding from(Instant)/toInstant() a few times over the last week so most of my comments are already included. Overall I think it has worked out well, just unfortunate that there is a bit of extra complexity because FileTime supports a wider time-line and we also went with the XML schema deviation from (older?) ISO 8601 for year 0000. In practical terms these aren't of course interesting for file times. In terms of API then from(Instant)/toInstant() are simple and I don't think we have an urgent need for FileTimes to be directly formatted. On toString then FileTime doesn't require that trailing zeros be stripped from the fraction of a second. If it is better to use 3-digit units that it is okay. Also if this is something that we got wrong in FileTime then we could change the spec without any compatibility impact. Values outside of MIN/MAX aren't too interesting so hashCode using Instant hashCode should be fine. I had to read compareTo a few times to convince myself that it correctly orders FileTimes where one is created from an Instant and the other from a value outside of MIN/MAX. It might be useful to expand the comment to explain this further. Thanks for expanding the existing test. A minor point at line 117 is that you don't need "Random r" as there is rand already. The pre-existing tests loop over TimeUnit.values() rather than EnumSet.allOf(TimeUnit.class). In eqTime then it prints to System.out where the rest of the test prints to System.err before throwing the exception. That's all I have. -Alan From david.holmes at oracle.com Thu Apr 11 22:57:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2013 15:57:15 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51679FB7.6050904@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> Message-ID: <5167A23B.3080607@oracle.com> Hi Sherman, On 12/04/2013 3:46 PM, Xueming Shen wrote: > David, > > webrev has been updated to removed the tzdb.dat from the CreateJars.gmk > as suggested. > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ In profile-includes.txt this change is wrong: ** 77,88 **** security/blacklist \ security/cacerts \ security/java.policy \ security/java.security \ security/local_policy.jar \ ! security/trusted.libraries \ ! tzdb.jar PROFILE_1_JRE_OTHER_FILES := \ COPYRIGHT \ LICENSE \ README \ --- 77,87 ---- security/blacklist \ security/cacerts \ security/java.policy \ security/java.security \ security/local_policy.jar \ ! security/trusted.libraries we need tzdb.dat listed here. Thanks, David > Thanks! > -Sherman > > On 04/09/2013 08:08 AM, Xueming Shen wrote: >> On 4/9/13 5:00 AM, David Holmes wrote: >>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>> file or not; if not then it should not be built using CreateJars.gmk >>> and shouldn't listed on the JAR variables in profile-includes.txt >> >> tzdb.dat now is NOT a jar file for performance (decompression slows >> down startup). >> So which gmk file is the best fit for this kind of "file building"? We >> may be able to >> update it to the appropriate place with a follow up push. >> >> -Sherman >> >>> >>> David >>> >>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>> Hi, >>>> >>>> JSR 310 has continued to refine and update the java.time API. >>>> Please help review the proposed changeset as showed in webrev: >>>> >>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>> >>>> In addition to general javadoc improvements, the changes include: >>>> >>>> java.time >>>> >>>> * Duration - added a static from(temporalAmount) method to simplify >>>> conversions from other amounts >>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>> classes >>>> * Period - added a static from(temporalAmount) method to simplify >>>> conversions >>>> * ZoneId - >>>> - Added getAvailableZoneIds method, a simpler mechanism than going >>>> to the provider >>>> - Added normalized() method to ease conversion to a fixed offset >>>> - renamed predefined static fields of timezone names >>>> >>>> java.time.chrono >>>> >>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>> - changed xxx_COMPARATORs to static methods returning the Time Line >>>> Order comparators >>>> - Added a from(TemporalAcessor) method to ease conversions >>>> * Chronology >>>> - Added method to create a Date from EpochDay (And in each >>>> calendar subclass) >>>> - Added resolveDate to allow resolving date components by the >>>> Chronology >>>> - Serialization fixes >>>> - Replaced raw return types with wildcard type >>>> * Era >>>> - Removed factory methods and getChronology - they did not work >>>> correctly in all cases >>>> - Declared Era as a functional interface >>>> * Hijrah calendar variations - >>>> - Supporting the Umm alQura calendar >>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>> making the enums public >>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>> to return the concrete Era type. >>>> >>>> java.time.format >>>> >>>> * DateTimeFormatter - >>>> - Added fields for the predefined formatters >>>> (moved from DateTimeFormatters class) >>>> - Updated patterns to be CLDR compatible >>>> - Moved documentation for the pattern letters to the class javadoc >>>> - Added support for Zone default and conversion >>>> * DateTimeFormatterBuilder >>>> - Updated documentation of patterns and corresponding equivalents >>>> to builder methods. >>>> - Added a method to append the localized offset. >>>> >>>> java.time.temporal >>>> >>>> * Adjusters - class removed; all static adjusters moved to static >>>> methods >>>> in TemporalAdjuster >>>> * ChronoField - >>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>> - Added getDisplayName - for locale specific field name >>>> * Queries - class removed; all static query method moved to static >>>> methods >>>> in TemporalQuery >>>> * TemporalField - added getDisplayName method >>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>> to reflect no support for a unit or field >>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>> match >>>> CLDR fields "Y", "W" >> > From david.holmes at oracle.com Fri Apr 12 00:09:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2013 17:09:54 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167A967.9000704@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> Message-ID: <5167B342.3050305@oracle.com> On 12/04/2013 4:27 PM, Xueming Shen wrote: > Good catch. webrev updated. It appears none of the tests catched this > error, if I just build the > jdk normally (?), either local fresh new build and jprt job. > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ A "profiles" build would have been affected by it. David > -Sherman. > > On 4/11/13 10:57 PM, David Holmes wrote: >> Hi Sherman, >> >> On 12/04/2013 3:46 PM, Xueming Shen wrote: >>> David, >>> >>> webrev has been updated to removed the tzdb.dat from the CreateJars.gmk >>> as suggested. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> In profile-includes.txt this change is wrong: >> >> ** 77,88 **** >> security/blacklist \ >> security/cacerts \ >> security/java.policy \ >> security/java.security \ >> security/local_policy.jar \ >> ! security/trusted.libraries \ >> ! tzdb.jar >> >> PROFILE_1_JRE_OTHER_FILES := \ >> COPYRIGHT \ >> LICENSE \ >> README \ >> --- 77,87 ---- >> security/blacklist \ >> security/cacerts \ >> security/java.policy \ >> security/java.security \ >> security/local_policy.jar \ >> ! security/trusted.libraries >> >> we need tzdb.dat listed here. >> >> Thanks, >> David >> >>> Thanks! >>> -Sherman >>> >>> On 04/09/2013 08:08 AM, Xueming Shen wrote: >>>> On 4/9/13 5:00 AM, David Holmes wrote: >>>>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>>>> file or not; if not then it should not be built using CreateJars.gmk >>>>> and shouldn't listed on the JAR variables in profile-includes.txt >>>> >>>> tzdb.dat now is NOT a jar file for performance (decompression slows >>>> down startup). >>>> So which gmk file is the best fit for this kind of "file building"? We >>>> may be able to >>>> update it to the appropriate place with a follow up push. >>>> >>>> -Sherman >>>> >>>>> >>>>> David >>>>> >>>>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>>>> Hi, >>>>>> >>>>>> JSR 310 has continued to refine and update the java.time API. >>>>>> Please help review the proposed changeset as showed in webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>>>> >>>>>> In addition to general javadoc improvements, the changes include: >>>>>> >>>>>> java.time >>>>>> >>>>>> * Duration - added a static from(temporalAmount) method to simplify >>>>>> conversions from other amounts >>>>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>>>> classes >>>>>> * Period - added a static from(temporalAmount) method to simplify >>>>>> conversions >>>>>> * ZoneId - >>>>>> - Added getAvailableZoneIds method, a simpler mechanism than >>>>>> going >>>>>> to the provider >>>>>> - Added normalized() method to ease conversion to a fixed offset >>>>>> - renamed predefined static fields of timezone names >>>>>> >>>>>> java.time.chrono >>>>>> >>>>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>>>> - changed xxx_COMPARATORs to static methods returning the Time >>>>>> Line >>>>>> Order comparators >>>>>> - Added a from(TemporalAcessor) method to ease conversions >>>>>> * Chronology >>>>>> - Added method to create a Date from EpochDay (And in each >>>>>> calendar subclass) >>>>>> - Added resolveDate to allow resolving date components by the >>>>>> Chronology >>>>>> - Serialization fixes >>>>>> - Replaced raw return types with wildcard type >>>>>> * Era >>>>>> - Removed factory methods and getChronology - they did not work >>>>>> correctly in all cases >>>>>> - Declared Era as a functional interface >>>>>> * Hijrah calendar variations - >>>>>> - Supporting the Umm alQura calendar >>>>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>>>> making the enums public >>>>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>>>> to return the concrete Era type. >>>>>> >>>>>> java.time.format >>>>>> >>>>>> * DateTimeFormatter - >>>>>> - Added fields for the predefined formatters >>>>>> (moved from DateTimeFormatters class) >>>>>> - Updated patterns to be CLDR compatible >>>>>> - Moved documentation for the pattern letters to the class >>>>>> javadoc >>>>>> - Added support for Zone default and conversion >>>>>> * DateTimeFormatterBuilder >>>>>> - Updated documentation of patterns and corresponding >>>>>> equivalents >>>>>> to builder methods. >>>>>> - Added a method to append the localized offset. >>>>>> >>>>>> java.time.temporal >>>>>> >>>>>> * Adjusters - class removed; all static adjusters moved to static >>>>>> methods >>>>>> in TemporalAdjuster >>>>>> * ChronoField - >>>>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>>>> - Added getDisplayName - for locale specific field name >>>>>> * Queries - class removed; all static query method moved to static >>>>>> methods >>>>>> in TemporalQuery >>>>>> * TemporalField - added getDisplayName method >>>>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>>>> to reflect no support for a unit or field >>>>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>>>> match >>>>>> CLDR fields "Y", "W" >>>> >>> > From xueming.shen at oracle.com Fri Apr 12 08:22:22 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 08:22:22 -0700 Subject: [threeten-dev] FWD: [JBS] (JDK-8011172) CCC request to Update the OpenJDK Threeten Project in SE 8 Message-ID: <516826AE.9080302@oracle.com> Hi, The latest JSR310 update has been pushed into TL repo. We missed the 4/9 (this Tuesday) PIT deadline for b86 (because of that hotspot interface static method regression), so the bits will be sitting in TL for b88, probably will be pit-ed on 4/23 and get into master jdk8 repo around 4/26. The threeten-repo is open for further update. We may/should be able to do another round of update/integration for the b88 if there is any. And we may have another update chance (May 9th) after the 4/23 one. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4d50e8cc9e2 -Sherman From Alan.Bateman at oracle.com Fri Apr 12 08:46:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 16:46:44 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167B342.3050305@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> Message-ID: <51682C64.7080600@oracle.com> On 12/04/2013 08:09, David Holmes wrote: > On 12/04/2013 4:27 PM, Xueming Shen wrote: >> Good catch. webrev updated. It appears none of the tests catched this >> error, if I just build the >> jdk normally (?), either local fresh new build and jprt job. >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > A "profiles" build would have been affected by it. > > David Speaking of, hijrah-config-umalqura.properties will need to be added to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it gets copied into the profile images. Sorry I didn't spot thing until now. -Alan From xueming.shen at oracle.com Fri Apr 12 09:04:04 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 09:04:04 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51682C64.7080600@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> Message-ID: <51683074.5020502@oracle.com> Will add in a separate push/update. On 4/12/13 8:46 AM, Alan Bateman wrote: > On 12/04/2013 08:09, David Holmes wrote: >> On 12/04/2013 4:27 PM, Xueming Shen wrote: >>> Good catch. webrev updated. It appears none of the tests catched this >>> error, if I just build the >>> jdk normally (?), either local fresh new build and jprt job. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> A "profiles" build would have been affected by it. >> >> David > Speaking of, hijrah-config-umalqura.properties will need to be added > to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it > gets copied into the profile images. Sorry I didn't spot thing until now. > > -Alan From Alan.Bateman at oracle.com Fri Apr 12 09:17:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 17:17:47 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51683074.5020502@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> <51683074.5020502@oracle.com> Message-ID: <516833AB.1090506@oracle.com> On 12/04/2013 17:04, Xueming Shen wrote: > Will add in a separate push/update. I just checked it and the HijrahChronology fails to initialized as expected on profile builds. The attached sorts it out. -Alan. diff -r f4d50e8cc9e2 makefiles/profile-includes.txt --- a/makefiles/profile-includes.txt Fri Apr 12 07:57:35 2013 -0700 +++ b/makefiles/profile-includes.txt Fri Apr 12 17:04:10 2013 +0100 @@ -66,6 +66,7 @@ ext/sunec.jar \ ext/sunjce_provider.jar \ ext/sunpkcs11.jar \ + hijrah-config-umalqura.properties \ jce.jar \ jsse.jar \ logging.properties \ From xueming.shen at oracle.com Fri Apr 12 09:17:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 09:17:08 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51682C64.7080600@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> Message-ID: <51683384.5050401@oracle.com> Alan, please help review. http://cr.openjdk.java.net/~sherman/8012123/webrev/ -Sherman On 4/12/13 8:46 AM, Alan Bateman wrote: > On 12/04/2013 08:09, David Holmes wrote: >> On 12/04/2013 4:27 PM, Xueming Shen wrote: >>> Good catch. webrev updated. It appears none of the tests catched this >>> error, if I just build the >>> jdk normally (?), either local fresh new build and jprt job. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> A "profiles" build would have been affected by it. >> >> David > Speaking of, hijrah-config-umalqura.properties will need to be added > to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it > gets copied into the profile images. Sorry I didn't spot thing until now. > > -Alan From Alan.Bateman at oracle.com Fri Apr 12 09:19:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 17:19:34 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51683384.5050401@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> <51683384.5050401@oracle.com> Message-ID: <51683416.9090503@oracle.com> On 12/04/2013 17:17, Xueming Shen wrote: > Alan, please help review. > > http://cr.openjdk.java.net/~sherman/8012123/webrev/ > > -Sherman Looks good. -Alan From xueming.shen at oracle.com Fri Apr 12 10:28:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 10:28:45 -0700 Subject: [threeten-dev] Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51680448.6020303@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> Message-ID: <5168444D.10003@oracle.com> On 04/12/2013 05:55 AM, Alan Bateman wrote: > Sherman and I chatted about adding from(Instant)/toInstant() a few times over the last week so most of my comments are already included. > > Overall I think it has worked out well, just unfortunate that there is a bit of extra complexity because FileTime supports a wider time-line and we also went with the XML schema deviation from (older?) ISO 8601 for year 0000. In practical terms these aren't of course interesting for file times. > > In terms of API then from(Instant)/toInstant() are simple and I don't think we have an urgent need for FileTimes to be directly formatted. > > On toString then FileTime doesn't require that trailing zeros be stripped from the fraction of a second. If it is better to use 3-digit units that it is okay. Also if this is something that we got wrong in FileTime then we could change the spec without any compatibility impact. I'm not sure if the 3-digit unit fitting is "better" or not. But xml spec cited in the toString() API specifies that the "trailing zeros are optional" in its 3.2.3.1 "lexical representatin" section and "trailing zeros are prohibited..." in 3.2.3.2 "canonical representation" section. So I think trimming trailing zeros in FileTime.toString() is just fine. http://www.w3.org/TR/xmlschema-2/#deviantformats > > Values outside of MIN/MAX aren't too interesting so hashCode using Instant hashCode should be fine. I had to read compareTo a few times to convince myself that it correctly orders FileTimes where one is created from an Instant and the other from a value outside of MIN/MAX. It might be useful to expand the comment to explain this further. Added some wording. > > Thanks for expanding the existing test. A minor point at line 117 is that you don't need "Random r" as there is rand already. The pre-existing tests loop over TimeUnit.values() rather than EnumSet.allOf(TimeUnit.class). In eqTime then it prints to System.out where the rest of the test prints to System.err before throwing the exception. > Updated. http://cr.openjdk.java.net/~sherman/8011647/webrev/ Thanks! -Sherman From Alan.Bateman at oracle.com Fri Apr 12 11:10:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 19:10:44 +0100 Subject: [threeten-dev] Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <5168444D.10003@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> <5168444D.10003@oracle.com> Message-ID: <51684E24.2090405@oracle.com> On 12/04/2013 18:28, Xueming Shen wrote: > > I'm not sure if the 3-digit unit fitting is "better" or not. But xml > spec cited in the > toString() API specifies that the "trailing zeros are optional" in its > 3.2.3.1 "lexical > representatin" section and "trailing zeros are prohibited..." in > 3.2.3.2 "canonical > representation" section. So I think trimming trailing zeros in > FileTime.toString() > is just fine. The deviation and reference to the XML scheme spec was intended to be deal with the issues of year 0000 and > 9999. I'm happy with dropping the trailing zeros, I just wasn't sure if you suggesting that it would have been better to use 3-digit unit that allow trailing zeros. > : > Updated. > > http://cr.openjdk.java.net/~sherman/8011647/webrev/ > Looks fine. The eqTime method is still printing to System.out in the test but it's not a big deal. -Alan From xueming.shen at oracle.com Fri Apr 12 11:16:27 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 11:16:27 -0700 Subject: [threeten-dev] Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51684E24.2090405@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> <5168444D.10003@oracle.com> <51684E24.2090405@oracle.com> Message-ID: <51684F7B.7000308@oracle.com> On 04/12/2013 11:10 AM, Alan Bateman wrote: > On 12/04/2013 18:28, Xueming Shen wrote: >> >> I'm not sure if the 3-digit unit fitting is "better" or not. But xml spec cited in the >> toString() API specifies that the "trailing zeros are optional" in its 3.2.3.1 "lexical >> representatin" section and "trailing zeros are prohibited..." in 3.2.3.2 "canonical >> representation" section. So I think trimming trailing zeros in FileTime.toString() >> is just fine. > The deviation and reference to the XML scheme spec was intended to be deal with the issues of year 0000 and > 9999. I'm happy with dropping the trailing zeros, I just wasn't sure if you suggesting that it would have been better to use 3-digit unit that allow trailing zeros. > > >> : >> Updated. >> >> http://cr.openjdk.java.net/~sherman/8011647/webrev/ >> > Looks fine. The eqTime method is still printing to System.out in the test but it's not a big deal. > http://cr.openjdk.java.net/~sherman/8011647/webrev/ Missed this one. Updated. I think we are good to go. Thanks! -Sherman From xueming.shen at oracle.com Fri Apr 12 12:27:26 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 12 Apr 2013 19:27:26 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Synced the changes/updates for TL integration Message-ID: <20130412192807.DEAAC48296@hg.openjdk.java.net> Changeset: 96815bfd0d13 Author: sherman Date: 2013-04-12 12:24 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/96815bfd0d13 Synced the changes/updates for TL integration ! makefiles/profile-includes.txt ! src/share/classes/java/nio/file/attribute/FileTime.java ! test/java/nio/file/attribute/FileTime/Basic.java From roger.riggs at oracle.com Fri Apr 12 14:38:37 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 12 Apr 2013 17:38:37 -0400 Subject: [threeten-dev] DateTimeFormatSymbols review Message-ID: <51687EDD.4030703@oracle.com> Hi, Following up on issue #114 Determine if DateTimeFormatSymbols provides correct localization In the attempt to disambiguate the class name it has become very long. Perhaps instead of DateTimeDecimalFormatSymbols it could be simply 'DecimalSymbols'. Many of the other classes have similarly long names that are unwieldy to use. The Webrev is: http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ Thanks, Roger From scolebourne at joda.org Sat Apr 13 02:05:40 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 13 Apr 2013 10:05:40 +0100 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: <51687EDD.4030703@oracle.com> References: <51687EDD.4030703@oracle.com> Message-ID: On 12 April 2013 22:38, roger riggs wrote: > Following up on issue #114 Determine if DateTimeFormatSymbols provides > correct localization > In the attempt to disambiguate the class name it has become very long. > > Perhaps instead of DateTimeDecimalFormatSymbols it could be simply > 'DecimalSymbols'. Many of the other classes have similarly long names that > are unwieldy to use. Other controlling elements in the package end in "Style". Maybe this should be DecimalStyle. Stephen From roger.riggs at oracle.com Mon Apr 15 09:25:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 15 Apr 2013 12:25:51 -0400 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: References: <51687EDD.4030703@oracle.com> Message-ID: <516C2A0F.1020008@oracle.com> Hi, The name DecimalStyle would be consistent with the other styling types and is conveniently short. Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; I remember a comment against using array returns. Thanks, Roger On 4/13/2013 5:05 AM, Stephen Colebourne wrote: > On 12 April 2013 22:38, roger riggs wrote: >> Following up on issue #114 Determine if DateTimeFormatSymbols provides >> correct localization >> In the attempt to disambiguate the class name it has become very long. >> >> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >> 'DecimalSymbols'. Many of the other classes have similarly long names that >> are unwieldy to use. > Other controlling elements in the package end in "Style". Maybe this > should be DecimalStyle. > > Stephen From scolebourne at joda.org Mon Apr 15 09:36:30 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 15 Apr 2013 17:36:30 +0100 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: <516C2A0F.1020008@oracle.com> References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> Message-ID: We're agreed on the name. The methods currently named getSymbols() should also be altered. I guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter DTPrintContext, DTParseContext. The Locale[] method should not return an array as you say. Should be Set to fit with Chronology and ZoneId. thanks Stephen On 15 April 2013 17:25, roger riggs wrote: > Hi, > > The name DecimalStyle would be consistent with the other > styling types and is conveniently short. > > Updated webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ > > BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; > I remember a comment against using array returns. > > Thanks, Roger > > > > > On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >> >> On 12 April 2013 22:38, roger riggs wrote: >>> >>> Following up on issue #114 Determine if DateTimeFormatSymbols provides >>> correct localization >>> In the attempt to disambiguate the class name it has become very long. >>> >>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>> 'DecimalSymbols'. Many of the other classes have similarly long names >>> that >>> are unwieldy to use. >> >> Other controlling elements in the package end in "Style". Maybe this >> should be DecimalStyle. >> >> Stephen > > From roger.riggs at oracle.com Mon Apr 15 11:28:35 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 15 Apr 2013 14:28:35 -0400 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> Message-ID: <516C46D3.60702@oracle.com> Hi, Updates method names as suggested, edited javadoc to replace or qualify use of 'symbols' with DecimalStyle. Changed the return type of DecimalStyle.getAvailableLocales() to Set. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ Roger On 4/15/2013 12:36 PM, Stephen Colebourne wrote: > We're agreed on the name. > > The methods currently named getSymbols() should also be altered. I > guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter > DTPrintContext, DTParseContext. > > The Locale[] method should not return an array as you say. Should be > Set to fit with Chronology and ZoneId. > > thanks > Stephen > > > On 15 April 2013 17:25, roger riggs wrote: >> Hi, >> >> The name DecimalStyle would be consistent with the other >> styling types and is conveniently short. >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >> >> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >> I remember a comment against using array returns. >> >> Thanks, Roger >> >> >> >> >> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>> On 12 April 2013 22:38, roger riggs wrote: >>>> Following up on issue #114 Determine if DateTimeFormatSymbols provides >>>> correct localization >>>> In the attempt to disambiguate the class name it has become very long. >>>> >>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>> 'DecimalSymbols'. Many of the other classes have similarly long names >>>> that >>>> are unwieldy to use. >>> Other controlling elements in the package end in "Style". Maybe this >>> should be DecimalStyle. >>> >>> Stephen >> From scolebourne at joda.org Mon Apr 15 11:33:55 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 15 Apr 2013 19:33:55 +0100 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: <516C46D3.60702@oracle.com> References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> <516C46D3.60702@oracle.com> Message-ID: Looks good to me Stephen On 15 April 2013 19:28, roger riggs wrote: > Hi, > > Updates method names as suggested, edited javadoc to replace > or qualify use of 'symbols' with DecimalStyle. > Changed the return type of DecimalStyle.getAvailableLocales() to > Set. > > Webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ > > Roger > > > On 4/15/2013 12:36 PM, Stephen Colebourne wrote: >> >> We're agreed on the name. >> >> The methods currently named getSymbols() should also be altered. I >> guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter >> DTPrintContext, DTParseContext. >> >> The Locale[] method should not return an array as you say. Should be >> Set to fit with Chronology and ZoneId. >> >> thanks >> Stephen >> >> >> On 15 April 2013 17:25, roger riggs wrote: >>> >>> Hi, >>> >>> The name DecimalStyle would be consistent with the other >>> styling types and is conveniently short. >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>> >>> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >>> I remember a comment against using array returns. >>> >>> Thanks, Roger >>> >>> >>> >>> >>> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>>> >>>> On 12 April 2013 22:38, roger riggs wrote: >>>>> >>>>> Following up on issue #114 Determine if DateTimeFormatSymbols provides >>>>> correct localization >>>>> In the attempt to disambiguate the class name it has become very long. >>>>> >>>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>>> 'DecimalSymbols'. Many of the other classes have similarly long names >>>>> that >>>>> are unwieldy to use. >>>> >>>> Other controlling elements in the package end in "Style". Maybe this >>>> should be DecimalStyle. >>>> >>>> Stephen >>> >>> > From xueming.shen at oracle.com Mon Apr 15 11:44:58 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 15 Apr 2013 11:44:58 -0700 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> <516C46D3.60702@oracle.com> Message-ID: <516C4AAA.6020607@oracle.com> How do you guys want to handle the 4/23 TL integration? To have a 4/20 or 4/21 as the cut off for all changes in Threeten repo? All changes should be able to make into b88. And we should have another slot around May 9 as the "final". -Sherman On 4/15/13 11:33 AM, Stephen Colebourne wrote: > Looks good to me > Stephen > > On 15 April 2013 19:28, roger riggs wrote: >> Hi, >> >> Updates method names as suggested, edited javadoc to replace >> or qualify use of 'symbols' with DecimalStyle. >> Changed the return type of DecimalStyle.getAvailableLocales() to >> Set. >> >> Webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >> >> Roger >> >> >> On 4/15/2013 12:36 PM, Stephen Colebourne wrote: >>> We're agreed on the name. >>> >>> The methods currently named getSymbols() should also be altered. I >>> guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter >>> DTPrintContext, DTParseContext. >>> >>> The Locale[] method should not return an array as you say. Should be >>> Set to fit with Chronology and ZoneId. >>> >>> thanks >>> Stephen >>> >>> >>> On 15 April 2013 17:25, roger riggs wrote: >>>> Hi, >>>> >>>> The name DecimalStyle would be consistent with the other >>>> styling types and is conveniently short. >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>>> >>>> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >>>> I remember a comment against using array returns. >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> >>>> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>>>> On 12 April 2013 22:38, roger riggs wrote: >>>>>> Following up on issue #114 Determine if DateTimeFormatSymbols provides >>>>>> correct localization >>>>>> In the attempt to disambiguate the class name it has become very long. >>>>>> >>>>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>>>> 'DecimalSymbols'. Many of the other classes have similarly long names >>>>>> that >>>>>> are unwieldy to use. >>>>> Other controlling elements in the package end in "Style". Maybe this >>>>> should be DecimalStyle. >>>>> >>>>> Stephen >>>> From roger.riggs at oracle.com Mon Apr 15 11:50:43 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 15 Apr 2013 14:50:43 -0400 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: <516C4AAA.6020607@oracle.com> References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> <516C46D3.60702@oracle.com> <516C4AAA.6020607@oracle.com> Message-ID: <516C4C03.8050105@oracle.com> Any API changes should go through the usual review so I'm not sure a Saturday cutoff is enough time though the number of changes should be much smaller than before. The alternative is to just go with what is already in TL for B88 and start accumulating changes for the week before May 9. Roger On 4/15/2013 2:44 PM, Xueming Shen wrote: > How do you guys want to handle the 4/23 TL integration? To have a 4/20 > or 4/21 as the cut off > for all changes in Threeten repo? All changes should be able to make > into b88. And we should > have another slot around May 9 as the "final". > > -Sherman > > > On 4/15/13 11:33 AM, Stephen Colebourne wrote: >> Looks good to me >> Stephen >> >> On 15 April 2013 19:28, roger riggs wrote: >>> Hi, >>> >>> Updates method names as suggested, edited javadoc to replace >>> or qualify use of 'symbols' with DecimalStyle. >>> Changed the return type of DecimalStyle.getAvailableLocales() to >>> Set. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>> >>> Roger >>> >>> >>> On 4/15/2013 12:36 PM, Stephen Colebourne wrote: >>>> We're agreed on the name. >>>> >>>> The methods currently named getSymbols() should also be altered. I >>>> guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter >>>> DTPrintContext, DTParseContext. >>>> >>>> The Locale[] method should not return an array as you say. Should be >>>> Set to fit with Chronology and ZoneId. >>>> >>>> thanks >>>> Stephen >>>> >>>> >>>> On 15 April 2013 17:25, roger riggs wrote: >>>>> Hi, >>>>> >>>>> The name DecimalStyle would be consistent with the other >>>>> styling types and is conveniently short. >>>>> >>>>> Updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>>>> >>>>> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >>>>> I remember a comment against using array returns. >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> >>>>> >>>>> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>>>>> On 12 April 2013 22:38, roger riggs wrote: >>>>>>> Following up on issue #114 Determine if DateTimeFormatSymbols >>>>>>> provides >>>>>>> correct localization >>>>>>> In the attempt to disambiguate the class name it has become very >>>>>>> long. >>>>>>> >>>>>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>>>>> 'DecimalSymbols'. Many of the other classes have similarly long >>>>>>> names >>>>>>> that >>>>>>> are unwieldy to use. >>>>>> Other controlling elements in the package end in "Style". Maybe this >>>>>> should be DecimalStyle. >>>>>> >>>>>> Stephen >>>>> > From scolebourne at joda.org Mon Apr 15 11:59:17 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 15 Apr 2013 19:59:17 +0100 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: <516C4AAA.6020607@oracle.com> References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> <516C46D3.60702@oracle.com> <516C4AAA.6020607@oracle.com> Message-ID: Are you indicating that there will be no more changes after May 9th at all? I still don't see how Project Lambda is anywhere near meeting a date like that... Stephen On 15 April 2013 19:44, Xueming Shen wrote: > How do you guys want to handle the 4/23 TL integration? To have a 4/20 or > 4/21 as the cut off > for all changes in Threeten repo? All changes should be able to make into > b88. And we should > have another slot around May 9 as the "final". > > -Sherman > > > > On 4/15/13 11:33 AM, Stephen Colebourne wrote: >> >> Looks good to me >> Stephen >> >> On 15 April 2013 19:28, roger riggs wrote: >>> >>> Hi, >>> >>> Updates method names as suggested, edited javadoc to replace >>> or qualify use of 'symbols' with DecimalStyle. >>> Changed the return type of DecimalStyle.getAvailableLocales() to >>> Set. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>> >>> Roger >>> >>> >>> On 4/15/2013 12:36 PM, Stephen Colebourne wrote: >>>> >>>> We're agreed on the name. >>>> >>>> The methods currently named getSymbols() should also be altered. I >>>> guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter >>>> DTPrintContext, DTParseContext. >>>> >>>> The Locale[] method should not return an array as you say. Should be >>>> Set to fit with Chronology and ZoneId. >>>> >>>> thanks >>>> Stephen >>>> >>>> >>>> On 15 April 2013 17:25, roger riggs wrote: >>>>> >>>>> Hi, >>>>> >>>>> The name DecimalStyle would be consistent with the other >>>>> styling types and is conveniently short. >>>>> >>>>> Updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>>>> >>>>> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >>>>> I remember a comment against using array returns. >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> >>>>> >>>>> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>>>>> >>>>>> On 12 April 2013 22:38, roger riggs wrote: >>>>>>> >>>>>>> Following up on issue #114 Determine if DateTimeFormatSymbols >>>>>>> provides >>>>>>> correct localization >>>>>>> In the attempt to disambiguate the class name it has become very >>>>>>> long. >>>>>>> >>>>>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>>>>> 'DecimalSymbols'. Many of the other classes have similarly long >>>>>>> names >>>>>>> that >>>>>>> are unwieldy to use. >>>>>> >>>>>> Other controlling elements in the package end in "Style". Maybe this >>>>>> should be DecimalStyle. >>>>>> >>>>>> Stephen >>>>> >>>>> > From roger.riggs at oracle.com Mon Apr 15 11:57:45 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 15 Apr 2013 18:57:45 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Determine if DateTimeFormatSymbols provides correct localization Message-ID: <20130415185944.B00EF48301@hg.openjdk.java.net> Changeset: 857afa14d766 Author: rriggs Date: 2013-04-15 14:56 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/857afa14d766 Determine if DateTimeFormatSymbols provides correct localization Rename class to DecimalStyle Changed return type of DecimalStyle.getAvailableLocales() to Set < Locale > Issue #114 - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimePrintContext.java + src/share/classes/java/time/format/DecimalStyle.java ! src/share/classes/java/time/format/package-info.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java + test/java/time/tck/java/time/format/TCKDecimalStyle.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/test/java/time/format/AbstractTestPrinterParser.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java + test/java/time/test/java/time/format/TestDecimalStyle.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java From xueming.shen at oracle.com Mon Apr 15 12:35:26 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 15 Apr 2013 12:35:26 -0700 Subject: [threeten-dev] DateTimeFormatSymbols review In-Reply-To: References: <51687EDD.4030703@oracle.com> <516C2A0F.1020008@oracle.com> <516C46D3.60702@oracle.com> <516C4AAA.6020607@oracle.com> Message-ID: <516C567E.1010203@oracle.com> May 9th is supposed to be the last for "this" milestone, which is the planed "feature/API done for JSR310". We should have more time for bug fix and "minor" API changes till D-day. JSR310 can be done before Lambda is done, though. -Sherman On 4/15/13 11:59 AM, Stephen Colebourne wrote: > Are you indicating that there will be no more changes after May 9th at > all? I still don't see how Project Lambda is anywhere near meeting a > date like that... > > Stephen > > > On 15 April 2013 19:44, Xueming Shen wrote: >> How do you guys want to handle the 4/23 TL integration? To have a 4/20 or >> 4/21 as the cut off >> for all changes in Threeten repo? All changes should be able to make into >> b88. And we should >> have another slot around May 9 as the "final". >> >> -Sherman >> >> >> >> On 4/15/13 11:33 AM, Stephen Colebourne wrote: >>> Looks good to me >>> Stephen >>> >>> On 15 April 2013 19:28, roger riggs wrote: >>>> Hi, >>>> >>>> Updates method names as suggested, edited javadoc to replace >>>> or qualify use of 'symbols' with DecimalStyle. >>>> Changed the return type of DecimalStyle.getAvailableLocales() to >>>> Set. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>>> >>>> Roger >>>> >>>> >>>> On 4/15/2013 12:36 PM, Stephen Colebourne wrote: >>>>> We're agreed on the name. >>>>> >>>>> The methods currently named getSymbols() should also be altered. I >>>>> guess to getDecimalStyle()/withDecimalStyle(). Affects DTFormatter >>>>> DTPrintContext, DTParseContext. >>>>> >>>>> The Locale[] method should not return an array as you say. Should be >>>>> Set to fit with Chronology and ZoneId. >>>>> >>>>> thanks >>>>> Stephen >>>>> >>>>> >>>>> On 15 April 2013 17:25, roger riggs wrote: >>>>>> Hi, >>>>>> >>>>>> The name DecimalStyle would be consistent with the other >>>>>> styling types and is conveniently short. >>>>>> >>>>>> Updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-formatsymbols-114/ >>>>>> >>>>>> BTW, the DecimalStyle.getAvailableLocales method returns a Locale[]; >>>>>> I remember a comment against using array returns. >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4/13/2013 5:05 AM, Stephen Colebourne wrote: >>>>>>> On 12 April 2013 22:38, roger riggs wrote: >>>>>>>> Following up on issue #114 Determine if DateTimeFormatSymbols >>>>>>>> provides >>>>>>>> correct localization >>>>>>>> In the attempt to disambiguate the class name it has become very >>>>>>>> long. >>>>>>>> >>>>>>>> Perhaps instead of DateTimeDecimalFormatSymbols it could be simply >>>>>>>> 'DecimalSymbols'. Many of the other classes have similarly long >>>>>>>> names >>>>>>>> that >>>>>>>> are unwieldy to use. >>>>>>> Other controlling elements in the package end in "Style". Maybe this >>>>>>> should be DecimalStyle. >>>>>>> >>>>>>> Stephen >>>>>> From scolebourne at joda.org Mon Apr 15 12:47:49 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 15 Apr 2013 19:47:49 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Define the Java Time-Scale properly Message-ID: <20130415194813.ABF1448304@hg.openjdk.java.net> Changeset: 10b3e4872af6 Author: scolebourne Date: 2013-04-15 20:39 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/10b3e4872af6 Define the Java Time-Scale properly Assistance gratefully received from Zefram Fixes #291 ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/Instant.java From scolebourne at joda.org Mon Apr 15 12:58:33 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 15 Apr 2013 19:58:33 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Enhance formatting of instants Message-ID: <20130415195845.52BEE48305@hg.openjdk.java.net> Changeset: 835edcf9578a Author: scolebourne Date: 2013-04-15 20:58 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/835edcf9578a Enhance formatting of instants Add option to control fractional digits See #301 ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java + test/java/time/tck/java/time/format/TCKInstantPrinterParser.java From roger.riggs at oracle.com Tue Apr 16 14:21:46 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 16 Apr 2013 17:21:46 -0400 Subject: [threeten-dev] Review for 8009648: Tests fail in -agentvm -concurrency mode Message-ID: <516DC0EA.90709@oracle.com> Simple review to enable higher concurrency in java.time test runs: 8009648: Tests fail in -agentvm -concurrency mode webrev: http://cr.openjdk.java.net/~rriggs/webrev-testconcurrency/ Roger From yoshito_umaoka at us.ibm.com Tue Apr 16 15:00:34 2013 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 16 Apr 2013 18:00:34 -0400 Subject: [threeten-dev] CLDR Islamic calendar subtag updates Message-ID: First of all, sorry for slow update. After CLDR 23 release, we finally had chance to discuss about the Islamic calendar subtags in CLDR / Unicode locale extension. There is one major change since I informed our plan in this mailing list. In the original proposal, we planned to add a new key "cv" for specifying calendar algorithm variants. However, some of the CLDR technically committee members who are participating CalConnect raised a concern about the separation. I think this was also discussed in this list. The CLDR TC's latest consensus is to specify the calendar type including small algorithm variations by the calendar keyword ("ca") with optional subtags. So, "ca-islamic-cv-umalqura" in the previous proposal is changed to "ca-islamic-umalqura". I updated the document - http://cldr.unicode.org/development/development-process/design-proposals/islamic-calendar-types The actual changes in the calendar definition data file with this will be: Because the threeten-dev community was the original requestor for this, I'd like to check with this list before making the change in the CLDR repository. If you have any major problems with above, please respond to me ASAP. We're preparing for opening CLDR survey tool (online tool for collecting locale data) for the next major CLDR release. We need to put the new subtags into the system soon. Thanks, Yoshito From roger.riggs at oracle.com Wed Apr 17 12:17:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 17 Apr 2013 15:17:51 -0400 Subject: [threeten-dev] CLDR Islamic calendar subtag updates In-Reply-To: References: Message-ID: <516EF55F.9090806@oracle.com> Hi Yoshito, Thank you for the update, it is timely since we will need to stabilize the behavior of the JDK shortly. I would agree that a single string is more convenient for implementations. With reference to the document: http://cldr.unicode.org/development/development-process/design-proposals/islamic-calendar-types 1. In the table: "Proposed Calendar Type Value Changes" Should there be a row for "islamic-umalqura"? It appears in the xml form but not the table. 2. With respect to the simple subtag "islamic", is an implementation free to choose a consistent but arbitrary calendar to identify as "islamic" or is it expected that the simple string is not a sufficient identifier and is an error? (JSR 310 would default to "islamic-umalqura") 3. In Hierarchical Calendar Type Subtags: There is mention of a prefix match; I would assume it only applies to matching of complete subtags, not prefixes of arbitrary lengths. Also the matching only applies to the lookup of formatting data from the calendar type, not of the calendar itself. 4. Is/will the type-subtype syntax be rigorously consistent with BCP47? Do you have an expectation about when v24 will be finalized? Thanks, Roger On 4/16/2013 6:00 PM, yoshito_umaoka at us.ibm.com wrote: > First of all, sorry for slow update. After CLDR 23 release, we finally had > chance to discuss about the Islamic calendar subtags in CLDR / Unicode > locale extension. > > There is one major change since I informed our plan in this mailing list. > > In the original proposal, we planned to add a new key "cv" for specifying > calendar algorithm variants. However, some of the CLDR technically > committee members who are participating CalConnect raised a concern about > the separation. I think this was also discussed in this list. The CLDR > TC's latest consensus is to specify the calendar type including small > algorithm variations by the calendar keyword ("ca") with optional subtags. > So, "ca-islamic-cv-umalqura" in the previous proposal is changed to > "ca-islamic-umalqura". > > I updated the document - > http://cldr.unicode.org/development/development-process/design-proposals/islamic-calendar-types > > The actual changes in the calendar definition data file with this will be: > > > > > > > > since="24"/> > > > > > > > > Because the threeten-dev community was the original requestor for this, > I'd like to check with this list before making the change in the CLDR > repository. > If you have any major problems with above, please respond to me ASAP. > We're preparing for opening CLDR survey tool (online tool for collecting > locale data) for the next major CLDR release. We need to put the new > subtags into the system soon. > > Thanks, > Yoshito > > From yoshito_umaoka at us.ibm.com Wed Apr 17 13:35:31 2013 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Wed, 17 Apr 2013 16:35:31 -0400 Subject: [threeten-dev] CLDR Islamic calendar subtag updates In-Reply-To: <516EF55F.9090806@oracle.com> References: <516EF55F.9090806@oracle.com> Message-ID: > Thank you for the update, it is timely since we will need to stabilize > the behavior > of the JDK shortly. I would agree that a single string is more > convenient for implementations. Great. > > With reference to the document: > http://cldr.unicode.org/development/development-process/design- > proposals/islamic-calendar-types > > 1. In the table: "Proposed Calendar Type Value Changes" > Should there be a row for "islamic-umalqura"? It appears in the xml > form but not the table. Sorry. I forgot to add the row - I updated the table and added islamic-umalqura. > > 2. With respect to the simple subtag "islamic", is an implementation free > to choose a consistent but arbitrary calendar to identify as "islamic" > or is it expected that the simple string is not a sufficient > identifier and is an error? > (JSR 310 would default to "islamic-umalqura") My intention is the former. "islamic" alone may be used when algorithm variations are not important. A consumer of LDML may use a specific Islamic algorithm variant as the default. This approach would work better if someone wants to add a new variation to the existing calendar type. For example, JDK's Japanese calendar uses Gregorian but just altering eras. If someone want to provide more accurate implementation (using Japanese variation of Chinese lunisolar calendar before 1873), then it might be identified as "japanese-historic" or something. > > 3. In Hierarchical Calendar Type Subtags: > There is mention of a prefix match; I would assume it only applies > to matching of complete subtags, not prefixes of arbitrary lengths. Yes - it should only applies to matching of complete subtags. > Also the matching only applies to the lookup of formatting data > from the calendar type, not of the calendar itself. I think it really depends on use cases. The LDML specification would just explain that the first subtag specifies arbitrary calendar type and the rest specifies an algorithm variant. Of course, it is intended for supporting such fallback algorithm. But how to handle prefix match is really up to the consumer's decision. For future backward compatibility support purpose, I guess JSR310 may also apply the prefix match fallback - If this is well-documented and there is a way to know the exact type resolved for a given type, then I don't see any major issues there. > > 4. Is/will the type-subtype syntax be rigorously consistent with BCP47? > For calendar type - that's the plan - and I'd like to clearly specify the policy in the LDML specification. For other types (like collation, number... etc) - No. > Do you have an expectation about when v24 will be finalized? CLDR 24 release is currently planned on Sep 18, 2013. I'll try to finish all of changes for this specific item much earlier (including spec update review). -Yoshito From roger.riggs at oracle.com Thu Apr 18 09:11:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 18 Apr 2013 12:11:52 -0400 Subject: [threeten-dev] Webrev for implSpec #213 Message-ID: <51701B48.70107@oracle.com> Hi, For the change to use @implSpec, please review and comment on: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-implspec-213/ Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/ Thanks, Roger From xueming.shen at oracle.com Thu Apr 18 10:15:28 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Apr 2013 10:15:28 -0700 Subject: [threeten-dev] Webrev for implSpec #213 In-Reply-To: <51701B48.70107@oracle.com> References: <51701B48.70107@oracle.com> Message-ID: <51702A30.9020501@oracle.com> On 04/18/2013 09:11 AM, roger riggs wrote: > Hi, > > For the change to use @implSpec, please review and comment on: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-implspec-213/ > Javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/ > > Thanks, Roger > > any particular reason to remove test/ProblemList.txt from the repo? From scolebourne at joda.org Thu Apr 18 10:25:02 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 18 Apr 2013 18:25:02 +0100 Subject: [threeten-dev] Webrev for implSpec #213 In-Reply-To: <51701B48.70107@oracle.com> References: <51701B48.70107@oracle.com> Message-ID: Main change loks good to me. Stephen On 18 April 2013 17:11, roger riggs wrote: > Hi, > > For the change to use @implSpec, please review and comment on: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-implspec-213/ > Javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/ > > Thanks, Roger > > From roger.riggs at oracle.com Thu Apr 18 10:57:44 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 18 Apr 2013 13:57:44 -0400 Subject: [threeten-dev] Webrev for implSpec #213 In-Reply-To: <51702A30.9020501@oracle.com> References: <51701B48.70107@oracle.com> <51702A30.9020501@oracle.com> Message-ID: <51703418.8030202@oracle.com> Oops, no, I'm not sure why that happened. Roger On 4/18/2013 1:15 PM, Xueming Shen wrote: > On 04/18/2013 09:11 AM, roger riggs wrote: >> Hi, >> >> For the change to use @implSpec, please review and comment on: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-implspec-213/ >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/ >> >> Thanks, Roger >> >> > any particular reason to remove test/ProblemList.txt from the repo? From roger.riggs at oracle.com Thu Apr 18 12:00:56 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 18 Apr 2013 15:00:56 -0400 Subject: [threeten-dev] Webrev for implSpec #213 In-Reply-To: <51702A30.9020501@oracle.com> References: <51701B48.70107@oracle.com> <51702A30.9020501@oracle.com> Message-ID: <517042E8.7080805@oracle.com> Hi, I updated the webrev to restore ProblemList.txt and to revert to using

Package Specification

in the package-info.java files. It looks better. Roger On 4/18/2013 1:15 PM, Xueming Shen wrote: > On 04/18/2013 09:11 AM, roger riggs wrote: >> Hi, >> >> For the change to use @implSpec, please review and comment on: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-implspec-213/ >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/ >> >> Thanks, Roger >> >> > any particular reason to remove test/ProblemList.txt from the repo? From roger.riggs at oracle.com Thu Apr 18 14:32:02 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 18 Apr 2013 21:32:02 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: # 213 Implementation notes normalization Message-ID: <20130418213224.3B8994842C@hg.openjdk.java.net> Changeset: fee6670b8e43 Author: rriggs Date: 2013-04-18 17:31 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fee6670b8e43 # 213 Implementation notes normalization Updated to use @implSpec and @implNote Added -tag definitions to build.xml ! make/netbeans/threeten/build.xml ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DateTimeException.java ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Ser.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/HijrahEra.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimeParseException.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/format/DecimalStyle.java ! src/share/classes/java/time/format/FormatStyle.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/format/SignStyle.java ! src/share/classes/java/time/format/TextStyle.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesException.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java From leif.samuelsson at oracle.com Thu Apr 18 15:30:02 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 18 Apr 2013 15:30:02 -0700 Subject: [threeten-dev] [JavaFX API Review] RT-27841: Define API for DatePicker Message-ID: <517073EA.5060108@oracle.com> Hi all, The new JSR-310 API for date and time has now made it into JDK 8. This means that we can finally add a DatePicker UI control to JavaFX with support for a large number of locale based calendar formats. DatePicker is built on ComboBox, using both a TextField and a popup for typing or picking a date. The value type for setting and getting a date is java.time.LocalDate. This class uses the ISO-8601 calendar (proleptic Gregorian), although the actual display of the calendar popup will be based on whatever calendar (Chronology in the API) that is either specified in the user's default Locale, or set explicitly by the application. The DatePicker API is intended to be minimal at first, while still providing lots of flexibility. We can expand it with various conveniences in the future after getting it properly road tested. If in the future we get a FormattedTextField that extends TextField, then we can retrofit it into DatePicker without losing API compatibility. The popup can be styled with CSS and the individual grid cells can be fully customized by use of a cell factory. The application can add validation and error handling for text input by providing a StringConverter. This could for example wrap the default converter and catch parse exceptions. For reference, here are some links to the java.time Javadoc pages: http://download.java.net/jdk8/docs/api/java/time/LocalDate.html http://download.java.net/jdk8/docs/api/java/time/chrono/Chronology.html Below is a brief overview of the proposed DatePicker and DateCell classes. You can find the full Javadoc in the JIRA issue: https://javafx-jira.kenai.com/browse/RT-27481 --- package javafx.scene.control; public class DatePicker extends ComboBoxBase { public DatePicker(); public DatePicker(LocalDate localDate); public ObjectProperty> dayCellFactoryProperty(); public ObjectProperty chronologyProperty(); public BooleanProperty showWeekNumbersProperty(); public ObjectProperty> converterProperty(); public ReadOnlyObjectProperty editorProperty(); } --- package javafx.scene.control; public class DateCell extends Cell { @Override public void updateItem(LocalDate item, boolean empty); @Override protected Skin createDefaultSkin(); } --- A code review for the implementation will follow. Thanks, Leif From xueming.shen at oracle.com Thu Apr 18 16:50:13 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Apr 2013 16:50:13 -0700 Subject: [threeten-dev] test/java/time/test/java/util/TestFormatter fails in UTC Tz Message-ID: <517086B5.90701@oracle.com> http://cr.openjdk.java.net/~sherman/jdk8_threeten/juf.utc/ The toZoneIdStr(...), which returns the "expected" result, need update to not replace the GMT/UTC/UT to 'Z', as these ids are no longer normalized to 'Z'. I also added the UTC/GMT/UT-ed tzd, so the test failure can be caught earlier in any env. -Sherman From leif.samuelsson at oracle.com Thu Apr 18 19:15:32 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 18 Apr 2013 19:15:32 -0700 Subject: [threeten-dev] [JavaFX API Review] RT-27841: Define API for DatePicker In-Reply-To: <5E36D5A4-834C-4A98-8751-CEC344B049F0@gmail.com> References: <517073EA.5060108@oracle.com> <5E36D5A4-834C-4A98-8751-CEC344B049F0@gmail.com> Message-ID: <5170A8C4.6050600@oracle.com> There is no time picker planned for 8.0, but I suggest that we file feature requests in JIRA for TimePicker and DateTimePicker, to be considered for a future release. For many use cases, a ComboBox might be enough. Especially if you can prepopulate it with a list of times, say for ticket sales, appointments, and such. Leif On 2013-04-18 19:03, Scott Palmer wrote: > It's not clear to me,not knowing the new Java 8 date and time API. Will this be a Date and/or Time picker? I.e. will date and time be covered with a single control, or will the Date picker only handle calendar popups and choosing the date, with a separate control for a Time field? > > > Scott > > On 2013-04-18, at 6:30 PM, Leif Samuelsson wrote: > >> Hi all, >> >> The new JSR-310 API for date and time has now made it into JDK 8. This means >> that we can finally add a DatePicker UI control to JavaFX with support for a >> large number of locale based calendar formats. >> >> DatePicker is built on ComboBox, using both a TextField and a popup for >> typing or picking a date. The value type for setting and getting a date is >> java.time.LocalDate. This class uses the ISO-8601 calendar (proleptic >> Gregorian), although the actual display of the calendar popup will be based >> on whatever calendar (Chronology in the API) that is either specified in the >> user's default Locale, or set explicitly by the application. >> >> The DatePicker API is intended to be minimal at first, while still providing >> lots of flexibility. We can expand it with various conveniences in the >> future after getting it properly road tested. If in the future we get a >> FormattedTextField that extends TextField, then we can retrofit it into >> DatePicker without losing API compatibility. >> >> The popup can be styled with CSS and the individual grid cells can be fully >> customized by use of a cell factory. >> >> The application can add validation and error handling for text input by >> providing a StringConverter. This could for example wrap the default >> converter and catch parse exceptions. >> >> For reference, here are some links to the java.time Javadoc pages: >> >> http://download.java.net/jdk8/docs/api/java/time/LocalDate.html >> http://download.java.net/jdk8/docs/api/java/time/chrono/Chronology.html >> >> Below is a brief overview of the proposed DatePicker and DateCell >> classes. You can find the full Javadoc in the JIRA issue: >> >> https://javafx-jira.kenai.com/browse/RT-27481 >> >> --- >> >> package javafx.scene.control; >> >> public class DatePicker extends ComboBoxBase { >> public DatePicker(); >> public DatePicker(LocalDate localDate); >> public ObjectProperty> dayCellFactoryProperty(); >> public ObjectProperty chronologyProperty(); >> public BooleanProperty showWeekNumbersProperty(); >> public ObjectProperty> converterProperty(); >> public ReadOnlyObjectProperty editorProperty(); >> } >> >> --- >> >> package javafx.scene.control; >> >> public class DateCell extends Cell { >> @Override public void updateItem(LocalDate item, boolean empty); >> @Override protected Skin createDefaultSkin(); >> } >> >> --- >> >> A code review for the implementation will follow. >> >> Thanks, >> Leif >> From swpalmer at gmail.com Thu Apr 18 19:03:44 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 18 Apr 2013 22:03:44 -0400 Subject: [threeten-dev] [JavaFX API Review] RT-27841: Define API for DatePicker In-Reply-To: <517073EA.5060108@oracle.com> References: <517073EA.5060108@oracle.com> Message-ID: <5E36D5A4-834C-4A98-8751-CEC344B049F0@gmail.com> It's not clear to me,not knowing the new Java 8 date and time API. Will this be a Date and/or Time picker? I.e. will date and time be covered with a single control, or will the Date picker only handle calendar popups and choosing the date, with a separate control for a Time field? Scott On 2013-04-18, at 6:30 PM, Leif Samuelsson wrote: > Hi all, > > The new JSR-310 API for date and time has now made it into JDK 8. This means > that we can finally add a DatePicker UI control to JavaFX with support for a > large number of locale based calendar formats. > > DatePicker is built on ComboBox, using both a TextField and a popup for > typing or picking a date. The value type for setting and getting a date is > java.time.LocalDate. This class uses the ISO-8601 calendar (proleptic > Gregorian), although the actual display of the calendar popup will be based > on whatever calendar (Chronology in the API) that is either specified in the > user's default Locale, or set explicitly by the application. > > The DatePicker API is intended to be minimal at first, while still providing > lots of flexibility. We can expand it with various conveniences in the > future after getting it properly road tested. If in the future we get a > FormattedTextField that extends TextField, then we can retrofit it into > DatePicker without losing API compatibility. > > The popup can be styled with CSS and the individual grid cells can be fully > customized by use of a cell factory. > > The application can add validation and error handling for text input by > providing a StringConverter. This could for example wrap the default > converter and catch parse exceptions. > > For reference, here are some links to the java.time Javadoc pages: > > http://download.java.net/jdk8/docs/api/java/time/LocalDate.html > http://download.java.net/jdk8/docs/api/java/time/chrono/Chronology.html > > Below is a brief overview of the proposed DatePicker and DateCell > classes. You can find the full Javadoc in the JIRA issue: > > https://javafx-jira.kenai.com/browse/RT-27481 > > --- > > package javafx.scene.control; > > public class DatePicker extends ComboBoxBase { > public DatePicker(); > public DatePicker(LocalDate localDate); > public ObjectProperty> dayCellFactoryProperty(); > public ObjectProperty chronologyProperty(); > public BooleanProperty showWeekNumbersProperty(); > public ObjectProperty> converterProperty(); > public ReadOnlyObjectProperty editorProperty(); > } > > --- > > package javafx.scene.control; > > public class DateCell extends Cell { > @Override public void updateItem(LocalDate item, boolean empty); > @Override protected Skin createDefaultSkin(); > } > > --- > > A code review for the implementation will follow. > > Thanks, > Leif > From scolebourne at joda.org Fri Apr 19 02:45:07 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 19 Apr 2013 10:45:07 +0100 Subject: [threeten-dev] test/java/time/test/java/util/TestFormatter fails in UTC Tz In-Reply-To: <517086B5.90701@oracle.com> References: <517086B5.90701@oracle.com> Message-ID: Looks fine to me Stephen On 19 April 2013 00:50, Xueming Shen wrote: > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/juf.utc/ > > The toZoneIdStr(...), which returns the "expected" result, need update to > not > replace the GMT/UTC/UT to 'Z', as these ids are no longer normalized to 'Z'. > > I also added the UTC/GMT/UT-ed tzd, so the test failure can be caught > earlier > in any env. > > -Sherman From roger.riggs at oracle.com Fri Apr 19 11:26:34 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 19 Apr 2013 14:26:34 -0400 Subject: [threeten-dev] Review Lenient parsing of 2 and 4 digits values (years) Message-ID: <51718C5A.701@oracle.com> Hi, As noted in#218 Parsing 2 and 4 digit years , the reducedValue parsing lenient mode should be defined to allow parsing of absolute values greater than the defined field width. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ Modified DateTimeFormatter.appendValueReduced to define the behavior when isLenient. Modified NumberPrinterParser in lenient mode to accept 1..19 digits. Note, the API/ implementation only works for base < MAX_INT, ~ 10 digits but the field size may be defined larger. Removed width constraint for "fixed" fields unless strict. Modified ReducedPrinterParser.setValue to apply the base only if isStrict or the value is less than range. It is not possible to enter negative values since ReducedPrinterParser prohibits any sign character. It should be considered to make the sign parsing lenient also. Currently entering a sign is prohibited in a "fixed" length field. The definition of fixed is diluted in this case in lenient mode. It is also not possible to enter absolute values less than the width. All small values are considered to be combined with the base. The only interesting case though is year and the range of likely base values is the current or past centuries. Thanks, Roger From xueming.shen at oracle.com Fri Apr 19 12:20:26 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Apr 2013 12:20:26 -0700 Subject: [threeten-dev] Review Lenient parsing of 2 and 4 digits values (years) In-Reply-To: <51718C5A.701@oracle.com> References: <51718C5A.701@oracle.com> Message-ID: <517198FA.9010200@oracle.com> I'm a little concerned of the approach of using the reducedValue parsing/lenient mode to address this 2 and 4 digits values issues, especially it introduces in the "uncertainty of" adding the baseValue or not based on the width of the input value, while the method itself is originally designed to add the baseValue for a "reduced" input. There is also words later says "This is a fixed width parser operating using 'adjacent value parsing'...", anything need to be wording here? -Sherman On 04/19/2013 11:26 AM, roger riggs wrote: > Hi, > > As noted in#218 Parsing 2 and 4 digit years , the reducedValue parsing > lenient mode should be defined to allow parsing of absolute values > greater than the defined field width. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ > > Modified DateTimeFormatter.appendValueReduced to define the behavior when isLenient. > > Modified NumberPrinterParser in lenient mode to accept 1..19 digits. > Note, the API/ implementation only works for base < MAX_INT, ~ 10 digits > but the field size may be defined larger. > Removed width constraint for "fixed" fields unless strict. > > Modified ReducedPrinterParser.setValue to apply the base only > if isStrict or the value is less than range. > > It is not possible to enter negative values since ReducedPrinterParser > prohibits any sign character. It should be considered to make the > sign parsing lenient also. Currently entering a sign is prohibited in a "fixed" > length field. The definition of fixed is diluted in this case in lenient mode. > > It is also not possible to enter absolute values less than the width. > All small values are considered to be combined with the base. > The only interesting case though is year and the range of likely base > values is the current or past centuries. > > Thanks, Roger > From roger.riggs at oracle.com Fri Apr 19 13:48:50 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 19 Apr 2013 16:48:50 -0400 Subject: [threeten-dev] Review Lenient parsing of 2 and 4 digits values (years) In-Reply-To: <517198FA.9010200@oracle.com> References: <51718C5A.701@oracle.com> <517198FA.9010200@oracle.com> Message-ID: <5171ADB2.8030006@oracle.com> Hi Sherman, Yes, I missed updating some of the javadoc comments. To work effectively the reducedValue mechanism should be associated with the "yy" patterns but the default is strict. It seemed important to be able to leverage the locale specific date pattern info for the ordering and separators of the fields. I suppose the question is whether this kind of leniency is a reasonable interpretation or usage within the CLDR descriptions. Expanding the definition of the reducedValue seemed like a reasonable extension. Roger On 4/19/2013 3:20 PM, Xueming Shen wrote: > I'm a little concerned of the approach of using the reducedValue > parsing/lenient > mode to address this 2 and 4 digits values issues, especially it > introduces in the > "uncertainty of" adding the baseValue or not based on the width of the > input value, > while the method itself is originally designed to add the baseValue > for a "reduced" > input. There is also words later says "This is a fixed width parser > operating using > 'adjacent value parsing'...", anything need to be wording here? > > -Sherman > > On 04/19/2013 11:26 AM, roger riggs wrote: >> Hi, >> >> As noted in#218 Parsing 2 and 4 digit years >> , the reducedValue >> parsing >> lenient mode should be defined to allow parsing of absolute values >> greater than the defined field width. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> Modified DateTimeFormatter.appendValueReduced to define the behavior >> when isLenient. >> >> Modified NumberPrinterParser in lenient mode to accept 1..19 digits. >> Note, the API/ implementation only works for base < MAX_INT, ~ 10 digits >> but the field size may be defined larger. >> Removed width constraint for "fixed" fields unless strict. >> >> Modified ReducedPrinterParser.setValue to apply the base only >> if isStrict or the value is less than range. >> >> It is not possible to enter negative values since ReducedPrinterParser >> prohibits any sign character. It should be considered to make the >> sign parsing lenient also. Currently entering a sign is prohibited >> in a "fixed" >> length field. The definition of fixed is diluted in this case in >> lenient mode. >> >> It is also not possible to enter absolute values less than the width. >> All small values are considered to be combined with the base. >> The only interesting case though is year and the range of likely base >> values is the current or past centuries. >> >> Thanks, Roger >> > From roger.riggs at oracle.com Fri Apr 19 14:33:18 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 19 Apr 2013 17:33:18 -0400 Subject: [threeten-dev] Add method to get localized date and time pattern Message-ID: <5171B81E.4060001@oracle.com> As requested in #305 Add getLocalePattern(datestyle, timestyle) method Webrev: http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ Please review Thanks, Roger From misterm at gmail.com Fri Apr 19 14:37:26 2013 From: misterm at gmail.com (Michael Nascimento) Date: Fri, 19 Apr 2013 18:37:26 -0300 Subject: [threeten-dev] Add method to get localized date and time pattern In-Reply-To: <5171B81E.4060001@oracle.com> References: <5171B81E.4060001@oracle.com> Message-ID: Hi Roger, + Objects.requireNonNull(locale, "locale"); + Objects.requireNonNull(chrono, "chrono"); + if (locale == null && chrono == null) { + throw new IllegalArgumentException("Either dateStyle or timeStyle must be non-null"); + } I guess this is a leftover of your attempts to implement it.... Which one the two is right? Regards, Michael On Fri, Apr 19, 2013 at 6:33 PM, roger riggs wrote: > As requested in #305 Add getLocalePattern(datestyle, timestyle) method > > > Webrev: > > http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ > > Please review > > Thanks, Roger > From scolebourne at joda.org Sat Apr 20 00:29:43 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 20 Apr 2013 08:29:43 +0100 Subject: [threeten-dev] Add method to get localized date and time pattern In-Reply-To: References: <5171B81E.4060001@oracle.com> Message-ID: In addition to Michael's point: - All static methods should be located before the constructor within a file - The method should have the parameter order (style, style, chrono, locale) to fit in with general use of locale (so a parallel method or future default param could drop the locale in favour of the default locale. thanks Stephen On 19 April 2013 22:37, Michael Nascimento wrote: > Hi Roger, > > + Objects.requireNonNull(locale, "locale"); > + Objects.requireNonNull(chrono, "chrono"); > + if (locale == null && chrono == null) { > + throw new IllegalArgumentException("Either dateStyle or > timeStyle must be non-null"); > + } > > I guess this is a leftover of your attempts to implement it.... Which > one the two is right? > > Regards, > Michael > > On Fri, Apr 19, 2013 at 6:33 PM, roger riggs wrote: >> As requested in #305 Add getLocalePattern(datestyle, timestyle) method >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ >> >> Please review >> >> Thanks, Roger >> From scolebourne at joda.org Sat Apr 20 01:16:57 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 20 Apr 2013 09:16:57 +0100 Subject: [threeten-dev] Review Lenient parsing of 2 and 4 digits values (years) In-Reply-To: <5171ADB2.8030006@oracle.com> References: <51718C5A.701@oracle.com> <517198FA.9010200@oracle.com> <5171ADB2.8030006@oracle.com> Message-ID: The CLDR document does not explicitly cover this http://www.unicode.org/reports/tr35/tr35-dates.html#Parsing_Dates_Times Personally, I'm not convinced that a single digit user entry "1" is clear enough to treat as either year 2001 or year 1. SimpleDateFormat does however allow this, and chooses to interpret is as year 1. If we're going to allow it, then it should match SimpleDateFormat, not what you currently have. If in adjacent parsing mode then the width needs to be fixed and not varying with leniency. This handles a pattern like ddMMyy. thanks Stephen On 19 April 2013 21:48, roger riggs wrote: > Hi Sherman, > > Yes, I missed updating some of the javadoc comments. > > To work effectively the reducedValue mechanism should be associated with > the "yy" patterns but the default is strict. It seemed important to be able > to leverage > the locale specific date pattern info for the ordering and separators > of the fields. I suppose the question is whether this kind of leniency > is a reasonable interpretation or usage within the CLDR descriptions. > > Expanding the definition of the reducedValue seemed like a reasonable > extension. > > Roger > > > > On 4/19/2013 3:20 PM, Xueming Shen wrote: >> >> I'm a little concerned of the approach of using the reducedValue >> parsing/lenient >> mode to address this 2 and 4 digits values issues, especially it >> introduces in the >> "uncertainty of" adding the baseValue or not based on the width of the >> input value, >> while the method itself is originally designed to add the baseValue for a >> "reduced" >> input. There is also words later says "This is a fixed width parser >> operating using >> 'adjacent value parsing'...", anything need to be wording here? >> >> -Sherman >> >> On 04/19/2013 11:26 AM, roger riggs wrote: >>> >>> Hi, >>> >>> As noted in#218 Parsing 2 and 4 digit years >>> , the reducedValue parsing >>> lenient mode should be defined to allow parsing of absolute values >>> greater than the defined field width. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>> >>> Modified DateTimeFormatter.appendValueReduced to define the behavior when >>> isLenient. >>> >>> Modified NumberPrinterParser in lenient mode to accept 1..19 digits. >>> Note, the API/ implementation only works for base < MAX_INT, ~ 10 digits >>> but the field size may be defined larger. >>> Removed width constraint for "fixed" fields unless strict. >>> >>> Modified ReducedPrinterParser.setValue to apply the base only >>> if isStrict or the value is less than range. >>> >>> It is not possible to enter negative values since ReducedPrinterParser >>> prohibits any sign character. It should be considered to make the >>> sign parsing lenient also. Currently entering a sign is prohibited in a >>> "fixed" >>> length field. The definition of fixed is diluted in this case in lenient >>> mode. >>> >>> It is also not possible to enter absolute values less than the width. >>> All small values are considered to be combined with the base. >>> The only interesting case though is year and the range of likely base >>> values is the current or past centuries. >>> >>> Thanks, Roger >>> >> > From roger.riggs at oracle.com Sat Apr 20 08:24:40 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 20 Apr 2013 11:24:40 -0400 Subject: [threeten-dev] Add method to get localized date and time pattern In-Reply-To: References: <5171B81E.4060001@oracle.com> Message-ID: <5172B338.9040208@oracle.com> Thanks Michael, It was supposed to be checking dateStyle and timeStyle, they can't both be null. (And the test is missing for IAE). Roger On 4/19/2013 5:37 PM, Michael Nascimento wrote: > Hi Roger, > > + Objects.requireNonNull(locale, "locale"); > + Objects.requireNonNull(chrono, "chrono"); > + if (locale == null && chrono == null) { > + throw new IllegalArgumentException("Either dateStyle or > timeStyle must be non-null"); > + } > > I guess this is a leftover of your attempts to implement it.... Which > one the two is right? > > Regards, > Michael > > On Fri, Apr 19, 2013 at 6:33 PM, roger riggs wrote: >> As requested in #305 Add getLocalePattern(datestyle, timestyle) method >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ >> >> Please review >> >> Thanks, Roger >> From roger.riggs at oracle.com Sat Apr 20 09:44:46 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 20 Apr 2013 12:44:46 -0400 Subject: [threeten-dev] Add method to get localized date and time pattern In-Reply-To: References: <5171B81E.4060001@oracle.com> Message-ID: <5172C5FE.1010704@oracle.com> Updated the webrev to address the comments. http://cr.openjdk.java.net/~rriggs/webrev-localized-pattern-305/ Thanks, Roger On 4/20/2013 3:29 AM, Stephen Colebourne wrote: > In addition to Michael's point: > - All static methods should be located before the constructor within a file > - The method should have the parameter order (style, style, chrono, > locale) to fit in with general use of locale (so a parallel method or > future default param could drop the locale in favour of the default > locale. > > thanks > Stephen > > > On 19 April 2013 22:37, Michael Nascimento wrote: >> Hi Roger, >> >> + Objects.requireNonNull(locale, "locale"); >> + Objects.requireNonNull(chrono, "chrono"); >> + if (locale == null && chrono == null) { >> + throw new IllegalArgumentException("Either dateStyle or >> timeStyle must be non-null"); >> + } >> >> I guess this is a leftover of your attempts to implement it.... Which >> one the two is right? >> >> Regards, >> Michael >> >> On Fri, Apr 19, 2013 at 6:33 PM, roger riggs wrote: >>> As requested in #305 Add getLocalePattern(datestyle, timestyle) method >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ >>> >>> Please review >>> >>> Thanks, Roger >>> From scolebourne at joda.org Sat Apr 20 12:48:51 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 20 Apr 2013 20:48:51 +0100 Subject: [threeten-dev] Add method to get localized date and time pattern In-Reply-To: <5172C5FE.1010704@oracle.com> References: <5171B81E.4060001@oracle.com> <5172C5FE.1010704@oracle.com> Message-ID: Looks good to push Stephen On 20 April 2013 17:44, roger riggs wrote: > Updated the webrev to address the comments. > > http://cr.openjdk.java.net/~rriggs/webrev-localized-pattern-305/ > > Thanks, Roger > > > On 4/20/2013 3:29 AM, Stephen Colebourne wrote: >> >> In addition to Michael's point: >> - All static methods should be located before the constructor within a >> file >> - The method should have the parameter order (style, style, chrono, >> locale) to fit in with general use of locale (so a parallel method or >> future default param could drop the locale in favour of the default >> locale. >> >> thanks >> Stephen >> >> >> On 19 April 2013 22:37, Michael Nascimento wrote: >>> >>> Hi Roger, >>> >>> + Objects.requireNonNull(locale, "locale"); >>> + Objects.requireNonNull(chrono, "chrono"); >>> + if (locale == null && chrono == null) { >>> + throw new IllegalArgumentException("Either dateStyle or >>> timeStyle must be non-null"); >>> + } >>> >>> I guess this is a leftover of your attempts to implement it.... Which >>> one the two is right? >>> >>> Regards, >>> Michael >>> >>> On Fri, Apr 19, 2013 at 6:33 PM, roger riggs >>> wrote: >>>> >>>> As requested in #305 Add getLocalePattern(datestyle, timestyle) method >>>> >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rriggs/localized-pattern-305/ >>>> >>>> Please review >>>> >>>> Thanks, Roger >>>> > From roger.riggs at oracle.com Sat Apr 20 13:29:34 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 20 Apr 2013 16:29:34 -0400 Subject: [threeten-dev] Lenient parsing of 2 and 4 digits values (years) In-Reply-To: References: <51718C5A.701@oracle.com> <517198FA.9010200@oracle.com> <5171ADB2.8030006@oracle.com> Message-ID: <5172FAAE.1070600@oracle.com> Hi, I'm not sure I understand all of the logic/code around parseAdjacent mode. It appears only to be active after a non-fixed width parser. ReducePrinterParser is defined to be statically fixed width but the setting of strict vs lenient isn't known until it is encountered during parsing. As such, the mechanism for accumulating subsequentWidth is not active. If it was then the ReducedPrinterParser could avoid eagerly consuming all the digits and leave them for subsequent parsers. If the current state of strict vs lenient was visible while building then ReducedPrinterParser could be sensitive to that and be created as fixed or variable width as appropriate. I'll look at SimpleDateFormat... Roger On 4/20/2013 4:16 AM, Stephen Colebourne wrote: > The CLDR document does not explicitly cover this > http://www.unicode.org/reports/tr35/tr35-dates.html#Parsing_Dates_Times > > Personally, I'm not convinced that a single digit user entry "1" is > clear enough to treat as either year 2001 or year 1. SimpleDateFormat > does however allow this, and chooses to interpret is as year 1. If > we're going to allow it, then it should match SimpleDateFormat, not > what you currently have. > > If in adjacent parsing mode then the width needs to be fixed and not > varying with leniency. This handles a pattern like ddMMyy. > > thanks > Stephen > > > > On 19 April 2013 21:48, roger riggs wrote: >> Hi Sherman, >> >> Yes, I missed updating some of the javadoc comments. >> >> To work effectively the reducedValue mechanism should be associated with >> the "yy" patterns but the default is strict. It seemed important to be able >> to leverage >> the locale specific date pattern info for the ordering and separators >> of the fields. I suppose the question is whether this kind of leniency >> is a reasonable interpretation or usage within the CLDR descriptions. >> >> Expanding the definition of the reducedValue seemed like a reasonable >> extension. >> >> Roger >> >> >> >> On 4/19/2013 3:20 PM, Xueming Shen wrote: >>> I'm a little concerned of the approach of using the reducedValue >>> parsing/lenient >>> mode to address this 2 and 4 digits values issues, especially it >>> introduces in the >>> "uncertainty of" adding the baseValue or not based on the width of the >>> input value, >>> while the method itself is originally designed to add the baseValue for a >>> "reduced" >>> input. There is also words later says "This is a fixed width parser >>> operating using >>> 'adjacent value parsing'...", anything need to be wording here? >>> >>> -Sherman >>> >>> On 04/19/2013 11:26 AM, roger riggs wrote: >>>> Hi, >>>> >>>> As noted in#218 Parsing 2 and 4 digit years >>>> , the reducedValue parsing >>>> lenient mode should be defined to allow parsing of absolute values >>>> greater than the defined field width. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>>> >>>> Modified DateTimeFormatter.appendValueReduced to define the behavior when >>>> isLenient. >>>> >>>> Modified NumberPrinterParser in lenient mode to accept 1..19 digits. >>>> Note, the API/ implementation only works for base < MAX_INT, ~ 10 digits >>>> but the field size may be defined larger. >>>> Removed width constraint for "fixed" fields unless strict. >>>> >>>> Modified ReducedPrinterParser.setValue to apply the base only >>>> if isStrict or the value is less than range. >>>> >>>> It is not possible to enter negative values since ReducedPrinterParser >>>> prohibits any sign character. It should be considered to make the >>>> sign parsing lenient also. Currently entering a sign is prohibited in a >>>> "fixed" >>>> length field. The definition of fixed is diluted in this case in lenient >>>> mode. >>>> >>>> It is also not possible to enter absolute values less than the width. >>>> All small values are considered to be combined with the base. >>>> The only interesting case though is year and the range of likely base >>>> values is the current or past centuries. >>>> >>>> Thanks, Roger >>>> From roger.riggs at oracle.com Sat Apr 20 13:31:22 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 20 Apr 2013 20:31:22 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: #305 Add getLocalePattern(datestyle, timestyle) method Message-ID: <20130420203207.D452E484AE@hg.openjdk.java.net> Changeset: 669138cb730f Author: rriggs Date: 2013-04-20 16:30 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/669138cb730f #305 Add getLocalePattern(datestyle, timestyle) method Added in DateTimeFormatterBuilder Added Tests for several locales and Chronologies ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java From scolebourne at joda.org Sun Apr 21 03:53:58 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 21 Apr 2013 11:53:58 +0100 Subject: [threeten-dev] Lenient parsing of 2 and 4 digits values (years) In-Reply-To: <5172FAAE.1070600@oracle.com> References: <51718C5A.701@oracle.com> <517198FA.9010200@oracle.com> <5171ADB2.8030006@oracle.com> <5172FAAE.1070600@oracle.com> Message-ID: On 20 April 2013 21:29, roger riggs wrote: > I'm not sure I understand all of the logic/code around parseAdjacent mode. > It appears only to be active after a non-fixed width parser. Handling the case of a series of fixed width parses is easy and requires no special logic. Each only consumes the amount available. Handling a fixed width after a variable width requires special handling, otherwise the variable width one gobbles everything. > If the current state of strict vs lenient was visible while building then > ReducedPrinterParser could be sensitive to that and be created > as fixed or variable width as appropriate. That may be a possible solution. Stephen From xueming.shen at oracle.com Mon Apr 22 11:30:08 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 22 Apr 2013 18:30:08 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated TestFormatter.java for the tz failure in GMT/UTC configuration Message-ID: <20130422183036.8C34E484EC@hg.openjdk.java.net> Changeset: 4cd2f44c65b2 Author: sherman Date: 2013-04-22 11:25 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4cd2f44c65b2 Updated TestFormatter.java for the tz failure in GMT/UTC configuration ! test/java/time/test/java/util/TestFormatter.java From roger.riggs at oracle.com Mon Apr 22 15:18:57 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 22 Apr 2013 18:18:57 -0400 Subject: [threeten-dev] Lenient parsing of 2 and 4 digits values In-Reply-To: References: <51718C5A.701@oracle.com> <517198FA.9010200@oracle.com> <5171ADB2.8030006@oracle.com> <5172FAAE.1070600@oracle.com> Message-ID: <5175B751.5030502@oracle.com> Hi, An alternative to the strict/lenient proposal with better/cleaner semantics is to modify appendValueReduced to be a variable width numeric field and treat it very similarly to NumberPrinterParser. If the min == max, it has the current behavior. If max > min, then it uses the adjacent parsing mode to update the subsequentWidth value if followed by fixed width fields but can then parse additional digits. The number of digits supplied as input is used to do the substitution into the base value. If the number of digits input is the same as the number of digits in the base value then the baseValue is not used. The strict/lenient mode is not necessary, the min/max width values are sufficient to control the parsing. Similarly, formatting can be conditioned to output the reduce value to fill the minimum width unless the actual value cannot be represented accurately and then the full value can be output up to the max field width. The updated webrev and tests illustrate this approach. This this idea is viable, some additional cleanup work is needed to expand and reorganize the tests and cleanup the implementation and description. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ Please comment. Roger From roger.riggs at oracle.com Wed Apr 24 15:00:18 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 24 Apr 2013 18:00:18 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 Message-ID: <517855F2.3000403@oracle.com> Hi, Cleanup of the changes for addValueReduced and the ReducedPrinterParser. The parseStrict and parseLenient logic re-introduced so that by default the behavior of appendPattern("yyMMdd") will result in a fixed width parse unless setLenient is called in the DateTimeFormatterBuilder. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ Please review. Thanks, Roger [1] https://github.com/ThreeTen/threeten/issues/218 From scolebourne at joda.org Thu Apr 25 03:07:57 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 25 Apr 2013 11:07:57 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517855F2.3000403@oracle.com> References: <517855F2.3000403@oracle.com> Message-ID: My concern is that this change caters too much for the edge case and not enough for the typical use case. In the typical use case, the user just wants to format/parse a fixed 2 digit year. The change to the builder now means they have to specify two widths, not one. We should retain the method with one width argument at the very least. Next, it seems that the behaviour is different to SimpleDateFormat, where parsing anything other than the specified width results in a pure year, not a year merged with the base year. At the very least, we need a way to replicate that, so our patterns match SDF. This would seem sensible behaviour: * appendValueReduced(YEAR, 2, 2000) * format = lowest 2 digits of year, zero padded if necessary * parse-strict = only accept two digits and apply base year * parse-lenient alone (yy/MM) = parse as though it were appendValue(YEAR). If 2 digits parsed then apply base year. * parse-lenient not adjacent (yyMMdd) = parse as though it were appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed then apply base year. * parse-lenient adjacent (MMddyy) = same as parse-strict Beyond that, the new method you're proposing seems to be controlling the maximum width of parsing allowed in lenient mode. I guess that is fine, but I'm not sure it would see wide applicability. We generally just say lenient is lenient, and I don't think a maxWidth concept should apply at all in strict mode in the context of "reduced". Sorry this change seems more complex than I expected. Stephen On 24 April 2013 23:00, roger riggs wrote: > Hi, > > Cleanup of the changes for addValueReduced and the ReducedPrinterParser. > The parseStrict and parseLenient logic re-introduced so that by default > the behavior of appendPattern("yyMMdd") will result in a fixed width parse > unless setLenient is called in the DateTimeFormatterBuilder. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ > > Please review. > > Thanks, Roger > > [1] https://github.com/ThreeTen/threeten/issues/218 From roger.riggs at oracle.com Thu Apr 25 07:40:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Apr 2013 10:40:51 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> Message-ID: <51794073.2050800@oracle.com> Hi, On 4/25/2013 6:07 AM, Stephen Colebourne wrote: > My concern is that this change caters too much for the edge case and > not enough for the typical use case. In the typical use case, the user > just wants to format/parse a fixed 2 digit year. The change to the > builder now means they have to specify two widths, not one. We should > retain the method with one width argument at the very least. ok, the min/max form provided a way on formatting to be able to get the complementary behavior on formatting of formatting the full year if the two digit form was not in range of the base. > > Next, it seems that the behaviour is different to SimpleDateFormat, > where parsing anything other than the specified width results in a > pure year, not a year merged with the base year. At the very least, we > need a way to replicate that, so our patterns match SDF. yes, the patterns will cause the least confusion if they match. On a related note, should we consider using the heuristic for the base year (current - 80)? Currently it is a bit awkward Year.now().getYear(); developers might take the shortcut and stick in some value they think is useful but it will vary from app to app and get stale. > > This would seem sensible behaviour: > * appendValueReduced(YEAR, 2, 2000) > * format = lowest 2 digits of year, zero padded if necessary > * parse-strict = only accept two digits and apply base year > * parse-lenient alone (yy/MM) = parse as though it were > appendValue(YEAR). If 2 digits parsed then apply base year. > * parse-lenient not adjacent (yyMMdd) = parse as though it were > appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed > then apply base year. > * parse-lenient adjacent (MMddyy) = same as parse-strict Seems reasonable. > > Beyond that, the new method you're proposing seems to be controlling > the maximum width of parsing allowed in lenient mode. I guess that is > fine, but I'm not sure it would see wide applicability. We generally > just say lenient is lenient, and I don't think a maxWidth concept > should apply at all in strict mode in the context of "reduced". ok, for lenient, the width does not need to be constrained Thanks, Roger > > Sorry this change seems more complex than I expected. > Stephen > > > > On 24 April 2013 23:00, roger riggs wrote: >> Hi, >> >> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >> The parseStrict and parseLenient logic re-introduced so that by default >> the behavior of appendPattern("yyMMdd") will result in a fixed width parse >> unless setLenient is called in the DateTimeFormatterBuilder. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> Please review. >> >> Thanks, Roger >> >> [1] https://github.com/ThreeTen/threeten/issues/218 From scolebourne at joda.org Thu Apr 25 10:29:41 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 25 Apr 2013 18:29:41 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517957EE.8040400@oracle.com> References: <517855F2.3000403@oracle.com> <51794073.2050800@oracle.com> <517957EE.8040400@oracle.com> Message-ID: In Joda-Time, the base value is set on the formatter, not the builder. We could do the same, but I don't think its the right option (as we allow anything to be truncated, not just one field. The same problem applies to a bulider-wide base value. Thats why its necessary to tie the base value in to the appendValueReduced(). We could have an appendPattern(String, Map) where the map tells the method what base year to use. But realistically, no-one woud use the method as they might as well use the builder proper at that point. I agree that 2000 may not satisfy the birthdate case, but only something like (current - 100) would really satisfy that. Any other choice is more arbitrary. It would have to be far enough in the future that it won't become out of date (as it is in the spec it really shouldn't be changed in the future). The 1940 to 1950 is just about possible, but effectively makes this API expire in 2040/2050, which no longer feel that far away. A different value per JDK release is also likely to confuse, although is at least more consistent than (current - 80). I might be OK with a value that changes per JDK and once per decade. So the value would be (jdk-release-year-rounded-down-to-decade - 80). Which would be 1930 until a JDK relase in 202x. Although scheduling a task to make that happen in 7 years time would be fun... Stephen On 25 April 2013 17:21, roger riggs wrote: > It depends on the use case, for entering birthdates, SDF make more sense > because it goes back 80 years. Using valueReduced at 2000 goes back only > 13 years. > > For the birthday case, a base of 1940 would be useful for ages up to 73. > Any developer for this case will need to use DateTimeFormatterBuilder > and hand craft the builder. > > I would bias the range toward the past, not the future, I think 25 years in > the > future is plenty, though in 10 years, it would need to be reviewed. > > Would it be reasonable to make the baseValue be a settable value > in the Builder? Then at least the developer could set the baseValue > and then append the pattern to get the desired result. > > Roger > > > > On 4/25/2013 12:08 PM, Stephen Colebourne wrote: > > On 25 Apr 2013 16:41, "roger riggs" wrote: >>> Next, it seems that the behaviour is different to SimpleDateFormat, >>> where parsing anything other than the specified width results in a >>> pure year, not a year merged with the base year. At the very least, we >>> need a way to replicate that, so our patterns match SDF. >> >> yes, the patterns will cause the least confusion if they match. >> On a related note, should we consider using the heuristic for the base >> year (current - 80)? >> Currently it is a bit awkward Year.now().getYear(); developers might >> take the shortcut and stick in some value they think is useful but it will >> vary >> from app to app and get stale. > > I think the SDF behaviour linking to current is poor design as any testing > you do becomes null and void on Jan 1st. The 2000 base is pretty reasonable > for today. Any other fixed JDK choice has real downsides. > > Stephen > > From xueming.shen at oracle.com Thu Apr 25 11:06:12 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 25 Apr 2013 11:06:12 -0700 Subject: [threeten-dev] Fwd: Re: Review for parsing 2 to 4 years #218 Message-ID: <51797094.3030401@oracle.com> -------- Original Message -------- Message-ID: <51796E5B.8020704 at oracle.com> Date: Thu, 25 Apr 2013 10:56:43 -0700 From: Xueming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Colebourne Subject: Re: [threeten-dev] Review for parsing 2 to 4 years #218 References: <517855F2.3000403 at oracle.com> <51794073.2050800 at oracle.com> <517957EE.8040400 at oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Maybe an appendValueReducedAdjusted(..., ValueAdjuster) is something more reasonable here? with interface ValueAdjuster { long adjust(TemporaField field, long value); } While myself is really not a fan of this reduced_and_adjusted idea, I think we're having enough interface and flexibility already here. But guess it at least has the benefit of leaving appendValueReduced to what it is intended, without blurring the spec and implementation with a "may/will be wrong in xyz years" base value. I always input 4 digits when asked during my web experience recently, I don't think you can get away with a 2 digits year very often these days when you are being asking mm/dd/yyyy... -Sherman On 04/25/2013 10:29 AM, Stephen Colebourne wrote: > In Joda-Time, the base value is set on the formatter, not the builder. > We could do the same, but I don't think its the right option (as we > allow anything to be truncated, not just one field. The same problem > applies to a bulider-wide base value. Thats why its necessary to tie > the base value in to the appendValueReduced(). > > We could have an appendPattern(String, Map) where the > map tells the method what base year to use. But realistically, no-one > woud use the method as they might as well use the builder proper at > that point. > > I agree that 2000 may not satisfy the birthdate case, but only > something like (current - 100) would really satisfy that. Any other > choice is more arbitrary. It would have to be far enough in the future > that it won't become out of date (as it is in the spec it really > shouldn't be changed in the future). The 1940 to 1950 is just about > possible, but effectively makes this API expire in 2040/2050, which no > longer feel that far away. > > A different value per JDK release is also likely to confuse, although > is at least more consistent than (current - 80). > > I might be OK with a value that changes per JDK and once per decade. > So the value would be (jdk-release-year-rounded-down-to-decade - 80). > Which would be 1930 until a JDK relase in 202x. Although scheduling a > task to make that happen in 7 years time would be fun... > > Stephen > > > On 25 April 2013 17:21, roger riggs wrote: >> It depends on the use case, for entering birthdates, SDF make more sense >> because it goes back 80 years. Using valueReduced at 2000 goes back only >> 13 years. >> >> For the birthday case, a base of 1940 would be useful for ages up to 73. >> Any developer for this case will need to use DateTimeFormatterBuilder >> and hand craft the builder. >> >> I would bias the range toward the past, not the future, I think 25 years in >> the >> future is plenty, though in 10 years, it would need to be reviewed. >> >> Would it be reasonable to make the baseValue be a settable value >> in the Builder? Then at least the developer could set the baseValue >> and then append the pattern to get the desired result. >> >> Roger >> >> >> >> On 4/25/2013 12:08 PM, Stephen Colebourne wrote: >> >> On 25 Apr 2013 16:41, "roger riggs" wrote: >>>> Next, it seems that the behaviour is different to SimpleDateFormat, >>>> where parsing anything other than the specified width results in a >>>> pure year, not a year merged with the base year. At the very least, we >>>> need a way to replicate that, so our patterns match SDF. >>> yes, the patterns will cause the least confusion if they match. >>> On a related note, should we consider using the heuristic for the base >>> year (current - 80)? >>> Currently it is a bit awkward Year.now().getYear(); developers might >>> take the shortcut and stick in some value they think is useful but it will >>> vary >>> from app to app and get stale. >> I think the SDF behaviour linking to current is poor design as any testing >> you do becomes null and void on Jan 1st. The 2000 base is pretty reasonable >> for today. Any other fixed JDK choice has real downsides. >> >> Stephen >> >> From roger.riggs at oracle.com Thu Apr 25 11:22:43 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Apr 2013 14:22:43 -0400 Subject: [threeten-dev] Fwd: Re: Review for parsing 2 to 4 years #218 In-Reply-To: <51797094.3030401@oracle.com> References: <51797094.3030401@oracle.com> Message-ID: <51797473.5090205@oracle.com> Hi, The impetus was less with the appendValueReduced method itself but to be able to leverage the locale specific date patterns and be able allow a more flexible UI that would accept a more lenient years to be input. In the CLDR data there are many forms that include 'yy' that could benifit the reduced input. There are very few forms that include yyyy. Roger On 4/25/2013 2:06 PM, Xueming Shen wrote: > > > Maybe an appendValueReducedAdjusted(..., ValueAdjuster) is something more > reasonable here? with > > interface ValueAdjuster { > long adjust(TemporaField field, long value); > } > > While myself is really not a fan of this reduced_and_adjusted idea, I > think we're > having enough interface and flexibility already here. But guess it at > least has the > benefit of leaving appendValueReduced to what it is intended, without > blurring the > spec and implementation with a "may/will be wrong in xyz years" base > value. > > I always input 4 digits when asked during my web experience recently, > I don't think > you can get away with a 2 digits year very often these days when you > are being > asking mm/dd/yyyy... > > -Sherman > > On 04/25/2013 10:29 AM, Stephen Colebourne wrote: >> In Joda-Time, the base value is set on the formatter, not the builder. >> We could do the same, but I don't think its the right option (as we >> allow anything to be truncated, not just one field. The same problem >> applies to a bulider-wide base value. Thats why its necessary to tie >> the base value in to the appendValueReduced(). >> >> We could have an appendPattern(String, Map) where the >> map tells the method what base year to use. But realistically, no-one >> woud use the method as they might as well use the builder proper at >> that point. >> >> I agree that 2000 may not satisfy the birthdate case, but only >> something like (current - 100) would really satisfy that. Any other >> choice is more arbitrary. It would have to be far enough in the future >> that it won't become out of date (as it is in the spec it really >> shouldn't be changed in the future). The 1940 to 1950 is just about >> possible, but effectively makes this API expire in 2040/2050, which no >> longer feel that far away. >> >> A different value per JDK release is also likely to confuse, although >> is at least more consistent than (current - 80). >> >> I might be OK with a value that changes per JDK and once per decade. >> So the value would be (jdk-release-year-rounded-down-to-decade - 80). >> Which would be 1930 until a JDK relase in 202x. Although scheduling a >> task to make that happen in 7 years time would be fun... >> >> Stephen >> >> >> On 25 April 2013 17:21, roger riggs wrote: >>> It depends on the use case, for entering birthdates, SDF make more >>> sense >>> because it goes back 80 years. Using valueReduced at 2000 goes >>> back only >>> 13 years. >>> >>> For the birthday case, a base of 1940 would be useful for ages up >>> to 73. >>> Any developer for this case will need to use DateTimeFormatterBuilder >>> and hand craft the builder. >>> >>> I would bias the range toward the past, not the future, I think 25 >>> years in >>> the >>> future is plenty, though in 10 years, it would need to be reviewed. >>> >>> Would it be reasonable to make the baseValue be a settable value >>> in the Builder? Then at least the developer could set the baseValue >>> and then append the pattern to get the desired result. >>> >>> Roger >>> >>> >>> >>> On 4/25/2013 12:08 PM, Stephen Colebourne wrote: >>> >>> On 25 Apr 2013 16:41, "roger riggs" wrote: >>>>> Next, it seems that the behaviour is different to SimpleDateFormat, >>>>> where parsing anything other than the specified width results in a >>>>> pure year, not a year merged with the base year. At the very >>>>> least, we >>>>> need a way to replicate that, so our patterns match SDF. >>>> yes, the patterns will cause the least confusion if they match. >>>> On a related note, should we consider using the heuristic for the >>>> base >>>> year (current - 80)? >>>> Currently it is a bit awkward Year.now().getYear(); developers might >>>> take the shortcut and stick in some value they think is useful but >>>> it will >>>> vary >>>> from app to app and get stale. >>> I think the SDF behaviour linking to current is poor design as any >>> testing >>> you do becomes null and void on Jan 1st. The 2000 base is pretty >>> reasonable >>> for today. Any other fixed JDK choice has real downsides. >>> >>> Stephen >>> >>> > From roger.riggs at oracle.com Thu Apr 25 11:29:21 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Apr 2013 14:29:21 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> Message-ID: <51797601.20003@oracle.com> Hi Stephen,. Do I read this correctly to expand the lenient mode for all number parsing to allow additional digits beyond the maxWidth or is the lenient parsing apply only to ReducePrinterParser? Roger On 4/25/2013 6:07 AM, Stephen Colebourne wrote: > My concern is that this change caters too much for the edge case and > not enough for the typical use case. In the typical use case, the user > just wants to format/parse a fixed 2 digit year. The change to the > builder now means they have to specify two widths, not one. We should > retain the method with one width argument at the very least. > > Next, it seems that the behaviour is different to SimpleDateFormat, > where parsing anything other than the specified width results in a > pure year, not a year merged with the base year. At the very least, we > need a way to replicate that, so our patterns match SDF. > > This would seem sensible behaviour: > * appendValueReduced(YEAR, 2, 2000) > * format = lowest 2 digits of year, zero padded if necessary > * parse-strict = only accept two digits and apply base year > * parse-lenient alone (yy/MM) = parse as though it were > appendValue(YEAR). If 2 digits parsed then apply base year. > * parse-lenient not adjacent (yyMMdd) = parse as though it were > appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed > then apply base year. > * parse-lenient adjacent (MMddyy) = same as parse-strict > > Beyond that, the new method you're proposing seems to be controlling > the maximum width of parsing allowed in lenient mode. I guess that is > fine, but I'm not sure it would see wide applicability. We generally > just say lenient is lenient, and I don't think a maxWidth concept > should apply at all in strict mode in the context of "reduced". > > Sorry this change seems more complex than I expected. > Stephen > > > > On 24 April 2013 23:00, roger riggs wrote: >> Hi, >> >> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >> The parseStrict and parseLenient logic re-introduced so that by default >> the behavior of appendPattern("yyMMdd") will result in a fixed width parse >> unless setLenient is called in the DateTimeFormatterBuilder. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> Please review. >> >> Thanks, Roger >> >> [1] https://github.com/ThreeTen/threeten/issues/218 From xueming.shen at oracle.com Thu Apr 25 11:38:34 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 25 Apr 2013 11:38:34 -0700 Subject: [threeten-dev] Fwd: Re: Review for parsing 2 to 4 years #218 In-Reply-To: <51797473.5090205@oracle.com> References: <51797094.3030401@oracle.com> <51797473.5090205@oracle.com> Message-ID: <5179782A.80502@oracle.com> On 04/25/2013 11:22 AM, roger riggs wrote: > Hi, > > The impetus was less with the appendValueReduced method itself > but to be able to leverage the locale specific date patterns and be able > allow a more flexible UI that would accept a more lenient years to be input. > Understood the requirement, just wonder maybe CLDR should be the one to provide the correct data, maybe two sets of data, yy and yyyy or the utility tool that pulls the data from the CLDR should tweak the data and provide two styles of data with the default base value for the yy, instead of "tweaking" the API to do the guess game. But when the data says yy it should be 2 digits and when it is yyyy, it's 4 digits of year value. The 80/100 years plus minus might be big enough for birthday 20 years ago, but it might be laughable 20 years later...my suggestion is to leave the guess game to the application developer, if it's wrong, it only affects the individual application, if JDK has a wrong guess, especially given our "compatibility, compatibility and compatibility" slogan. But it's a "out of box" suggestion. -Sherman > In the CLDR data there are many forms that include 'yy' that could benifit > the reduced input. There are very few forms that include yyyy. > > Roger > > > On 4/25/2013 2:06 PM, Xueming Shen wrote: >> >> >> Maybe an appendValueReducedAdjusted(..., ValueAdjuster) is something more >> reasonable here? with >> >> interface ValueAdjuster { >> long adjust(TemporaField field, long value); >> } >> >> While myself is really not a fan of this reduced_and_adjusted idea, I think we're >> having enough interface and flexibility already here. But guess it at least has the >> benefit of leaving appendValueReduced to what it is intended, without blurring the >> spec and implementation with a "may/will be wrong in xyz years" base value. >> >> I always input 4 digits when asked during my web experience recently, I don't think >> you can get away with a 2 digits year very often these days when you are being >> asking mm/dd/yyyy... >> >> -Sherman >> >> On 04/25/2013 10:29 AM, Stephen Colebourne wrote: >>> In Joda-Time, the base value is set on the formatter, not the builder. >>> We could do the same, but I don't think its the right option (as we >>> allow anything to be truncated, not just one field. The same problem >>> applies to a bulider-wide base value. Thats why its necessary to tie >>> the base value in to the appendValueReduced(). >>> >>> We could have an appendPattern(String, Map) where the >>> map tells the method what base year to use. But realistically, no-one >>> woud use the method as they might as well use the builder proper at >>> that point. >>> >>> I agree that 2000 may not satisfy the birthdate case, but only >>> something like (current - 100) would really satisfy that. Any other >>> choice is more arbitrary. It would have to be far enough in the future >>> that it won't become out of date (as it is in the spec it really >>> shouldn't be changed in the future). The 1940 to 1950 is just about >>> possible, but effectively makes this API expire in 2040/2050, which no >>> longer feel that far away. >>> >>> A different value per JDK release is also likely to confuse, although >>> is at least more consistent than (current - 80). >>> >>> I might be OK with a value that changes per JDK and once per decade. >>> So the value would be (jdk-release-year-rounded-down-to-decade - 80). >>> Which would be 1930 until a JDK relase in 202x. Although scheduling a >>> task to make that happen in 7 years time would be fun... >>> >>> Stephen >>> >>> >>> On 25 April 2013 17:21, roger riggs wrote: >>>> It depends on the use case, for entering birthdates, SDF make more sense >>>> because it goes back 80 years. Using valueReduced at 2000 goes back only >>>> 13 years. >>>> >>>> For the birthday case, a base of 1940 would be useful for ages up to 73. >>>> Any developer for this case will need to use DateTimeFormatterBuilder >>>> and hand craft the builder. >>>> >>>> I would bias the range toward the past, not the future, I think 25 years in >>>> the >>>> future is plenty, though in 10 years, it would need to be reviewed. >>>> >>>> Would it be reasonable to make the baseValue be a settable value >>>> in the Builder? Then at least the developer could set the baseValue >>>> and then append the pattern to get the desired result. >>>> >>>> Roger >>>> >>>> >>>> >>>> On 4/25/2013 12:08 PM, Stephen Colebourne wrote: >>>> >>>> On 25 Apr 2013 16:41, "roger riggs" wrote: >>>>>> Next, it seems that the behaviour is different to SimpleDateFormat, >>>>>> where parsing anything other than the specified width results in a >>>>>> pure year, not a year merged with the base year. At the very least, we >>>>>> need a way to replicate that, so our patterns match SDF. >>>>> yes, the patterns will cause the least confusion if they match. >>>>> On a related note, should we consider using the heuristic for the base >>>>> year (current - 80)? >>>>> Currently it is a bit awkward Year.now().getYear(); developers might >>>>> take the shortcut and stick in some value they think is useful but it will >>>>> vary >>>>> from app to app and get stale. >>>> I think the SDF behaviour linking to current is poor design as any testing >>>> you do becomes null and void on Jan 1st. The 2000 base is pretty reasonable >>>> for today. Any other fixed JDK choice has real downsides. >>>> >>>> Stephen >>>> >>>> >> > From roger.riggs at oracle.com Thu Apr 25 15:06:45 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Apr 2013 18:06:45 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> Message-ID: <5179A8F5.8090703@oracle.com> Hi, Updated as recommended below: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ One open question is whether lenient parsing of numbers (including ValueReduced) should respect the maxWidth. Currently, NumberPrinterParser uses maxWidth to limit the width of the parse. The ReducedPrinterParser needs an upper bound on the width to parse leniently. Another minor issue is the range of text width and range of BaseValue. The original code allowed field widths of up to 19 but the baseValue was limited to an int and the table of powers of ten was limited to 10 digits. Is there a recommended range for fields that might use ReducedValue parsing? Thanks, Roger On 4/25/2013 6:07 AM, Stephen Colebourne wrote: > My concern is that this change caters too much for the edge case and > not enough for the typical use case. In the typical use case, the user > just wants to format/parse a fixed 2 digit year. The change to the > builder now means they have to specify two widths, not one. We should > retain the method with one width argument at the very least. > > Next, it seems that the behaviour is different to SimpleDateFormat, > where parsing anything other than the specified width results in a > pure year, not a year merged with the base year. At the very least, we > need a way to replicate that, so our patterns match SDF. > > This would seem sensible behaviour: > * appendValueReduced(YEAR, 2, 2000) > * format = lowest 2 digits of year, zero padded if necessary > * parse-strict = only accept two digits and apply base year > * parse-lenient alone (yy/MM) = parse as though it were > appendValue(YEAR). If 2 digits parsed then apply base year. > * parse-lenient not adjacent (yyMMdd) = parse as though it were > appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed > then apply base year. > * parse-lenient adjacent (MMddyy) = same as parse-strict > > Beyond that, the new method you're proposing seems to be controlling > the maximum width of parsing allowed in lenient mode. I guess that is > fine, but I'm not sure it would see wide applicability. We generally > just say lenient is lenient, and I don't think a maxWidth concept > should apply at all in strict mode in the context of "reduced". > > Sorry this change seems more complex than I expected. > Stephen > > > > On 24 April 2013 23:00, roger riggs wrote: >> Hi, >> >> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >> The parseStrict and parseLenient logic re-introduced so that by default >> the behavior of appendPattern("yyMMdd") will result in a fixed width parse >> unless setLenient is called in the DateTimeFormatterBuilder. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> Please review. >> >> Thanks, Roger >> >> [1] https://github.com/ThreeTen/threeten/issues/218 From roger.riggs at oracle.com Thu Apr 25 15:13:20 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Apr 2013 18:13:20 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <5179782A.80502@oracle.com> References: <51797094.3030401@oracle.com> <51797473.5090205@oracle.com> <5179782A.80502@oracle.com> Message-ID: <5179AA80.4090705@oracle.com> Hi Sherman, It might be useful if CLDR would take into account heuristics for two digit parsing but if you've read the leniency descriptions in CLDR, I'd rather leave that up to an implementation especially where it related to a user interface and trying to be locale sensitive. A "floating" baseValue is useful (if well documented) and properly used by developers in user interfaces. If these parsing functions are being used against textual data stored and retrieved then the two digit forms are sensitive to aging and should not be used for persistence. The entire CLDR/LDML infrastructure is more focused on communicating with users not for persistence. Roger On 4/25/2013 2:38 PM, Xueming Shen wrote: > On 04/25/2013 11:22 AM, roger riggs wrote: >> Hi, >> >> The impetus was less with the appendValueReduced method itself >> but to be able to leverage the locale specific date patterns and be able >> allow a more flexible UI that would accept a more lenient years to be >> input. >> > > Understood the requirement, just wonder maybe CLDR should be the one > to provide the correct data, maybe two sets of data, yy and yyyy or the > utility tool that pulls the data from the CLDR should tweak the data and > provide two styles of data with the default base value for the yy, > instead > of "tweaking" the API to do the guess game. But when the data says yy it > should be 2 digits and when it is yyyy, it's 4 digits of year value. > The 80/100 > years plus minus might be big enough for birthday 20 years ago, but it > might > be laughable 20 years later...my suggestion is to leave the guess game to > the application developer, if it's wrong, it only affects the individual > application, if JDK has a wrong guess, especially given our > "compatibility, > compatibility and compatibility" slogan. But it's a "out of box" > suggestion. > > -Sherman > > >> In the CLDR data there are many forms that include 'yy' that could >> benifit >> the reduced input. There are very few forms that include yyyy. >> >> Roger >> >> >> On 4/25/2013 2:06 PM, Xueming Shen wrote: >>> >>> >>> Maybe an appendValueReducedAdjusted(..., ValueAdjuster) is something >>> more >>> reasonable here? with >>> >>> interface ValueAdjuster { >>> long adjust(TemporaField field, long value); >>> } >>> >>> While myself is really not a fan of this reduced_and_adjusted idea, >>> I think we're >>> having enough interface and flexibility already here. But guess it >>> at least has the >>> benefit of leaving appendValueReduced to what it is intended, >>> without blurring the >>> spec and implementation with a "may/will be wrong in xyz years" base >>> value. >>> >>> I always input 4 digits when asked during my web experience >>> recently, I don't think >>> you can get away with a 2 digits year very often these days when you >>> are being >>> asking mm/dd/yyyy... >>> >>> -Sherman >>> >>> On 04/25/2013 10:29 AM, Stephen Colebourne wrote: >>>> In Joda-Time, the base value is set on the formatter, not the >>>> builder. >>>> We could do the same, but I don't think its the right option (as we >>>> allow anything to be truncated, not just one field. The same problem >>>> applies to a bulider-wide base value. Thats why its necessary to tie >>>> the base value in to the appendValueReduced(). >>>> >>>> We could have an appendPattern(String, Map) where the >>>> map tells the method what base year to use. But realistically, no-one >>>> woud use the method as they might as well use the builder proper at >>>> that point. >>>> >>>> I agree that 2000 may not satisfy the birthdate case, but only >>>> something like (current - 100) would really satisfy that. Any other >>>> choice is more arbitrary. It would have to be far enough in the >>>> future >>>> that it won't become out of date (as it is in the spec it really >>>> shouldn't be changed in the future). The 1940 to 1950 is just about >>>> possible, but effectively makes this API expire in 2040/2050, >>>> which no >>>> longer feel that far away. >>>> >>>> A different value per JDK release is also likely to confuse, although >>>> is at least more consistent than (current - 80). >>>> >>>> I might be OK with a value that changes per JDK and once per decade. >>>> So the value would be (jdk-release-year-rounded-down-to-decade - 80). >>>> Which would be 1930 until a JDK relase in 202x. Although scheduling a >>>> task to make that happen in 7 years time would be fun... >>>> >>>> Stephen >>>> >>>> >>>> On 25 April 2013 17:21, roger riggs wrote: >>>>> It depends on the use case, for entering birthdates, SDF make >>>>> more sense >>>>> because it goes back 80 years. Using valueReduced at 2000 goes >>>>> back only >>>>> 13 years. >>>>> >>>>> For the birthday case, a base of 1940 would be useful for ages up >>>>> to 73. >>>>> Any developer for this case will need to use >>>>> DateTimeFormatterBuilder >>>>> and hand craft the builder. >>>>> >>>>> I would bias the range toward the past, not the future, I think >>>>> 25 years in >>>>> the >>>>> future is plenty, though in 10 years, it would need to be reviewed. >>>>> >>>>> Would it be reasonable to make the baseValue be a settable value >>>>> in the Builder? Then at least the developer could set the baseValue >>>>> and then append the pattern to get the desired result. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> On 4/25/2013 12:08 PM, Stephen Colebourne wrote: >>>>> >>>>> On 25 Apr 2013 16:41, "roger riggs" wrote: >>>>>>> Next, it seems that the behaviour is different to >>>>>>> SimpleDateFormat, >>>>>>> where parsing anything other than the specified width results in a >>>>>>> pure year, not a year merged with the base year. At the very >>>>>>> least, we >>>>>>> need a way to replicate that, so our patterns match SDF. >>>>>> yes, the patterns will cause the least confusion if they match. >>>>>> On a related note, should we consider using the heuristic for >>>>>> the base >>>>>> year (current - 80)? >>>>>> Currently it is a bit awkward Year.now().getYear(); developers >>>>>> might >>>>>> take the shortcut and stick in some value they think is useful >>>>>> but it will >>>>>> vary >>>>>> from app to app and get stale. >>>>> I think the SDF behaviour linking to current is poor design as >>>>> any testing >>>>> you do becomes null and void on Jan 1st. The 2000 base is pretty >>>>> reasonable >>>>> for today. Any other fixed JDK choice has real downsides. >>>>> >>>>> Stephen >>>>> >>>>> >>> >> > From xueming.shen at oracle.com Thu Apr 25 16:03:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 25 Apr 2013 16:03:01 -0700 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <5179A8F5.8090703@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> Message-ID: <5179B625.4060802@oracle.com> Do we expect this new appendValueReduced(field, minwidth, maxwidth, basevaluse) method provide benefit for any other temporal field? or it most likely will only be used for the special yy/uu->yyyy parsing? My limited knowledge/experience does not bring in any other usage for other field (other calendar system?). If this is the case, maybe it should simply be more specific as appendYearValueReduced(baseValue)? with the specific description of supporting 2 digits year and 4 digits year formatting/parsing? -Sherman On 04/25/2013 03:06 PM, roger riggs wrote: > Hi, > > Updated as recommended below: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ > > One open question is whether lenient parsing of numbers (including > ValueReduced) should respect the maxWidth. > Currently, NumberPrinterParser uses maxWidth to limit the width of the parse. > The ReducedPrinterParser needs an upper bound on the width to parse > leniently. > > Another minor issue is the range of text width and range of BaseValue. > The original code allowed field widths of up to 19 but the baseValue > was limited to an int and the table of powers of ten was limited to 10 digits. > Is there a recommended range for fields that might use ReducedValue parsing? > > Thanks, Roger > > > On 4/25/2013 6:07 AM, Stephen Colebourne wrote: >> My concern is that this change caters too much for the edge case and >> not enough for the typical use case. In the typical use case, the user >> just wants to format/parse a fixed 2 digit year. The change to the >> builder now means they have to specify two widths, not one. We should >> retain the method with one width argument at the very least. >> >> Next, it seems that the behaviour is different to SimpleDateFormat, >> where parsing anything other than the specified width results in a >> pure year, not a year merged with the base year. At the very least, we >> need a way to replicate that, so our patterns match SDF. >> >> This would seem sensible behaviour: >> * appendValueReduced(YEAR, 2, 2000) >> * format = lowest 2 digits of year, zero padded if necessary >> * parse-strict = only accept two digits and apply base year >> * parse-lenient alone (yy/MM) = parse as though it were >> appendValue(YEAR). If 2 digits parsed then apply base year. >> * parse-lenient not adjacent (yyMMdd) = parse as though it were >> appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed >> then apply base year. >> * parse-lenient adjacent (MMddyy) = same as parse-strict >> >> Beyond that, the new method you're proposing seems to be controlling >> the maximum width of parsing allowed in lenient mode. I guess that is >> fine, but I'm not sure it would see wide applicability. We generally >> just say lenient is lenient, and I don't think a maxWidth concept >> should apply at all in strict mode in the context of "reduced". >> >> Sorry this change seems more complex than I expected. >> Stephen >> >> >> >> On 24 April 2013 23:00, roger riggs wrote: >>> Hi, >>> >>> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >>> The parseStrict and parseLenient logic re-introduced so that by default >>> the behavior of appendPattern("yyMMdd") will result in a fixed width parse >>> unless setLenient is called in the DateTimeFormatterBuilder. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>> >>> Please review. >>> >>> Thanks, Roger >>> >>> [1] https://github.com/ThreeTen/threeten/issues/218 > From roger.riggs at oracle.com Fri Apr 26 06:52:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 26 Apr 2013 09:52:51 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <5179B625.4060802@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <5179B625.4060802@oracle.com> Message-ID: <517A86B3.5030602@oracle.com> Hi Sherman, True, common use case is for fields that are years. But there are several year fields: YEAR, YEAR_OF_ERA, and the localized WEEK_BASED_YEARs so the field argument can't be removed. I don't think the method will be used extensively but would prefer to keep it flexible. Roger On 4/25/2013 7:03 PM, Xueming Shen wrote: > > Do we expect this new appendValueReduced(field, minwidth, maxwidth, > basevaluse) > method provide benefit for any other temporal field? or it most likely > will only be used > for the special yy/uu->yyyy parsing? My limited knowledge/experience > does not bring > in any other usage for other field (other calendar system?). If this > is the case, maybe it > should simply be more specific as appendYearValueReduced(baseValue)? > with the specific > description of supporting 2 digits year and 4 digits year > formatting/parsing? > > -Sherman > > > On 04/25/2013 03:06 PM, roger riggs wrote: >> Hi, >> >> Updated as recommended below: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> One open question is whether lenient parsing of numbers (including >> ValueReduced) should respect the maxWidth. >> Currently, NumberPrinterParser uses maxWidth to limit the width of >> the parse. >> The ReducedPrinterParser needs an upper bound on the width to parse >> leniently. >> >> Another minor issue is the range of text width and range of BaseValue. >> The original code allowed field widths of up to 19 but the baseValue >> was limited to an int and the table of powers of ten was limited to >> 10 digits. >> Is there a recommended range for fields that might use ReducedValue >> parsing? >> >> Thanks, Roger >> >> >> On 4/25/2013 6:07 AM, Stephen Colebourne wrote: >>> My concern is that this change caters too much for the edge case and >>> not enough for the typical use case. In the typical use case, the user >>> just wants to format/parse a fixed 2 digit year. The change to the >>> builder now means they have to specify two widths, not one. We should >>> retain the method with one width argument at the very least. >>> >>> Next, it seems that the behaviour is different to SimpleDateFormat, >>> where parsing anything other than the specified width results in a >>> pure year, not a year merged with the base year. At the very least, we >>> need a way to replicate that, so our patterns match SDF. >>> >>> This would seem sensible behaviour: >>> * appendValueReduced(YEAR, 2, 2000) >>> * format = lowest 2 digits of year, zero padded if necessary >>> * parse-strict = only accept two digits and apply base year >>> * parse-lenient alone (yy/MM) = parse as though it were >>> appendValue(YEAR). If 2 digits parsed then apply base year. >>> * parse-lenient not adjacent (yyMMdd) = parse as though it were >>> appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed >>> then apply base year. >>> * parse-lenient adjacent (MMddyy) = same as parse-strict >>> >>> Beyond that, the new method you're proposing seems to be controlling >>> the maximum width of parsing allowed in lenient mode. I guess that is >>> fine, but I'm not sure it would see wide applicability. We generally >>> just say lenient is lenient, and I don't think a maxWidth concept >>> should apply at all in strict mode in the context of "reduced". >>> >>> Sorry this change seems more complex than I expected. >>> Stephen >>> >>> >>> >>> On 24 April 2013 23:00, roger riggs wrote: >>>> Hi, >>>> >>>> Cleanup of the changes for addValueReduced and the >>>> ReducedPrinterParser. >>>> The parseStrict and parseLenient logic re-introduced so that by >>>> default >>>> the behavior of appendPattern("yyMMdd") will result in a fixed >>>> width parse >>>> unless setLenient is called in the DateTimeFormatterBuilder. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>>> >>>> Please review. >>>> >>>> Thanks, Roger >>>> >>>> [1] https://github.com/ThreeTen/threeten/issues/218 >> > From scolebourne at joda.org Fri Apr 26 07:21:33 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 26 Apr 2013 15:21:33 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <5179A8F5.8090703@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> Message-ID: Your parseAdjacent test in TestReducedPrinter should be in TestReducedParser Looking at the TestReducedParser.parseAll test cases, I'd expect this {YEAR, 2, 2010, "123", 0, 2, 2012}, to parse year 123 in lenient mode {YEAR, 1, 2010, "10", 0, 1, 1}, {YEAR, 1, 2005, "21", 0, 1, 2}, Similarly, these should parse 10 and 21 in lenient mode. {YEAR, 2, 2010, "321", 0, 2, 2032}, {YEAR, 2, 2010, "54321", 0, 2, 2054}, Simlarly, parsing 321 and 54321 in lenient mode. The parseStrict cases result in weird things {YEAR, 1, 2, 2010, "12", 0, 1, 1}, {YEAR, 1, 4, 2010, "21", 0, 1, 2}, Thats because the second method with two widths doesn't make sense here. I still think we should delete the method with the extra argument. The method with a single width should parse up to a sensible maximum width in lenient mode (where permitted by adjacent value parsing). I don't think the Javadoc of the original method now describes what happens when leniently parsing less than the specified width. It should clearly desribe strict vs lenient, and lenient matching width vs lenient absorb anything available. The maximum field width is generally 19, to allow for long values. But 10 (for int values) is also avalid option if documented. NumberPrinterParser should also parse up to 19 digits in lenient mode (where permitted by adjacent value parsing). Stephen On 25 April 2013 23:06, roger riggs wrote: > Hi, > > Updated as recommended below: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ > > One open question is whether lenient parsing of numbers (including > ValueReduced) should respect the maxWidth. > Currently, NumberPrinterParser uses maxWidth to limit the width of the > parse. > The ReducedPrinterParser needs an upper bound on the width to parse > leniently. > > Another minor issue is the range of text width and range of BaseValue. > The original code allowed field widths of up to 19 but the baseValue > was limited to an int and the table of powers of ten was limited to 10 > digits. > Is there a recommended range for fields that might use ReducedValue parsing? > > Thanks, Roger > > > > On 4/25/2013 6:07 AM, Stephen Colebourne wrote: >> >> My concern is that this change caters too much for the edge case and >> not enough for the typical use case. In the typical use case, the user >> just wants to format/parse a fixed 2 digit year. The change to the >> builder now means they have to specify two widths, not one. We should >> retain the method with one width argument at the very least. >> >> Next, it seems that the behaviour is different to SimpleDateFormat, >> where parsing anything other than the specified width results in a >> pure year, not a year merged with the base year. At the very least, we >> need a way to replicate that, so our patterns match SDF. >> >> This would seem sensible behaviour: >> * appendValueReduced(YEAR, 2, 2000) >> * format = lowest 2 digits of year, zero padded if necessary >> * parse-strict = only accept two digits and apply base year >> * parse-lenient alone (yy/MM) = parse as though it were >> appendValue(YEAR). If 2 digits parsed then apply base year. >> * parse-lenient not adjacent (yyMMdd) = parse as though it were >> appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed >> then apply base year. >> * parse-lenient adjacent (MMddyy) = same as parse-strict >> >> Beyond that, the new method you're proposing seems to be controlling >> the maximum width of parsing allowed in lenient mode. I guess that is >> fine, but I'm not sure it would see wide applicability. We generally >> just say lenient is lenient, and I don't think a maxWidth concept >> should apply at all in strict mode in the context of "reduced". >> >> Sorry this change seems more complex than I expected. >> Stephen >> >> >> >> On 24 April 2013 23:00, roger riggs wrote: >>> >>> Hi, >>> >>> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >>> The parseStrict and parseLenient logic re-introduced so that by default >>> the behavior of appendPattern("yyMMdd") will result in a fixed width >>> parse >>> unless setLenient is called in the DateTimeFormatterBuilder. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>> >>> Please review. >>> >>> Thanks, Roger >>> >>> [1] https://github.com/ThreeTen/threeten/issues/218 > > From roger.riggs at oracle.com Fri Apr 26 08:14:50 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 26 Apr 2013 11:14:50 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> Message-ID: <517A99EA.7010304@oracle.com> Hi, On 4/26/2013 10:21 AM, Stephen Colebourne wrote: > Your parseAdjacent test in TestReducedPrinter should be in TestReducedParser It is misnamed, it is a printing test to confirm that the output is 2 digits when the value is in range of the baseValue and the truncates to maxWidth otherwise. > > Looking at the TestReducedParser.parseAll test cases, I'd expect this > {YEAR, 2, 2010, "123", 0, 2, 2012}, > to parse year 123 in lenient mode Except that with fixed width of 2, lenient is disabled, see below > > {YEAR, 1, 2010, "10", 0, 1, 1}, > {YEAR, 1, 2005, "21", 0, 1, 2}, > Similarly, these should parse 10 and 21 in lenient mode. > > {YEAR, 2, 2010, "321", 0, 2, 2032}, > {YEAR, 2, 2010, "54321", 0, 2, 2054}, > Simlarly, parsing 321 and 54321 in lenient mode. > > The parseStrict cases result in weird things > {YEAR, 1, 2, 2010, "12", 0, 1, 1}, > {YEAR, 1, 4, 2010, "21", 0, 1, 2}, > Thats because the second method with two widths doesn't make sense here. > > I still think we should delete the method with the extra argument. The > method with a single width should parse up to a sensible maximum width > in lenient mode (where permitted by adjacent value parsing). The problem arises that with a single width min=max, the logic for min == max never does the setup of valueParserIndex that accumulates subsequentWidths. So the number parser in lenient mode consumes all the input and leaves nothing for the rest of the fields. Only a variable width field triggers the logic for adjacent value mode. See appendValue(field, min, max, signstyle) I coded that up and it didn't work. I opted not to try to redesign that mechanism but make the reduceValue not a fixed width field. > > I don't think the Javadoc of the original method now describes what > happens when leniently parsing less than the specified width. It > should clearly desribe strict vs lenient, and lenient matching width > vs lenient absorb anything available. > > > The maximum field width is generally 19, to allow for long values. But > 10 (for int values) is also avalid option if documented. > > NumberPrinterParser should also parse up to 19 digits in lenient mode > (where permitted by adjacent value parsing). As above, a fixed width field can't be made lenient because the subsequentWidth is never accumulated after a fixedWidth field. Suggestions? Thanks, Roger > > Stephen > > > > On 25 April 2013 23:06, roger riggs wrote: >> Hi, >> >> Updated as recommended below: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> One open question is whether lenient parsing of numbers (including >> ValueReduced) should respect the maxWidth. >> Currently, NumberPrinterParser uses maxWidth to limit the width of the >> parse. >> The ReducedPrinterParser needs an upper bound on the width to parse >> leniently. >> >> Another minor issue is the range of text width and range of BaseValue. >> The original code allowed field widths of up to 19 but the baseValue >> was limited to an int and the table of powers of ten was limited to 10 >> digits. >> Is there a recommended range for fields that might use ReducedValue parsing? >> >> Thanks, Roger >> >> >> >> On 4/25/2013 6:07 AM, Stephen Colebourne wrote: >>> My concern is that this change caters too much for the edge case and >>> not enough for the typical use case. In the typical use case, the user >>> just wants to format/parse a fixed 2 digit year. The change to the >>> builder now means they have to specify two widths, not one. We should >>> retain the method with one width argument at the very least. >>> >>> Next, it seems that the behaviour is different to SimpleDateFormat, >>> where parsing anything other than the specified width results in a >>> pure year, not a year merged with the base year. At the very least, we >>> need a way to replicate that, so our patterns match SDF. >>> >>> This would seem sensible behaviour: >>> * appendValueReduced(YEAR, 2, 2000) >>> * format = lowest 2 digits of year, zero padded if necessary >>> * parse-strict = only accept two digits and apply base year >>> * parse-lenient alone (yy/MM) = parse as though it were >>> appendValue(YEAR). If 2 digits parsed then apply base year. >>> * parse-lenient not adjacent (yyMMdd) = parse as though it were >>> appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed >>> then apply base year. >>> * parse-lenient adjacent (MMddyy) = same as parse-strict >>> >>> Beyond that, the new method you're proposing seems to be controlling >>> the maximum width of parsing allowed in lenient mode. I guess that is >>> fine, but I'm not sure it would see wide applicability. We generally >>> just say lenient is lenient, and I don't think a maxWidth concept >>> should apply at all in strict mode in the context of "reduced". >>> >>> Sorry this change seems more complex than I expected. >>> Stephen >>> >>> >>> >>> On 24 April 2013 23:00, roger riggs wrote: >>>> Hi, >>>> >>>> Cleanup of the changes for addValueReduced and the ReducedPrinterParser. >>>> The parseStrict and parseLenient logic re-introduced so that by default >>>> the behavior of appendPattern("yyMMdd") will result in a fixed width >>>> parse >>>> unless setLenient is called in the DateTimeFormatterBuilder. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >>>> >>>> Please review. >>>> >>>> Thanks, Roger >>>> >>>> [1] https://github.com/ThreeTen/threeten/issues/218 >> From scolebourne at joda.org Fri Apr 26 11:13:57 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 26 Apr 2013 19:13:57 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517A99EA.7010304@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> Message-ID: On 26 April 2013 16:14, roger riggs wrote: > Suggestions? I think we should start with a set of test cases we agree on. Then whatever code needs to be changed will have to be changed. It sounds like the adjacent value parsing mechanism will need some tweaking. Stephen From roger.riggs at oracle.com Fri Apr 26 12:32:25 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 26 Apr 2013 15:32:25 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> Message-ID: <517AD649.4000902@oracle.com> Hi, Start with a hard one. "yyMMdd" in the case where ReducedValue/NumberPP is set to lenient. "76321" could be parsed as (76, 3, 21) or (76, 32, 1) "765432" could be parsed several ways. (76, 5, 432) (76, 54, 32), etc. The subsequentWidth mechanism only works for fixed fields following a variable width field. If the parsing is set to lenient then what was a fixed field is now variable but the static mechanism for lookahead can't anticipate that. The current mechanism works fine as long as fixed width fields have the same width whether lenient or strict. I think it is unnecessary and too big a change to modify NumberPP to extend lenient parsing to fixed width fields. Roger On 4/26/2013 2:13 PM, Stephen Colebourne wrote: > On 26 April 2013 16:14, roger riggs wrote: >> Suggestions? > I think we should start with a set of test cases we agree on. Then > whatever code needs to be changed will have to be changed. It sounds > like the adjacent value parsing mechanism will need some tweaking. > > Stephen From scolebourne at joda.org Fri Apr 26 13:00:13 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 26 Apr 2013 21:00:13 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517AD649.4000902@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> <517AD649.4000902@oracle.com> Message-ID: On 26 Apr 2013 20:32, "roger riggs" wrote: > Start with a hard one. "yyMMdd" in the case where ReducedValue/NumberPP is set to lenient. > > "76321" could be parsed as (76, 3, 21) or (76, 32, 1) Should be 7, 63, 21 > "765432" could be parsed several ways. (76, 5, 432) (76, 54, 32), etc. 76 54 32 The first is variable and the others fixed. Thus lenient could only impact the first if others are fixed width. Stephen > The subsequentWidth mechanism only works for fixed fields > following a variable width field. If the parsing is set to lenient > then what was a fixed field is now variable but the static mechanism > for lookahead can't anticipate that. > > The current mechanism works fine as long as fixed width fields > have the same width whether lenient or strict. I think it is unnecessary > and too big a change to modify NumberPP to extend lenient parsing to > fixed width fields. > > Roger > > > > > On 4/26/2013 2:13 PM, Stephen Colebourne wrote: >> >> On 26 April 2013 16:14, roger riggs wrote: >>> >>> Suggestions? >> >> I think we should start with a set of test cases we agree on. Then >> whatever code needs to be changed will have to be changed. It sounds >> like the adjacent value parsing mechanism will need some tweaking. >> >> Stephen > > From roger.riggs at oracle.com Fri Apr 26 13:35:30 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 26 Apr 2013 16:35:30 -0400 Subject: [threeten-dev] #263 performance of getAvailableChronologies Message-ID: <517AE512.9010407@oracle.com> Please Review: A startup time concern [1] is the initialization of all of the HijrahChronologies whether they are used by an application or not. This change delays reading the HijrahChronology specific data until the first time it is needed. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-chrono-init-263/ Roger [1] https://github.com/ThreeTen/threeten/issues/263 From scolebourne at joda.org Fri Apr 26 16:39:26 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 27 Apr 2013 00:39:26 +0100 Subject: [threeten-dev] #263 performance of getAvailableChronologies In-Reply-To: <517AE512.9010407@oracle.com> References: <517AE512.9010407@oracle.com> Message-ID: Shouldn't the boolean init flag be volatile? Otherwise looks ok. Stephen On 26 April 2013 21:35, roger riggs wrote: > Please Review: > > A startup time concern [1] is the initialization of all of the > HijrahChronologies > whether they are used by an application or not. This change delays > reading the HijrahChronology specific data until the first time it is > needed. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-chrono-init-263/ > > Roger > > [1] https://github.com/ThreeTen/threeten/issues/263 From dingxmin at linux.vnet.ibm.com Sat Apr 27 00:00:24 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Sat, 27 Apr 2013 15:00:24 +0800 Subject: [threeten-dev] A potential bug in JapaneseDate.of(Era era, int yearOfEra, int month, int dayOfMonth) Message-ID: <517B7788.2080006@linux.vnet.ibm.com> Hi Threeten guys, Our Japanese test team found out a bug when calling JapaneseDate.of(Era era, int yearOfEra, int month, int dayOfMonth). See the code below. JapaneseDate date = JapaneseDate.of(java.time.chrono.JapaneseEra.HEISEI, 1, 1, 7); Heisei era starts in Heisei 1/1/8 which implies Heisei 1/1/7 is invalid. According to its spec [1], It throws DateTimeException - if the value of any field is out of range, or if the day-of-month is invalid for the month-year, or if the date is not a Japanese era. So the correct behavior is observing DateTimeException for the code above. What's your opinion of it? Best regards, Frank [1] http://download.java.net/jdk8/docs/api/java/time/chrono/JapaneseDate.html#of%28java.time.chrono.Era,%20int,%20int,%20int%29 From dingxmin at linux.vnet.ibm.com Sat Apr 27 00:18:16 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Sat, 27 Apr 2013 15:18:16 +0800 Subject: [threeten-dev] SimpleDateFormat and DateTimeFormatter produce different result for JapaneseDate Message-ID: <517B7BB8.1090408@linux.vnet.ibm.com> Hi threeten guys Another issue was discovered in recent date time code (b87). Below is the test case. Locale jplocale = new Locale("ja", "JP", "JP"); String str; String pattern = "GGGGyyyy\u5e74 MMMM d\u65e5"; System.out.println("--- Calendar SimpleDateFormst ---"); Calendar cal = Calendar.getInstance(); cal.set(1989,0,8); // = Heisei 1 SimpleDateFormat format = new SimpleDateFormat(pattern, jplocale); str = format.format(cal.getTime()); System.out.println("\""+pattern+"\" "+str); System.out.println("--- JapaneseDate DateTimeFormatter ---"); JapaneseDate date = JapaneseDate.of(1989,1,8); DateTimeFormatter dtf = DateTimeFormatter.ofPattern(pattern).withLocale(jplocale); str = date.format(dtf); System.out.println("\""+pattern+"\" "+str); The actual output is (Converted Japanese characters to Unicode by native2ascii command) > --- Calendar SimpleDateFormst --- > "GGGGyyyy\u5e74 MMMM d\u65e5" \u5e73\u6210\u5143\u5e74 1\u6708 8\u65e5 > --- JapaneseDate DateTimeFormatter --- > "GGGGyyyy\u5e74 MMMM d\u65e5" Heisei0001\u5e74 1\u6708 8\u65e5 It looks like a bug in DateTimeFormatter. Could anybody take a look at it and confirm? Best regards, Frank From dingxmin at linux.vnet.ibm.com Sat Apr 27 00:51:56 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Sat, 27 Apr 2013 15:51:56 +0800 Subject: [threeten-dev] Host Locale Provider cannot get Japanese DayOfWeek Message-ID: <517B839C.4000401@linux.vnet.ibm.com> Hi threeten guys, A bug was found in b87 when Host Locale Provider was used, "Day name in week" and "AM/PM mark" become blank in Japanese environment. Locale locale = new Locale("ja","JP","JP"); SimpleDateFormat df = new SimpleDateFormat("GGGG yyyy.MM.dd '('E')' a hh:mm:ss zzz", locale); System.out.println(df.format(new Date())); The expected output is "\u5e73\u6210 25.04.19 (\u91d1) \u5348\u5f8c 06:28:59 JST" or "?? 25.04.27 (?) ?? 03:47:28 CST", which can be obtained by specifying JRE as locale provider (-Djava.locale.providers=JRE). However, it's now "Heisei 25.04.19 () 06:24:02 JST " when option "-Djava.locale.providers=HOST" is specified. Can anybody take a look at it and confirm? Best regards, Frank From dingxmin at linux.vnet.ibm.com Sat Apr 27 01:00:02 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Sat, 27 Apr 2013 16:00:02 +0800 Subject: [threeten-dev] Host Locale Provider cannot get Japanese DayOfWeek In-Reply-To: <517B839C.4000401@linux.vnet.ibm.com> References: <517B839C.4000401@linux.vnet.ibm.com> Message-ID: <517B8582.5040503@linux.vnet.ibm.com> Forgot to mention that the era Heisei should be actually translated to Japanese characters for HOST locale provider. Best regards, Frank On 4/27/2013 3:51 PM, Frank Ding wrote: > Hi threeten guys, > A bug was found in b87 when Host Locale Provider was used, "Day name > in week" and "AM/PM mark" become blank in Japanese environment. > > Locale locale = new Locale("ja","JP","JP"); > SimpleDateFormat df = new SimpleDateFormat("GGGG yyyy.MM.dd '('E')' a > hh:mm:ss zzz", locale); > System.out.println(df.format(new Date())); > > The expected output is "\u5e73\u6210 25.04.19 (\u91d1) \u5348\u5f8c > 06:28:59 JST" or "?? 25.04.27 (?) ?? 03:47:28 CST", which can be > obtained by specifying JRE as locale provider > (-Djava.locale.providers=JRE). However, it's now "Heisei 25.04.19 () > 06:24:02 JST > " when option "-Djava.locale.providers=HOST" is specified. > > Can anybody take a look at it and confirm? > > Best regards, > Frank > > > > From roger.riggs at oracle.com Sat Apr 27 11:45:48 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 27 Apr 2013 14:45:48 -0400 Subject: [threeten-dev] #263 performance of getAvailableChronologies In-Reply-To: References: <517AE512.9010407@oracle.com> Message-ID: <517C1CDC.4000106@oracle.com> Hi, Strictly speaking since if a thread doesn't see the value change from false to true (by another thread) it just pays the extra overhead of reloading the data; but the computation is identical. I have changed it to use volatile. It will have a small performance negative impact. Thanks ,Roger On 4/26/2013 7:39 PM, Stephen Colebourne wrote: > Shouldn't the boolean init flag be volatile? Otherwise looks ok. > Stephen > > On 26 April 2013 21:35, roger riggs wrote: >> Please Review: >> >> A startup time concern [1] is the initialization of all of the >> HijrahChronologies >> whether they are used by an application or not. This change delays >> reading the HijrahChronology specific data until the first time it is >> needed. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-chrono-init-263/ >> >> Roger >> >> [1] https://github.com/ThreeTen/threeten/issues/263 From roger.riggs at oracle.com Sat Apr 27 12:06:31 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 27 Apr 2013 19:06:31 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130427190717.9F07148664@hg.openjdk.java.net> Changeset: bfd5f5ef2281 Author: rriggs Date: 2013-04-27 14:40 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bfd5f5ef2281 #263 Performance of Localized calendar initializations Defer the reading of the HijrahChronology data until it is first needed. Update a crude test of the time it takes to list the available Chronologies ! src/share/classes/java/time/chrono/HijrahChronology.java ! test/java/time/test/java/time/chrono/TestChronologyPerf.java Changeset: d8e31d2dd5a7 Author: rriggs Date: 2013-04-27 15:04 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d8e31d2dd5a7 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/time/chrono/HijrahChronology.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/java/time/tck/java/time/TestChronology.java ! test/java/time/tck/java/time/chrono/TCKChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java ! test/java/time/test/java/time/chrono/TestChronologyPerf.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/javax/script/RhinoExceptionTest.java From patrick.zhang at oracle.com Sat Apr 27 20:35:12 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Sun, 28 Apr 2013 11:35:12 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.JapaneseChronology, HijrahChronology and ThaiBuddhistChronology In-Reply-To: <513597AD.8080306@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> Message-ID: <517C98F0.3020603@oracle.com> Hi Team, The new added webrev is similar with |http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/webrev/ , which is only for MinguoChronology. In the new webrev we add test cases for below similar function in JapaneseChronology, HijrahChronology and ThaiBuddhistChronology |1. check new factory method. |* date*(Era era, int yearOfEra, int month, int dayOfMonth) ||*dateYearDay*(Era era, int yearOfEra, int dayOfYear)| 2. check now() related function in MinguoChronology and MinguoDate. |*dateNow*()| |*dateNow*(Clock clock)| |*dateNow*(ZoneId zone)| webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKHijrahChronology.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKJapaneseChronology.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKThaiBuddhistChronology.jtr Regards Patrick | | From patrick.zhang at oracle.com Sat Apr 27 20:48:39 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Sun, 28 Apr 2013 11:48:39 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.Year and YearMonth In-Reply-To: <517C98F0.3020603@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> Message-ID: <517C9C17.9090402@oracle.com> Hi Team, Please help to review new added test case for java.time.Year and java.time.YearMonth. The webrev has been reviewed about before 1 month. But I forget to request it for pushing because of repo building problem on past. Now it has been modified according to latest test code and run again. :) Included apis: plus(long, TemporalUnit) minus(long, TemporalUnit) plus(TemporalAmount) minus(TemporalAmount) with(TemporalField, long) with(TemporalAdjuster) webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/webrev/ Test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYear.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYearMonth.jtr From patrick.zhang at oracle.com Sat Apr 27 21:44:03 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Sun, 28 Apr 2013 12:44:03 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.ZoneOffset In-Reply-To: <517C9C17.9090402@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> <517C9C17.9090402@oracle.com> Message-ID: <517CA913.1080604@oracle.com> Hi Team, Please help to review new added test case for ZoneOffset. Roughly it is only for adjustInto() method. And the test logic is simple: When it is "adjustInto" to one ZonedDateTime, offset of new generated ZonedDateTime will NOT be changed. It is because ZonedDateTime initialized by specific zoneId will have one fixed offset, if we ignore the DST. When it is "adjustInto" to one OffsetDateTime, offset of new generated OffsetDateTime will be changed. Webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/ZoneOffset/webrev/ Test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/ZoneOffset/TCKZoneOffset.jtr Regards Patrick From patrick.zhang at oracle.com Sat Apr 27 21:44:49 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Sun, 28 Apr 2013 12:44:49 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.OffsetTime In-Reply-To: <517C9C17.9090402@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> <517C9C17.9090402@oracle.com> Message-ID: <517CA941.7070006@oracle.com> Hi Team, Please help to review new test cases for OffsetTime.periodUntil(). The test logic is simple, as description in javadoc: ============= When two OffsetTime have different Offset, then the specified end time will be normalized to have same offset with start time. ============= Then 01:01:01+10:00 to 02:01:01+10:00 should be 1 hour while 01:01:01+10:00 to 02:01:01+9:00 should be 2 hours. Webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetTime/webrev/ Test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetTime/TCKOffsetTime.jtr Regards Patrick From Roger.Riggs at Oracle.com Sun Apr 28 19:09:09 2013 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sun, 28 Apr 2013 22:09:09 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> <517AD649.4000902@oracle.com> Message-ID: <517DD645.7070800@Oracle.com> Hi, The remaining problem is that the pattern "MMdd" or the equivalent builder appends of "Value(2), Value(2)", is not recognized as using adjacent parsing. When set to lenient the NumberPP parse of "MM" gobbles up all the input leaving nothing for 'dd'. (This is a new issue since NumberPP in lenient mode is no longer limited to maxWidth). If the field is marked as withfixedWidth (subsequentWidth == -1) the field is no longer lenient. The problem that remains is that a field identified by the builder (minWidth == maxWidth) as fixed width may not actually be fixed width at the time the PP is invoked. I am inclined to think that adjacent value mode must always be engaged, even for fixed fields. The first fixed field must be informed that it is followed by fixed fields. Roger On 4/26/2013 4:00 PM, Stephen Colebourne wrote: > > On 26 Apr 2013 20:32, "roger riggs" > wrote: > > Start with a hard one. "yyMMdd" in the case where > ReducedValue/NumberPP is set to lenient. > > > > "76321" could be parsed as (76, 3, 21) or (76, 32, 1) > > Should be 7, 63, 21 > > > "765432" could be parsed several ways. (76, 5, 432) (76, 54, 32), etc. > > 76 54 32 > > The first is variable and the others fixed. Thus lenient could only > impact the first if others are fixed width. > Stephen > > > The subsequentWidth mechanism only works for fixed fields > > following a variable width field. If the parsing is set to lenient > > then what was a fixed field is now variable but the static mechanism > > for lookahead can't anticipate that. > > > > The current mechanism works fine as long as fixed width fields > > have the same width whether lenient or strict. I think it is > unnecessary > > and too big a change to modify NumberPP to extend lenient parsing to > > fixed width fields. > > > > Roger > > > > > > > > > > On 4/26/2013 2:13 PM, Stephen Colebourne wrote: > >> > >> On 26 April 2013 16:14, roger riggs > wrote: > >>> > >>> Suggestions? > >> > >> I think we should start with a set of test cases we agree on. Then > >> whatever code needs to be changed will have to be changed. It sounds > >> like the adjacent value parsing mechanism will need some tweaking. > >> > >> Stephen > > > > > From scolebourne at joda.org Mon Apr 29 04:48:24 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 29 Apr 2013 12:48:24 +0100 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.JapaneseChronology, HijrahChronology and ThaiBuddhistChronology In-Reply-To: <517C98F0.3020603@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> Message-ID: Looks good to me. Stephen On 28 April 2013 04:35, Patrick Zhang wrote: > Hi Team, > > The new added webrev is similar with > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/webrev/, > which is only for MinguoChronology. > > In the new webrev we add test cases for below similar function in > JapaneseChronology, HijrahChronology and ThaiBuddhistChronology > > 1. check new factory method. > date(Era era, int yearOfEra, int month, int dayOfMonth) > dateYearDay(Era era, int yearOfEra, int dayOfYear) > 2. check now() related function in MinguoChronology and MinguoDate. > dateNow() > dateNow(Clock clock) > dateNow(ZoneId zone) > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKHijrahChronology.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKJapaneseChronology.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/JapaneseChronology/TCKThaiBuddhistChronology.jtr > > Regards > Patrick > > > From scolebourne at joda.org Mon Apr 29 04:52:06 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 29 Apr 2013 12:52:06 +0100 Subject: [threeten-dev] Please help to review new test cases for java.time.Year and YearMonth In-Reply-To: <517C9C17.9090402@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> <517C9C17.9090402@oracle.com> Message-ID: Looks good to me Stephen On 28 April 2013 04:48, Patrick Zhang wrote: > Hi Team, > > Please help to review new added test case for java.time.Year and > java.time.YearMonth. > The webrev has been reviewed about before 1 month. But I forget to request > it for pushing because of repo building problem on past. > Now it has been modified according to latest test code and run again. :) > > Included apis: > > plus(long, TemporalUnit) > minus(long, TemporalUnit) > plus(TemporalAmount) > minus(TemporalAmount) > with(TemporalField, long) > with(TemporalAdjuster) > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/webrev/ > > Test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYear.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYearMonth.jtr > From scolebourne at joda.org Mon Apr 29 04:55:19 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 29 Apr 2013 12:55:19 +0100 Subject: [threeten-dev] Please help to review new test cases for java.time.ZoneOffset In-Reply-To: <517CA913.1080604@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> <517C9C17.9090402@oracle.com> <517CA913.1080604@oracle.com> Message-ID: test_adjustDate_nullLocalDate should be named test_adjustInto_dateOnly Otherwise looks good. Stephen On 28 April 2013 05:44, Patrick Zhang wrote: > Hi Team, > > Please help to review new added test case for ZoneOffset. > Roughly it is only for adjustInto() method. And the test logic is simple: > > When it is "adjustInto" to one ZonedDateTime, offset of new generated > ZonedDateTime will NOT be changed. It is because ZonedDateTime initialized > by specific zoneId will have one fixed offset, if we ignore the DST. > When it is "adjustInto" to one OffsetDateTime, offset of new generated > OffsetDateTime will be changed. > > Webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/ZoneOffset/webrev/ > > Test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/ZoneOffset/TCKZoneOffset.jtr > > Regards > Patrick From scolebourne at joda.org Mon Apr 29 05:01:45 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 29 Apr 2013 13:01:45 +0100 Subject: [threeten-dev] Please help to review new test cases for java.time.OffsetTime In-Reply-To: <517CA941.7070006@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <517C98F0.3020603@oracle.com> <517C9C17.9090402@oracle.com> <517CA941.7070006@oracle.com> Message-ID: "test_periodUntil_InvalidTemporalUnit" should named "test_periodUntil_invalidType" as it tests periodUtil between OffsetTime and OffsetDateTIme. "test_periodUntil_InvalidTemporalUnit" should test a period in an invalid unit, such as querying the period in MONTHS Otherwise looks good. Stephen On 28 April 2013 05:44, Patrick Zhang wrote: > Hi Team, > > Please help to review new test cases for OffsetTime.periodUntil(). > > The test logic is simple, as description in javadoc: > ============= > When two OffsetTime have different Offset, then the specified end time will > be normalized to have same offset with start time. > ============= > Then 01:01:01+10:00 to 02:01:01+10:00 should be 1 hour while 01:01:01+10:00 > to 02:01:01+9:00 should be 2 hours. > > > Webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetTime/webrev/ > > Test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetTime/TCKOffsetTime.jtr > > Regards > Patrick From roger.riggs at oracle.com Mon Apr 29 14:54:45 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 29 Apr 2013 17:54:45 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517DD645.7070800@Oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> <517AD649.4000902@oracle.com> <517DD645.7070800@Oracle.com> Message-ID: <517EEC25.4000307@oracle.com> Hi, Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ The logic for adjacent value mode has been consolidated a single method that uses the current state of active parser and the new PrinterParser to decide how to adjust the active and new PrinterParser. The first value printer parser becomes the active PrinterParser (and if parsing is set to lenient may consume a variable number of digits), subsequent fixed width fields are forced to remain fixed width and their width is contributed to the first value field to prevent unbounded digit consumption. If a variable width field is appended to the sequence, the initial active value field is modified to be fixed width so that the entire sequence is fixed and the new variable width field becomes the active printer parser. A ValueReducedPrinterParser is treated no differently. Please review the updated test cases for correctness in the lenient and strict modes and the other changes. Thanks, Roger On 4/28/2013 10:09 PM, Roger Riggs wrote: > Hi, > > The remaining problem is that the pattern "MMdd" or the equivalent > builder appends of "Value(2), Value(2)", is not recognized as using > adjacent parsing. When set to lenient the NumberPP parse of "MM" > gobbles up all the input leaving nothing for 'dd'. > (This is a new issue since NumberPP in lenient mode is no longer > limited to maxWidth). > > If the field is marked as withfixedWidth (subsequentWidth == -1) the > field is no longer lenient. > > The problem that remains is that a field identified by the builder > (minWidth == maxWidth) > as fixed width may not actually be fixed width at the time the PP is > invoked. > > I am inclined to think that adjacent value mode must always be engaged, > even for fixed fields. The first fixed field must be informed that it > is followed by > fixed fields. > > Roger > > > > On 4/26/2013 4:00 PM, Stephen Colebourne wrote: >> >> On 26 Apr 2013 20:32, "roger riggs" > > wrote: >> > Start with a hard one. "yyMMdd" in the case where >> ReducedValue/NumberPP is set to lenient. >> > >> > "76321" could be parsed as (76, 3, 21) or (76, 32, 1) >> >> Should be 7, 63, 21 >> >> > "765432" could be parsed several ways. (76, 5, 432) (76, 54, 32), >> etc. >> >> 76 54 32 >> >> The first is variable and the others fixed. Thus lenient could only >> impact the first if others are fixed width. >> Stephen >> >> > The subsequentWidth mechanism only works for fixed fields >> > following a variable width field. If the parsing is set to lenient >> > then what was a fixed field is now variable but the static mechanism >> > for lookahead can't anticipate that. >> > >> > The current mechanism works fine as long as fixed width fields >> > have the same width whether lenient or strict. I think it is >> unnecessary >> > and too big a change to modify NumberPP to extend lenient parsing to >> > fixed width fields. >> > >> > Roger >> > >> > >> > >> > >> > On 4/26/2013 2:13 PM, Stephen Colebourne wrote: >> >> >> >> On 26 April 2013 16:14, roger riggs > > wrote: >> >>> >> >>> Suggestions? >> >> >> >> I think we should start with a set of test cases we agree on. Then >> >> whatever code needs to be changed will have to be changed. It sounds >> >> like the adjacent value parsing mechanism will need some tweaking. >> >> >> >> Stephen >> > >> > >> > > From roger.riggs at oracle.com Mon Apr 29 14:56:29 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 29 Apr 2013 17:56:29 -0400 Subject: [threeten-dev] A potential bug in JapaneseDate.of(Era era, int yearOfEra, int month, int dayOfMonth) In-Reply-To: <517B7788.2080006@linux.vnet.ibm.com> References: <517B7788.2080006@linux.vnet.ibm.com> Message-ID: <517EEC8D.1020507@oracle.com> Hi Frank, Thanks for the reports, we will followup. If the test case code is available it would be useful to integrate it into the existing java.time tests. Thanks, Roger On 4/27/2013 3:00 AM, Frank Ding wrote: > Hi Threeten guys, > Our Japanese test team found out a bug when calling > JapaneseDate.of(Era era, int yearOfEra, int month, int dayOfMonth). > See the code below. > > JapaneseDate date = > JapaneseDate.of(java.time.chrono.JapaneseEra.HEISEI, 1, 1, 7); > > Heisei era starts in Heisei 1/1/8 which implies Heisei 1/1/7 is > invalid. According to its spec [1], > It throws DateTimeException - if the value of any field is out of > range, or if the day-of-month is invalid for the month-year, or if the > date is not a Japanese era. > So the correct behavior is observing DateTimeException for the code > above. What's your opinion of it? > > Best regards, > Frank > > [1] > http://download.java.net/jdk8/docs/api/java/time/chrono/JapaneseDate.html#of%28java.time.chrono.Era,%20int,%20int,%20int%29 > From masayoshi.okutsu at oracle.com Mon Apr 29 22:52:02 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 30 Apr 2013 14:52:02 +0900 Subject: [threeten-dev] SimpleDateFormat and DateTimeFormatter produce different result for JapaneseDate In-Reply-To: <517B7BB8.1090408@linux.vnet.ibm.com> References: <517B7BB8.1090408@linux.vnet.ibm.com> Message-ID: <517F5C02.3000006@oracle.com> Hi, This one isn't reproducible with b87. Both SimpleDateFormat and DateTimeFormatter produce the era name in Japanese. BTW, SimpleDateFormat and DateTimeFormatter patterns aren't compatible. DateTimeFormatter doesn't support the text presentation of the first year of an era, for example. Thanks, Masayoshi On 4/27/2013 4:18 PM, Frank Ding wrote: > Hi threeten guys > Another issue was discovered in recent date time code (b87). Below > is the test case. > > Locale jplocale = new Locale("ja", "JP", "JP"); > String str; > String pattern = "GGGGyyyy\u5e74 MMMM d\u65e5"; > > System.out.println("--- Calendar SimpleDateFormst ---"); > Calendar cal = Calendar.getInstance(); > cal.set(1989,0,8); // = Heisei 1 > > SimpleDateFormat format = new SimpleDateFormat(pattern, > jplocale); > str = format.format(cal.getTime()); > System.out.println("\""+pattern+"\" "+str); > > System.out.println("--- JapaneseDate DateTimeFormatter ---"); > JapaneseDate date = JapaneseDate.of(1989,1,8); > DateTimeFormatter dtf = > DateTimeFormatter.ofPattern(pattern).withLocale(jplocale); > str = date.format(dtf); > System.out.println("\""+pattern+"\" "+str); > > The actual output is (Converted Japanese characters to Unicode by > native2ascii command) > > --- Calendar SimpleDateFormst --- > > "GGGGyyyy\u5e74 MMMM d\u65e5" \u5e73\u6210\u5143\u5e74 1\u6708 8\u65e5 > > --- JapaneseDate DateTimeFormatter --- > > "GGGGyyyy\u5e74 MMMM d\u65e5" Heisei0001\u5e74 1\u6708 8\u65e5 > > It looks like a bug in DateTimeFormatter. Could anybody take a look > at it and confirm? > > Best regards, > Frank > > From scolebourne at joda.org Mon Apr 29 23:24:02 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 30 Apr 2013 07:24:02 +0100 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: <517EEC25.4000307@oracle.com> References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> <517AD649.4000902@oracle.com> <517DD645.7070800@Oracle.com> <517EEC25.4000307@oracle.com> Message-ID: I think the core logic here is now right. In particular its really good that there is no difference internally in appendValue() with fixed/non-fixed width. DTFB line 559 needs tweaking to make sense: "If there is a value PrinterParser is not active then the PrinterParser becomes the active PP;" DTFB lines 1370 (Javadoc) and line 1658 (code) differ. The Javadoc for the two appendValueReduced methods doesn't make it clear enough to me as to their difference. It seems to me that the simpler method is useful for all normal cases. In other places I've got a paragraph for formatting, then a paragraph for parsing - that pattern would be beneficial here. Line 468-470 seems wrong now. Para line 476 also looks wrong. DTFB line 2685, 2715, 496, 543 Javadoc differ from what the code accepts. In TestReducedParser, the parseStrict tests under "Negative baseValue" do not all have negative bases, and perhaps they should. Same with parseLenient The TestReducedParser lenient tests has this {YEAR, 2, 4, 2000, "-10", 0, 3, 2090}, which I think should be {YEAR, 2, 4, 2000, "-10", 0, 3, -10}, as we should only map 01 to 99 to the base value (unless SimpleDateFormat does what your patch proposes) While this {"ddMMyy", "25062001", LENIENT, 0, 8, 2001, 20, 2506}, is clearly "wrong" as far as a human might read it, it is right as far as the rules defined are concerned. We could only get better if we used the knowledge of month range and/or have separate append methods for fixed width. That might be desirable, but is a lot more complicated. So, with all the great logic now in the appendValue and appendValueReduced, the only things that the new reduced method provide AFAICT are: - allow strict parsing to be more lenient - allow lenient parsing to control the maximum width I guess that is sufficient behaviour to justify the new method, although I suspect it will be little used. thanks Stephen On 29 April 2013 22:54, roger riggs wrote: > Hi, > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ > > The logic for adjacent value mode has been consolidated a single method > that uses the current state of active parser and the new PrinterParser > to decide how to adjust the active and new PrinterParser. > > The first value printer parser becomes the active PrinterParser (and if > parsing > is set to lenient may consume a variable number of digits), subsequent > fixed width fields are forced to remain fixed width and their width > is contributed to the first value field to prevent unbounded digit > consumption. > If a variable width field is appended to the sequence, the initial active > value > field is modified to be fixed width so that the entire sequence is fixed and > the new variable width field becomes the active printer parser. > A ValueReducedPrinterParser is treated no differently. > > Please review the updated test cases for correctness in the lenient > and strict modes and the other changes. > > Thanks, Roger > > > > On 4/28/2013 10:09 PM, Roger Riggs wrote: >> >> Hi, >> >> The remaining problem is that the pattern "MMdd" or the equivalent >> builder appends of "Value(2), Value(2)", is not recognized as using >> adjacent parsing. When set to lenient the NumberPP parse of "MM" >> gobbles up all the input leaving nothing for 'dd'. >> (This is a new issue since NumberPP in lenient mode is no longer limited >> to maxWidth). >> >> If the field is marked as withfixedWidth (subsequentWidth == -1) the field >> is no longer lenient. >> >> The problem that remains is that a field identified by the builder >> (minWidth == maxWidth) >> as fixed width may not actually be fixed width at the time the PP is >> invoked. >> >> I am inclined to think that adjacent value mode must always be engaged, >> even for fixed fields. The first fixed field must be informed that it is >> followed by >> fixed fields. >> >> Roger >> >> >> >> On 4/26/2013 4:00 PM, Stephen Colebourne wrote: >>> >>> >>> On 26 Apr 2013 20:32, "roger riggs" >> > wrote: >>> > Start with a hard one. "yyMMdd" in the case where >>> > ReducedValue/NumberPP is set to lenient. >>> > >>> > "76321" could be parsed as (76, 3, 21) or (76, 32, 1) >>> >>> Should be 7, 63, 21 >>> >>> > "765432" could be parsed several ways. (76, 5, 432) (76, 54, 32), etc. >>> >>> 76 54 32 >>> >>> The first is variable and the others fixed. Thus lenient could only >>> impact the first if others are fixed width. >>> Stephen >>> >>> > The subsequentWidth mechanism only works for fixed fields >>> > following a variable width field. If the parsing is set to lenient >>> > then what was a fixed field is now variable but the static mechanism >>> > for lookahead can't anticipate that. >>> > >>> > The current mechanism works fine as long as fixed width fields >>> > have the same width whether lenient or strict. I think it is >>> > unnecessary >>> > and too big a change to modify NumberPP to extend lenient parsing to >>> > fixed width fields. >>> > >>> > Roger >>> > >>> > >>> > >>> > >>> > On 4/26/2013 2:13 PM, Stephen Colebourne wrote: >>> >> >>> >> On 26 April 2013 16:14, roger riggs >> >> > wrote: >>> >>> >>> >>> Suggestions? >>> >> >>> >> I think we should start with a set of test cases we agree on. Then >>> >> whatever code needs to be changed will have to be changed. It sounds >>> >> like the adjacent value parsing mechanism will need some tweaking. >>> >> >>> >> Stephen >>> > >>> > >>> >> >> > From scolebourne at joda.org Mon Apr 29 23:59:14 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 30 Apr 2013 07:59:14 +0100 Subject: [threeten-dev] SimpleDateFormat and DateTimeFormatter produce different result for JapaneseDate In-Reply-To: <517F5C02.3000006@oracle.com> References: <517B7BB8.1090408@linux.vnet.ibm.com> <517F5C02.3000006@oracle.com> Message-ID: Functionality available in SDF but not in DateTimeFormatter sounds like a bug. Perhaps you should raise an issue for any differences you know of? Stephen On 30 April 2013 06:52, Masayoshi Okutsu wrote: > Hi, > > This one isn't reproducible with b87. Both SimpleDateFormat and > DateTimeFormatter produce the era name in Japanese. > > BTW, SimpleDateFormat and DateTimeFormatter patterns aren't compatible. > DateTimeFormatter doesn't support the text presentation of the first year of > an era, for example. > > Thanks, > Masayoshi > > > On 4/27/2013 4:18 PM, Frank Ding wrote: >> >> Hi threeten guys >> Another issue was discovered in recent date time code (b87). Below is >> the test case. >> >> Locale jplocale = new Locale("ja", "JP", "JP"); >> String str; >> String pattern = "GGGGyyyy\u5e74 MMMM d\u65e5"; >> >> System.out.println("--- Calendar SimpleDateFormst ---"); >> Calendar cal = Calendar.getInstance(); >> cal.set(1989,0,8); // = Heisei 1 >> >> SimpleDateFormat format = new SimpleDateFormat(pattern, jplocale); >> str = format.format(cal.getTime()); >> System.out.println("\""+pattern+"\" "+str); >> >> System.out.println("--- JapaneseDate DateTimeFormatter ---"); >> JapaneseDate date = JapaneseDate.of(1989,1,8); >> DateTimeFormatter dtf = >> DateTimeFormatter.ofPattern(pattern).withLocale(jplocale); >> str = date.format(dtf); >> System.out.println("\""+pattern+"\" "+str); >> >> The actual output is (Converted Japanese characters to Unicode by >> native2ascii command) >> > --- Calendar SimpleDateFormst --- >> > "GGGGyyyy\u5e74 MMMM d\u65e5" \u5e73\u6210\u5143\u5e74 1\u6708 8\u65e5 >> > --- JapaneseDate DateTimeFormatter --- >> > "GGGGyyyy\u5e74 MMMM d\u65e5" Heisei0001\u5e74 1\u6708 8\u65e5 >> >> It looks like a bug in DateTimeFormatter. Could anybody take a look at >> it and confirm? >> >> Best regards, >> Frank >> >> > From masayoshi.okutsu at oracle.com Tue Apr 30 01:18:38 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 30 Apr 2013 17:18:38 +0900 Subject: [threeten-dev] SimpleDateFormat and DateTimeFormatter produce different result for JapaneseDate In-Reply-To: References: <517B7BB8.1090408@linux.vnet.ibm.com> <517F5C02.3000006@oracle.com> Message-ID: <517F7E5E.6070802@oracle.com> The text representation support for the year value is SDF's own extension which isn't in CLDR. Do you really want to support the same thing? Masayoshi On 4/30/2013 3:59 PM, Stephen Colebourne wrote: > Functionality available in SDF but not in DateTimeFormatter sounds > like a bug. Perhaps you should raise an issue for any differences you > know of? > > Stephen > > > On 30 April 2013 06:52, Masayoshi Okutsu wrote: >> Hi, >> >> This one isn't reproducible with b87. Both SimpleDateFormat and >> DateTimeFormatter produce the era name in Japanese. >> >> BTW, SimpleDateFormat and DateTimeFormatter patterns aren't compatible. >> DateTimeFormatter doesn't support the text presentation of the first year of >> an era, for example. >> >> Thanks, >> Masayoshi >> >> >> On 4/27/2013 4:18 PM, Frank Ding wrote: >>> Hi threeten guys >>> Another issue was discovered in recent date time code (b87). Below is >>> the test case. >>> >>> Locale jplocale = new Locale("ja", "JP", "JP"); >>> String str; >>> String pattern = "GGGGyyyy\u5e74 MMMM d\u65e5"; >>> >>> System.out.println("--- Calendar SimpleDateFormst ---"); >>> Calendar cal = Calendar.getInstance(); >>> cal.set(1989,0,8); // = Heisei 1 >>> >>> SimpleDateFormat format = new SimpleDateFormat(pattern, jplocale); >>> str = format.format(cal.getTime()); >>> System.out.println("\""+pattern+"\" "+str); >>> >>> System.out.println("--- JapaneseDate DateTimeFormatter ---"); >>> JapaneseDate date = JapaneseDate.of(1989,1,8); >>> DateTimeFormatter dtf = >>> DateTimeFormatter.ofPattern(pattern).withLocale(jplocale); >>> str = date.format(dtf); >>> System.out.println("\""+pattern+"\" "+str); >>> >>> The actual output is (Converted Japanese characters to Unicode by >>> native2ascii command) >>>> --- Calendar SimpleDateFormst --- >>>> "GGGGyyyy\u5e74 MMMM d\u65e5" \u5e73\u6210\u5143\u5e74 1\u6708 8\u65e5 >>>> --- JapaneseDate DateTimeFormatter --- >>>> "GGGGyyyy\u5e74 MMMM d\u65e5" Heisei0001\u5e74 1\u6708 8\u65e5 >>> It looks like a bug in DateTimeFormatter. Could anybody take a look at >>> it and confirm? >>> >>> Best regards, >>> Frank >>> >>> From roger.riggs at oracle.com Tue Apr 30 12:17:57 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 30 Apr 2013 15:17:57 -0400 Subject: [threeten-dev] Review for parsing 2 to 4 years #218 In-Reply-To: References: <517855F2.3000403@oracle.com> <5179A8F5.8090703@oracle.com> <517A99EA.7010304@oracle.com> <517AD649.4000902@oracle.com> <517DD645.7070800@Oracle.com> <517EEC25.4000307@oracle.com> Message-ID: <518018E5.7030100@oracle.com> Thanks for the detailed review. Updated Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-lenient-parse-218/ On 4/30/2013 2:24 AM, Stephen Colebourne wrote: > I think the core logic here is now right. In particular its really > good that there is no difference internally in appendValue() with > fixed/non-fixed width. > > DTFB line 559 needs tweaking to make sense: > "If there is a value PrinterParser is not active then the > PrinterParser becomes the active PP;" fixed > > DTFB lines 1370 (Javadoc) and line 1658 (code) differ. > > The Javadoc for the two appendValueReduced methods doesn't make it > clear enough to me as to their difference. It seems to me that the > simpler method is useful for all normal cases. In other places I've > got a paragraph for formatting, then a paragraph for parsing - that > pattern would be beneficial here. Line 468-470 seems wrong now. Para > line 476 also looks wrong. Re-ordered the paragraphs and made them consistent. There is an asymmetry between the reduced value computation. For formatting, it is minWidth, on parsing it is two digits. I would be inclined to change parsing to use minwidth but then it would not match the SimpleDateFormat that is explicitly two digits. In most case it would have the same effect since "yy" converts to a fixed with of 2. It affects test cases with the width == 1, not likely to used often. > > DTFB line 2685, 2715, 496, 543 Javadoc differ from what the code accepts. Cleaned up to allow 1..10 characters. > > > In TestReducedParser, the parseStrict tests under "Negative baseValue" > do not all have negative bases, and perhaps they should. Same with > parseLenient Reordered the test cases and removed some duplicates. > > The TestReducedParser lenient tests has this > {YEAR, 2, 4, 2000, "-10", 0, 3, 2090}, > which I think should be > {YEAR, 2, 4, 2000, "-10", 0, 3, -10}, > as we should only map 01 to 99 to the base value (unless > SimpleDateFormat does what your patch proposes) SDF values are relative for exactly 2 parsed digits. Updated ReducedPrinterParser to match. > > While this > {"ddMMyy", "25062001", LENIENT, 0, 8, 2001, 20, 2506}, > is clearly "wrong" as far as a human might read it, it is right as far > as the rules defined are concerned. We could only get better if we > used the knowledge of month range and/or have separate append methods > for fixed width. That might be desirable, but is a lot more > complicated. Very consistent as is, but appendValueReduced could be special cased to force the preceding fields to be fixed (as if it were a variable width field). If the developer used the 2nd form of addValueReduced with two different widths the problem would not appear. > > > So, with all the great logic now in the appendValue and > appendValueReduced, the only things that the new reduced method > provide AFAICT are: > - allow strict parsing to be more lenient > - allow lenient parsing to control the maximum width yes, that's the value add. Roger > > I guess that is sufficient behaviour to justify the new method, > although I suspect it will be little used. > thanks > Stephen > > > > On 29 April 2013 22:54, roger riggs wrote: >> Hi, >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/ >> >> The logic for adjacent value mode has been consolidated a single method >> that uses the current state of active parser and the new PrinterParser >> to decide how to adjust the active and new PrinterParser. >> >> The first value printer parser becomes the active PrinterParser (and if >> parsing >> is set to lenient may consume a variable number of digits), subsequent >> fixed width fields are forced to remain fixed width and their width >> is contributed to the first value field to prevent unbounded digit >> consumption. >> If a variable width field is appended to the sequence, the initial active >> value >> field is modified to be fixed width so that the entire sequence is fixed and >> the new variable width field becomes the active printer parser. >> A ValueReducedPrinterParser is treated no differently. >> >> Please review the updated test cases for correctness in the lenient >> and strict modes and the other changes. >> >> Thanks, Roger >>