From roger.riggs at oracle.com Mon Jul 1 07:18:34 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 01 Jul 2013 10:18:34 -0400 Subject: [threeten-dev] Review Tests for HijrahChronology resolve of lenient dates plus a bug fix Message-ID: <51D18FBA.1000504@oracle.com> Please review new tests and a bug fix for HijrahChronology.resolve. http://cr.openjdk.java.net/~rriggs/webrev-hijrah-resolve-318/ Thanks, Roger From scolebourne at joda.org Mon Jul 1 07:52:42 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 1 Jul 2013 15:52:42 +0100 Subject: [threeten-dev] Review Tests for HijrahChronology resolve of lenient dates plus a bug fix In-Reply-To: <51D18FBA.1000504@oracle.com> References: <51D18FBA.1000504@oracle.com> Message-ID: Looks good to me Stephen On 1 July 2013 15:18, roger riggs wrote: > Please review new tests and a bug fix for HijrahChronology.resolve. > > http://cr.openjdk.java.net/~rriggs/webrev-hijrah-resolve-318/ > > Thanks, Roger > > From roger.riggs at oracle.com Mon Jul 1 08:40:41 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 01 Jul 2013 15:40:41 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Issue #318: Lenient parsing of other non-ISO Message-ID: <20130701154154.A9FD4486C9@hg.openjdk.java.net> Changeset: c7d8b218d8ae Author: rriggs Date: 2013-07-01 11:24 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c7d8b218d8ae Issue #318: Lenient parsing of other non-ISO - Tests for HijrahChronology.resolve - fix bug in HijrahDate.dateYearDay that did not check day-of-year ! src/share/classes/java/time/chrono/HijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java From scolebourne at joda.org Mon Jul 1 08:45:43 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 01 Jul 2013 15:45:43 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20130701154624.CEB9B486CA@hg.openjdk.java.net> Changeset: e92ef0ad0c59 Author: scolebourne Date: 2013-07-01 15:33 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e92ef0ad0c59 Organize imports ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java Changeset: bafad55d127c Author: scolebourne Date: 2013-07-01 16:38 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bafad55d127c Alter TemporalField.resolve to directly alter map Simpler, less error prone, approach for implementors See #322 ! src/share/classes/java/time/format/Parsed.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 Changeset: 6545c4e1fa35 Author: scolebourne Date: 2013-07-01 16:45 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6545c4e1fa35 Merge From scolebourne at joda.org Mon Jul 1 09:00:20 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 01 Jul 2013 16:00:20 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Add Temporal.isSupported(TemporalUnit) Message-ID: <20130701160046.1370A486CB@hg.openjdk.java.net> Changeset: 309941ea2062 Author: scolebourne Date: 2013-07-01 16:57 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/309941ea2062 Add Temporal.isSupported(TemporalUnit) See #315 ! 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/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZonedDateTime.java ! 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/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKChronoUnit.java From masayoshi.okutsu at oracle.com Mon Jul 1 09:44:01 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 02 Jul 2013 01:44:01 +0900 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: References: <51C4C2F5.9040609@oracle.com> Message-ID: <51D1B1D1.8050807@oracle.com> On 2013/06/24 20:21, Stephen Colebourne wrote: > And there is a disagreemnet as to the start of the Meiji era. > sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says 1868-09-08. > Is the old Sun class wrong here? Both are wrong. 1968-01-01 is to extend Gregorian backwards from Meiji 6 in which Gregorian was adopted in Japan. This is because of the lack of the Tenpo calendar (a lunisolar calendar) support. 1868-01-01 is wrong, but intentional in the sun.util.calendar implementation. 09-08 is the Keio-Meiji transition date in the lunisolar calendar, which doesn't make sense in Gregorian. Its real Gregorian date is 1868-10-23. Note that the whole lunisolar year became Meiji 1 by the era transition rule at that time. The real Meiji 1-01-01 is Gregorian 1868-01-25. If JSR 310 needs correct Meiji support before Meiji 6, the lunisolar calendar must be supported. I've been proposing that JapaneseChronology supports dates from Meiji 6. > Showa is also different by a day. The initial version in 1.6 had that bug. But it was fixed long ago. Which version are you referring to? Masayoshi > > The class needs a lot of tidying up I fear. > > Here are some more tests, with bugs commented out. > https://gist.github.com/jodastephen/5849354 > > Who is working to fix this class? > thanks > Stephen > > > > On 24 June 2013 11:26, Stephen Colebourne wrote: >> The patch is fine, except for a cut and paste "Hijrah". >> >> There are lots of issues to work out with Japanese. I'd like to get >> the two patches I put out integrated as well. >> https://github.com/ThreeTen/threeten/issues/299#issuecomment-19831206 >> https://github.com/ThreeTen/threeten/issues/318#issuecomment-19896959 >> >> The public factory methods are also weird too. ofYearDay(int,int) is >> public, unlike other date classes. >> Stephen >> >> >> >> On 21 June 2013 22:17, roger riggs wrote: >>> A number of problems were found with the DAY_OF_YEAR field in >>> JapaneseChronology/Date. >>> The values for the lengthOfYear() and range were incorrectly computed >>> interfering >>> with the operation of get() and with(). >>> >>> The bugs.sun.com issue is: 8017105 >>> >>> >>> Please review and comment: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ >>> >>> Thanks, Roger >>> >>> From roger.riggs at oracle.com Mon Jul 1 10:15:25 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 01 Jul 2013 13:15:25 -0400 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: <51D1B1D1.8050807@oracle.com> References: <51C4C2F5.9040609@oracle.com> <51D1B1D1.8050807@oracle.com> Message-ID: <51D1B92D.9060404@oracle.com> Hi, I filed an issue #326 to track limiting dates to Meiji 6 and later. Roger [1] JBS 8019512 On 7/1/2013 12:44 PM, Masayoshi Okutsu wrote: > On 2013/06/24 20:21, Stephen Colebourne wrote: >> And there is a disagreemnet as to the start of the Meiji era. >> sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says >> 1868-09-08. >> Is the old Sun class wrong here? > > Both are wrong. 1968-01-01 is to extend Gregorian backwards from Meiji > 6 in which Gregorian was adopted in Japan. This is because of the lack > of the Tenpo calendar (a lunisolar calendar) support. 1868-01-01 is > wrong, but intentional in the sun.util.calendar implementation. > > 09-08 is the Keio-Meiji transition date in the lunisolar calendar, > which doesn't make sense in Gregorian. Its real Gregorian date is > 1868-10-23. Note that the whole lunisolar year became Meiji 1 by the > era transition rule at that time. The real Meiji 1-01-01 is Gregorian > 1868-01-25. If JSR 310 needs correct Meiji support before Meiji 6, the > lunisolar calendar must be supported. > > I've been proposing that JapaneseChronology supports dates from Meiji 6. > >> Showa is also different by a day. > > The initial version in 1.6 had that bug. But it was fixed long ago. > Which version are you referring to? > > Masayoshi > >> >> The class needs a lot of tidying up I fear. >> >> Here are some more tests, with bugs commented out. >> https://gist.github.com/jodastephen/5849354 >> >> Who is working to fix this class? >> thanks >> Stephen >> >> >> >> On 24 June 2013 11:26, Stephen Colebourne wrote: >>> The patch is fine, except for a cut and paste "Hijrah". >>> >>> There are lots of issues to work out with Japanese. I'd like to get >>> the two patches I put out integrated as well. >>> https://github.com/ThreeTen/threeten/issues/299#issuecomment-19831206 >>> https://github.com/ThreeTen/threeten/issues/318#issuecomment-19896959 >>> >>> The public factory methods are also weird too. ofYearDay(int,int) is >>> public, unlike other date classes. >>> Stephen >>> >>> >>> >>> On 21 June 2013 22:17, roger riggs wrote: >>>> A number of problems were found with the DAY_OF_YEAR field in >>>> JapaneseChronology/Date. >>>> The values for the lengthOfYear() and range were incorrectly computed >>>> interfering >>>> with the operation of get() and with(). >>>> >>>> The bugs.sun.com issue is: 8017105 >>>> >>>> >>>> Please review and comment: >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ >>>> >>>> >>>> Thanks, Roger >>>> >>>> > From scolebourne at joda.org Thu Jul 4 03:31:40 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 04 Jul 2013 10:31:40 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Test jumps over the international date line Message-ID: <20130704103245.BD109487C4@hg.openjdk.java.net> Changeset: bb4def168896 Author: scolebourne Date: 2013-07-04 11:29 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bb4def168896 Test jumps over the international date line See #316 ! test/java/time/tck/java/time/zone/TCKZoneRules.java From scolebourne at joda.org Sun Jul 7 04:02:37 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sun, 07 Jul 2013 11:02:37 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix Javadoc Message-ID: <20130707110335.67ABE48881@hg.openjdk.java.net> Changeset: ae87386e0029 Author: scolebourne Date: 2013-07-07 11:59 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ae87386e0029 Fix Javadoc Broken in commit bafad55d127c ! src/share/classes/java/time/format/DateTimeFormatter.java From roger.riggs at oracle.com Tue Jul 9 11:22:38 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 09 Jul 2013 14:22:38 -0400 Subject: [threeten-dev] Review Request: JapaneseChronology starts with Meiji 6 Message-ID: <51DC54EE.306@oracle.com> Hi, In issue #326 and JBS 8019512 it is proposed to start the JapaneseChronology at Meiji 6 when the Gregorian calendar was adopted to overlay the Imperial Eras. Dates before Meiji 6 are not supported throw an exception. The changes remove the Seireki Era and define the first supported date as Meiji 6, January 1. Various ranges and tests are updated to match. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-no-seireki-326/ Please review and comment, Roger From scolebourne at joda.org Tue Jul 9 11:56:43 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Jul 2013 19:56:43 +0100 Subject: [threeten-dev] Review Request: JapaneseChronology starts with Meiji 6 In-Reply-To: <51DC54EE.306@oracle.com> References: <51DC54EE.306@oracle.com> Message-ID: Looks good to me Stephen On 9 July 2013 19:22, roger riggs wrote: > Hi, > > In issue #326 and JBS > 8019512 it is proposed to > start the JapaneseChronology at Meiji 6 > when the Gregorian calendar was adopted to overlay the Imperial Eras. > Dates before Meiji 6 are not supported throw an exception. > > The changes remove the Seireki Era and define the first supported > date as Meiji 6, January 1. Various ranges and tests are updated to match. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-no-seireki-326/ > > Please review and comment, Roger > > > > From roger.riggs at oracle.com Tue Jul 9 12:07:30 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 09 Jul 2013 15:07:30 -0400 Subject: [threeten-dev] Code Freeze tomorrow Message-ID: <51DC5F72.7020102@oracle.com> Hi, It is time to integrate the accumulated ThreeTen changes into the TL workspace. As mentioned last week, tomorrow is the cut off for getting changes into this update. I am working on: - #326 to cleanup up the Japanese Eras. - #292 to remove the generics from ChronoLocalDate (web-rev later today) What additional changes can we expect by tomorrow? Can we plan to include: - #321 Change Chronology to be an Interface? - #282 and #299 related to lenient parsing; are these complete? Thanks, Roger From scolebourne at joda.org Tue Jul 9 12:32:13 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Jul 2013 20:32:13 +0100 Subject: [threeten-dev] Code Freeze tomorrow In-Reply-To: <51DC5F72.7020102@oracle.com> References: <51DC5F72.7020102@oracle.com> Message-ID: #299 is waiting approval from Oracle that the algorithm for smart is acceptable as the default. (It would be awkward in some ways if it wasn't acceptable). #282 is only open as a placeholder for more testing. That won't happen in the next week. I think #312 is desirable, but makes our implementations harder as it probably results in lots of duplicate code. It won't be done this week. (this is a busy work week) Stephen On 9 July 2013 20:07, roger riggs wrote: > Hi, > > It is time to integrate the accumulated ThreeTen changes into the TL > workspace. > As mentioned last week, tomorrow is the cut off for getting changes into > this update. > > I am working on: > - #326 to cleanup up the Japanese Eras. > - #292 to remove the generics from ChronoLocalDate (web-rev later today) > > What additional changes can we expect by tomorrow? > > Can we plan to include: > - #321 Change Chronology to be an Interface? > - #282 and #299 related to lenient parsing; are these complete? > > Thanks, Roger > From scolebourne at joda.org Tue Jul 9 12:46:59 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Jul 2013 20:46:59 +0100 Subject: [threeten-dev] Temporal API Message-ID: Overall, I think the API is pretty sound. I've not had any huge reason to doubt what we've got in the last few months. The main area where there is a possible change is whether we should have an "API" that is separate from all implementation code. By this, I mean that the temporal interfaces - TemporalAccessor, Temporal, TemporalUnit, TemporalField, TemporalAdjuster, TemporalAmount and TemporalQuery - could form a small and isolated API that is independent of all the implementation classes. Right now, they are bound in as follows: - TemporalField.resolve refers to ZoneId and Chronology. Could be changes to TemporalAccessor. - TemporalQuery and TemporalAdjuster refer to lots of classes in static methods. Could remove the static methods on the interface and revive the TemporalQueries and Temporal Adjusters as public classes. - TemporalUnit refers to Duration. The first two are easy to change and have very little impact. The latter is much harder, as Duration is effectively the correct type to use. It could be changed to TemporalAmount, but that makes it harder to use. It could be change to be a long, but that limits the size of the maximum TemporalUnit. Or it could be a long refering to another unit - "one day = 24 hours". The benefits of separating out the API as above are to allow future evolution to use the API, but not the implementation. However, that has never been a goal of the project. The lilkelihood is that there is unlikely to be a replacement API in the JDK, and if there is it would probably replace the whole of threeten, including the temporal interfaces. Given where we are, it seems unlikely that we will do the above, but it should be mentioned/discussed. I would say that the static methods on TemporalQuery and TemporalAdjuster remain at the borders of good taste. There could be a good case for reviving TemporalQueries and Temporal Adjusters as public classes anyway. In addition, Stephen From roger.riggs at oracle.com Tue Jul 9 14:39:32 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 09 Jul 2013 17:39:32 -0400 Subject: [threeten-dev] Review #383 ChronoLocalDate generics difficult to use Message-ID: <51DC8314.90801@oracle.com> Please review this change remove the generic type parameter from ChronoLocalDate. As raised in issue #292 the type parameter is unnecessary and unwieldy. Initially, it was useful to the implementation of default methods but the implementation has been refactored. This change reduces the number of cases where the developer will need to deal explicitly with wildcard type parameters to ChronoZonedDateTime and ChronoLocalDateTime. The patch contains the changes proposed in the GIST rebased to the current tip. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cld-nogenerictype-292/ Please review and comment. Thanks, Roger From roger.riggs at oracle.com Tue Jul 9 14:43:00 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 09 Jul 2013 17:43:00 -0400 Subject: [threeten-dev] Code Freeze tomorrow In-Reply-To: References: <51DC5F72.7020102@oracle.com> Message-ID: <51DC83E4.1060308@oracle.com> Hi, On 7/9/2013 3:32 PM, Stephen Colebourne wrote: > #299 is waiting approval from Oracle that the algorithm for smart is > acceptable as the default. (It would be awkward in some ways if it > wasn't acceptable). ok, I have ping'ed them to review it, if no response by tomorrow, I would push it and correct it later as necessary. > > #282 is only open as a placeholder for more testing. That won't happen > in the next week. ok > > I think #321 is desirable, but makes our implementations harder as it > probably results in lots of duplicate code. It won't be done this > week. (this is a busy work week) ok, duplicate code is not a plus, we can take another look later. Thanks, Roger > > Stephen > > > On 9 July 2013 20:07, roger riggs wrote: >> Hi, >> >> It is time to integrate the accumulated ThreeTen changes into the TL >> workspace. >> As mentioned last week, tomorrow is the cut off for getting changes into >> this update. >> >> I am working on: >> - #326 to cleanup up the Japanese Eras. >> - #292 to remove the generics from ChronoLocalDate (web-rev later today) >> >> What additional changes can we expect by tomorrow? >> >> Can we plan to include: >> - #321 Change Chronology to be an Interface? >> - #282 and #299 related to lenient parsing; are these complete? >> >> Thanks, Roger >> From roger.riggs at oracle.com Tue Jul 9 14:44:50 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 09 Jul 2013 21:44:50 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: BugId: 8019512 #326 No Support for JapaneseChronology before Meiji 6 Message-ID: <20130709214536.713684891B@hg.openjdk.java.net> Changeset: e6e4db707045 Author: rriggs Date: 2013-07-09 15:22 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e6e4db707045 BugId: 8019512 #326 No Support for JapaneseChronology before Meiji 6 Established Meiji 6 as the first valid year for the JapaneseDate Removed Seireki Era since is not an accurate calendar Update range for YEAR_OF_ERA to have a minimum of 1 Update range for YEAR to reflect minimum support year (Meiji 6) Updated tests Corrected one Islamic UmmAlQura test case that had incorrect data but seemed to be passing ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java ! test/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java From scolebourne at joda.org Tue Jul 9 15:34:40 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Jul 2013 23:34:40 +0100 Subject: [threeten-dev] Code Freeze tomorrow In-Reply-To: <51DC83E4.1060308@oracle.com> References: <51DC5F72.7020102@oracle.com> <51DC83E4.1060308@oracle.com> Message-ID: On 9 July 2013 22:43, roger riggs wrote: >> #299 is waiting approval from Oracle that the algorithm for smart is >> acceptable as the default. (It would be awkward in some ways if it >> wasn't acceptable). > > ok, I have ping'ed them to review it, if no response by tomorrow, I would > push it > and correct it later as necessary. My changes are already committed. The review is to check that they are happy with the logic that went in. >> #282 is only open as a placeholder for more testing. That won't happen >> in the next week. > > ok >> >> I think #321 is desirable, but makes our implementations harder as it >> probably results in lots of duplicate code. It won't be done this >> week. (this is a busy work week) > > ok, duplicate code is not a plus, we can take another look later. See the issue for a gist that adds AbstractChronology as a public class. This avoids the code duplication. With the upcoming generics removal, the patch can be further enhanced, removing code from subclass Chronology implementations (unless explicit Javadoc is needed). I don't propose we commit the gist/patch before tomorrow, however it would be good to get feedback on the approach. Stephen From scolebourne at joda.org Tue Jul 9 15:54:54 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Jul 2013 23:54:54 +0100 Subject: [threeten-dev] Review #383 ChronoLocalDate generics difficult to use In-Reply-To: <51DC8314.90801@oracle.com> References: <51DC8314.90801@oracle.com> Message-ID: ChronoLocalDateTimeImpl.plusWithOverflow looks like it should take D as the argument, not ChronoLocalDate A number of methods in ChronoZonedDateTimeImpl.ofInstant, ChronoZonedDateTimeImpl.ensureValid and ChronoLocalDateTimeImpl.ensureValid hide the generic with a method-level . The method-level ones should use (for result) to be clearer. ChronoLocalDateTimeImpl.of() looks like it would benefit from the addition of a method-level . MinguoDate and HijrahDate have a change in readExternal, but Thai and Japanese do not. None of the above look like vital things to fix before pushing, although they should all be investigated at some point. Otherwise looks good. thanks Stephen On 9 July 2013 22:39, roger riggs wrote: > Please review this change remove the generic type parameter from > ChronoLocalDate. > As raised in issue #292 > the type parameter is unnecessary and unwieldy. > Initially, it was useful to the implementation of default methods but the > implementation > has been refactored. > > This change reduces the number of cases where the developer will need > to deal explicitly with wildcard type parameters to ChronoZonedDateTime > and ChronoLocalDateTime. > > The patch contains the changes proposed in the GIST rebased to the current > tip. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cld-nogenerictype-292/ > > Please review and comment. > > Thanks, Roger > > > > From roger.riggs at oracle.com Wed Jul 10 07:40:30 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 10 Jul 2013 10:40:30 -0400 Subject: [threeten-dev] Review #383 ChronoLocalDate generics difficult to use In-Reply-To: References: <51DC8314.90801@oracle.com> Message-ID: <51DD725E.9040001@oracle.com> Thanks for the review, I will make the updates. http://cr.openjdk.java.net/~rriggs/webrev-cld-nogenerictype-292/ I also updated the example code in the chrono package-info.java to remove the wildcards. On 7/9/2013 6:54 PM, Stephen Colebourne wrote: > ChronoLocalDateTimeImpl.plusWithOverflow looks like it should take D > as the argument, not ChronoLocalDate right > > A number of methods in ChronoZonedDateTimeImpl.ofInstant, > ChronoZonedDateTimeImpl.ensureValid and > ChronoLocalDateTimeImpl.ensureValid hide the generic with a > method-level . The method-level ones should use (for result) to > be clearer. fixed > > ChronoLocalDateTimeImpl.of() looks like it would benefit from the > addition of a method-level . ok > > MinguoDate and HijrahDate have a change in readExternal, but Thai and > Japanese do not. The change was to consistently return the specific subclass; previously Minguo and Hijrah returned ChronoLocalDate; > > > None of the above look like vital things to fix before pushing, > although they should all be investigated at some point. > Otherwise looks good. Thanks, Roger > thanks > Stephen > > > On 9 July 2013 22:39, roger riggs wrote: >> Please review this change remove the generic type parameter from >> ChronoLocalDate. >> As raised in issue #292 >> the type parameter is unnecessary and unwieldy. >> Initially, it was useful to the implementation of default methods but the >> implementation >> has been refactored. >> >> This change reduces the number of cases where the developer will need >> to deal explicitly with wildcard type parameters to ChronoZonedDateTime >> and ChronoLocalDateTime. >> >> The patch contains the changes proposed in the GIST rebased to the current >> tip. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cld-nogenerictype-292/ >> >> Please review and comment. >> >> Thanks, Roger >> >> >> >> From roger.riggs at oracle.com Wed Jul 10 10:17:30 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 10 Jul 2013 17:17:30 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: BugId: 8020280, Issue #292 Remove generics from ChronoLocalDate Message-ID: <20130710171803.A15FE48960@hg.openjdk.java.net> Changeset: 1e3f7b402795 Author: rriggs Date: 2013-07-10 11:48 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1e3f7b402795 BugId: 8020280, Issue #292 Remove generics from ChronoLocalDate Keep them on ChronoZonedDateTime and ChronoLocalDateTime Updated sample code in java.time.chrono package javadoc ! src/share/classes/java/time/LocalDate.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/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimePrintContext.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 ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/test/java/time/chrono/TestChronoLocalDate.java ! test/java/time/test/java/time/chrono/TestExampleCode.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java From roger.riggs at oracle.com Thu Jul 11 13:27:47 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 11 Jul 2013 16:27:47 -0400 Subject: [threeten-dev] Java.time -Xlint warning cleanup Message-ID: <51DF1543.4000901@oracle.com> Hi, An ongoing goal is to cleanup the JDK build so that compiles do not produce warnings. They may not go in with the rest of the current updates but I wanted to understand the impact. The bulk of warnings in java.time are related to unchecked casts. But some API changes seemed to be the better solution than just suppressing the warnings. Please review: http://cr.openjdk.java.net/~rriggs/webrev-unchecked-cleanup-8020418/ Thanks, Roger From scolebourne at joda.org Thu Jul 11 14:09:34 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 11 Jul 2013 22:09:34 +0100 Subject: [threeten-dev] Java.time -Xlint warning cleanup In-Reply-To: <51DF1543.4000901@oracle.com> References: <51DF1543.4000901@oracle.com> Message-ID: Looks fine, except that the public API in ChronoLocalDate has changed. I'm not sure whether its a good change or not though. But you have left in a redundent @param thanks Stephen On 11 July 2013 21:27, roger riggs wrote: > Hi, > > An ongoing goal is to cleanup the JDK build so that compiles do not produce > warnings. They may not go in with the rest of the current updates but I > wanted > to understand the impact. > > The bulk of warnings in java.time are related to unchecked casts. > But some API changes seemed to be the better solution than just > suppressing the warnings. > > Please review: > > http://cr.openjdk.java.net/~rriggs/webrev-unchecked-cleanup-8020418/ > > Thanks, Roger > > > From roger.riggs at oracle.com Thu Jul 11 14:25:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 11 Jul 2013 17:25:51 -0400 Subject: [threeten-dev] Java.time -Xlint warning cleanup In-Reply-To: References: <51DF1543.4000901@oracle.com> Message-ID: <51DF22DF.6040600@oracle.com> Hi, In ChronoLocalDate.atTime, with the previous definition default ChronoLocalDateTime atTime(LocalTime localTime) {...} I could not find a way to silence the unchecked warning. Also, it allowed the caller, without any warning, to implicitly change the generic parameter. ChronoLocalDateTime jd = HijrahChronology.INSTANCE.dateNow().atTime(LocalTime.NOON); Thanks, Roger On 7/11/2013 5:09 PM, Stephen Colebourne wrote: > Looks fine, except that the public API in ChronoLocalDate has changed. > I'm not sure whether its a good change or not though. > But you have left in a redundent @param > > thanks > Stephen > > > On 11 July 2013 21:27, roger riggs wrote: >> Hi, >> >> An ongoing goal is to cleanup the JDK build so that compiles do not produce >> warnings. They may not go in with the rest of the current updates but I >> wanted >> to understand the impact. >> >> The bulk of warnings in java.time are related to unchecked casts. >> But some API changes seemed to be the better solution than just >> suppressing the warnings. >> >> Please review: >> >> http://cr.openjdk.java.net/~rriggs/webrev-unchecked-cleanup-8020418/ >> >> Thanks, Roger >> >> >> From scolebourne at joda.org Thu Jul 11 14:29:03 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 11 Jul 2013 22:29:03 +0100 Subject: [threeten-dev] Java.time -Xlint warning cleanup In-Reply-To: <51DF22DF.6040600@oracle.com> References: <51DF1543.4000901@oracle.com> <51DF22DF.6040600@oracle.com> Message-ID: If you remove the @param then its fine to commit. Stephen On 11 July 2013 22:25, roger riggs wrote: > Hi, > > In ChronoLocalDate.atTime, with the previous definition > default ChronoLocalDateTime > atTime(LocalTime localTime) {...} > > I could not find a way to silence the unchecked warning. > > Also, it allowed the caller, without any warning, to implicitly change the > generic parameter. > > ChronoLocalDateTime jd = > HijrahChronology.INSTANCE.dateNow().atTime(LocalTime.NOON); > > Thanks, Roger > > > > > On 7/11/2013 5:09 PM, Stephen Colebourne wrote: >> >> Looks fine, except that the public API in ChronoLocalDate has changed. >> I'm not sure whether its a good change or not though. >> But you have left in a redundent @param >> >> thanks >> Stephen >> >> >> On 11 July 2013 21:27, roger riggs wrote: >>> >>> Hi, >>> >>> An ongoing goal is to cleanup the JDK build so that compiles do not >>> produce >>> warnings. They may not go in with the rest of the current updates but I >>> wanted >>> to understand the impact. >>> >>> The bulk of warnings in java.time are related to unchecked casts. >>> But some API changes seemed to be the better solution than just >>> suppressing the warnings. >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-unchecked-cleanup-8020418/ >>> >>> Thanks, Roger >>> >>> >>> > From roger.riggs at oracle.com Thu Jul 11 19:02:53 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 12 Jul 2013 02:02:53 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130712020340.09F9548A0E@hg.openjdk.java.net> Changeset: 390da5b045f5 Author: rriggs Date: 2013-07-11 21:55 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/390da5b045f5 Corrected order of @see tags in JSR 310 javadoc ! make/netbeans/threeten/build.xml Changeset: faba7f5409d2 Author: rriggs Date: 2013-07-11 21:59 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/faba7f5409d2 BugId: 8020418 Cleanup of -Xlint warnings in java.time ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! test/java/time/test/java/time/chrono/TestChronoLocalDate.java ! test/java/time/test/java/time/chrono/TestExampleCode.java From patrick.zhang at oracle.com Fri Jul 12 03:23:56 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Fri, 12 Jul 2013 18:23:56 +0800 Subject: [threeten-dev] some questions for with() method in java.time.chrono.ChronoLocalDate In-Reply-To: <51A46179.3000204@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> <519D907B.2030801@oracle.com> <519D96DB.4020400@oracle.com> <519D9A1C.9030008@oracle.com> <519F25FB.5000004@oracle.com> <51A46179.3000204@oracle.com> Message-ID: <51DFD93C.5030208@oracle.com> Hi Team, I am reading source code of threeten project and find something strange in java.time.chrono.ChronoLocalDate. There are 2 with() methods, mostly I am confused by below: ====== default ChronoLocalDate with(TemporalField field, long newValue) { if (field instanceof ChronoField) { throw new UnsupportedTemporalTypeException("Unsupported field: " + field); } return ChronoDateImpl.ensureValid(getChronology(), field.adjustInto(this, newValue)); } ====== As you know, ChronoLocalDate with(TemporalField field, long newValue) is not DEFAULT in ChronoLocalDateTime and ChronoZonedDateTime. 1. Why we make it as default in ChronoLocalDate? 2. The implement looks strange. Why it does not support standard ChronoField and must throw UnsupportedTemporalTypeException explicitly? Regards Patrick From roger.riggs at oracle.com Fri Jul 12 06:46:08 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 12 Jul 2013 09:46:08 -0400 Subject: [threeten-dev] some questions for with() method in java.time.chrono.ChronoLocalDate In-Reply-To: <51DFD93C.5030208@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> <519D907B.2030801@oracle.com> <519D96DB.4020400@oracle.com> <519D9A1C.9030008@oracle.com> <519F25FB.5000004@oracle.com> <51A46179.3000204@oracle.com> <51DFD93C.5030208@oracle.com> Message-ID: <51E008A0.7010705@oracle.com> Hi Patrick, On 7/12/2013 6:23 AM, Patrick Zhang wrote: > Hi Team, > > I am reading source code of threeten project and find something > strange in java.time.chrono.ChronoLocalDate. > There are 2 with() methods, mostly I am confused by below: > ====== > default ChronoLocalDate with(TemporalField field, long newValue) { > if (field instanceof ChronoField) { > throw new UnsupportedTemporalTypeException("Unsupported > field: " + field); > } > return ChronoDateImpl.ensureValid(getChronology(), > field.adjustInto(this, newValue)); > } > > ====== > > As you know, ChronoLocalDate with(TemporalField field, long newValue) > is not DEFAULT in ChronoLocalDateTime and ChronoZonedDateTime. > > 1. Why we make it as default in ChronoLocalDate? This is a defensive strategy to make sure implementations of with(TemporalField field, value) for built-in fields (ChronoField) are handled in the concrete implementations. If a concrete implementation failed to override the method it throws the exception. For other subtypes of TemporalField it delegates to the field to figure out how to compute the value and produce the updated date in terms of the intrinsic fields (month, day, hour, etc) using some combination of ChronoFields. If it did not throw the exception, it would recursively call the field.adjustInto which would call the temporal.with() which would call field.adjustInto()... til the stack was consumed. Since it is expected that additional Chronologies will add subclasses of ChronoLocalDate (and not all by Oracle) the default method is a precaution to catch early mistakes in coding. > 2. The implement looks strange. Why it does not support standard > ChronoField and must throw UnsupportedTemporalTypeException explicitly? > Every concrete Subclass must override the method and compute the new value. The interfaces ChronoLocalDateTime and ChronoZonedDateTime as just holders of a time, date, etc and delegate to the date or time as appropriate. Perhaps it could have been implemented as a "default" method but since it is expected there is only a single 'final' implementation of each it the default method would not be needed/useful. Roger > Regards > Patrick > From xueming.shen at oracle.com Fri Jul 12 10:40:00 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Jul 2013 10:40:00 -0700 Subject: [threeten-dev] RFR: 8016025 JSR 310: DateTime API Updates IV Message-ID: <51E03F70.2040701@oracle.com> Hi Please help review the update for the JSR310 DateTime API updates IV http://cr.openjdk.java.net/~sherman/8016025/webrev/ Here is the summary of the updates included in this round of API update: - Remove type parameter from ChronoLocalDate as unnecessary to simplify API and usage - Rename Temporal.periodUntil to until() and in all implementations - Added Temporal.isSupported(TemporalUnit) as a complement to TemporalAccessor.isSupported(TemporalField) - Add support for lenient parsing mechanism with Chronology.resolveDate, in subclasses and in TemporalField. - Add parsing support in Period for ISO week strings - Remove Temporal/getName and ChronoField.getName (redundant with toString and ChronoField.name method) - ChronoField.DAY_OF_YEAR clarified in case of Calendars and Eras whose start day varies from year to year as in Japanese eras. - TemporalUnit and ChronoUnit.isDateUnit and isTimeUnit methods renamed to isDateBased and isTimeBased. - Move static methods in java.time.temporal.Adjusters to Adjuster interface and remove class Adjusters - Move static methods in java.time.temporal.Queries to TemporalQuery and remove class Queries - Changed OffsetDateTime.INSTANT_COMPARATOR froma field to a method - WeekFields updated to specific the lenient resolution modes - DateTimeFormatterBuilder cleanup of parsing of ZoneIds to match ZoneId.of syntax. - HijrahChronology updated the syntax for the BCP 47 based locale string to use "-u-ca-islamic-umalqura" - IsoChronology - narrowed the return type of getEra to IsoEra - JapaneseChronology/Date/Era - Japanese calendar starts with Meiji 6 to avoid ill defined early years of Meiji calendar. - Remove editorial error "(1865-04-07 - 1868-09-07)" as the Meiji range in the JapaneseChronology API doc. - Remove JapaneseEra.SEIREKI as ill defined and unnecessary; - Update the signature of ChronoLocalDate.atTime The webrev also includes the proposed change for JDK-8020418: Cleanup of -Xlint warnings in java.time Thanks, -Sherman From xueming.shen at oracle.com Wed Jul 17 09:58:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 17 Jul 2013 09:58:36 -0700 Subject: [threeten-dev] jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Message-ID: <51E6CD3C.9040306@oracle.com> Roger, It appears this test has the non-ascii character in the source code, ideally it should be use \uxxxx for non-ascii character here (run the native2ascii with appropriate encoding, for example). I'm not familiar with this test, can you help take a look? -Sherman ------------------------------------------------------------------------------------------------ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: error: unmappable character for encoding ASCII {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month name is Rabi Al-Awwal, but the locale data contains short form. ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: error: unmappable character for encoding ASCII {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month name is Rabi Al-Awwal, but the locale data contains short form. ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: error: unmappable character for encoding ASCII {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual month name is Rabi Al-Akhar, but the locale data contains short form. ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: error: unmappable character for encoding ASCII {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual month name is Rabi Al-Akhar, but the locale data contains short form. ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: error: unmappable character for encoding ASCII {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: error: unmappable character for encoding ASCII {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: error: unmappable character for encoding ASCII {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: error: unmappable character for encoding ASCII {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: error: unmappable character for encoding ASCII {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: error: unmappable character for encoding ASCII {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: error: unmappable character for encoding ASCII {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, ^ /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: error: unmappable character for encoding ASCII {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, ^ From roger.riggs at oracle.com Wed Jul 17 10:07:31 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 17 Jul 2013 13:07:31 -0400 Subject: [threeten-dev] jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java In-Reply-To: <51E6CD3C.9040306@oracle.com> References: <51E6CD3C.9040306@oracle.com> Message-ID: <51E6CF53.9060408@oracle.com> Hi Sherman, Yes, I'll take a look, it came from Basha originally. Roger On 7/17/2013 12:58 PM, Xueming Shen wrote: > Roger, > > It appears this test has the non-ascii character in the source code, > ideally it should > be use \uxxxx for non-ascii character here (run the native2ascii with > appropriate > encoding, for example). I'm not familiar with this test, can you help > take a look? > > -Sherman > > ------------------------------------------------------------------------------------------------ > > > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: > error: unmappable character for encoding ASCII > {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month > name is Rabi Al-Awwal, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: > error: unmappable character for encoding ASCII > {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month > name is Rabi Al-Awwal, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: > error: unmappable character for encoding ASCII > {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual > month name is Rabi Al-Akhar, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: > error: unmappable character for encoding ASCII > {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual > month name is Rabi Al-Akhar, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: > error: unmappable character for encoding ASCII > {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: > error: unmappable character for encoding ASCII > {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: > error: unmappable character for encoding ASCII > {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: > error: unmappable character for encoding ASCII > {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, > ^ From roger.riggs at oracle.com Wed Jul 17 10:13:49 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 17 Jul 2013 13:13:49 -0400 Subject: [threeten-dev] jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java In-Reply-To: <51E6CD3C.9040306@oracle.com> References: <51E6CD3C.9040306@oracle.com> Message-ID: <51E6D0CD.9080408@oracle.com> Hi Sherman, I don't know why that didn't show up earlier. You can either run native2ascii (from a JDK bin directory) or replace the characters with \u02bb Roger On 7/17/2013 12:58 PM, Xueming Shen wrote: > Roger, > > It appears this test has the non-ascii character in the source code, > ideally it should > be use \uxxxx for non-ascii character here (run the native2ascii with > appropriate > encoding, for example). I'm not familiar with this test, can you help > take a look? > > -Sherman > > ------------------------------------------------------------------------------------------------ > > > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: > error: unmappable character for encoding ASCII > {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month > name is Rabi Al-Awwal, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:425: > error: unmappable character for encoding ASCII > {1434, 3, 1, "01 AH Sun Rabi?? I 1434"},//the actual month > name is Rabi Al-Awwal, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: > error: unmappable character for encoding ASCII > {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual > month name is Rabi Al-Akhar, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:426: > error: unmappable character for encoding ASCII > {1434, 4, 1, "01 AH Mon Rabi?? II 1434"},//the actual > month name is Rabi Al-Akhar, but the locale data contains short form. > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: > error: unmappable character for encoding ASCII > {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:430: > error: unmappable character for encoding ASCII > {1434, 8, 1, "01 AH Mon Sha??ban 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:433: > error: unmappable character for encoding ASCII > {1434, 11, 1, "01 AH Sat Dhu??l-Qi??dah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: > error: unmappable character for encoding ASCII > {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, > ^ > /opt/jprt/T/P1/172757.sherman/s/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java:434: > error: unmappable character for encoding ASCII > {1434, 12, 1, "01 AH Sun Dhu??l-Hijjah 1434"}, > ^ From xueming.shen at oracle.com Thu Jul 18 09:48:06 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Jul 2013 09:48:06 -0700 Subject: [threeten-dev] src/share/classes/java/time/format/DateTimeFormatter.java Message-ID: <51E81C46.1050802@oracle.com> Roger, It appears the @return is being dropped in the new source, I would assume it's not intentional? http://cr.openjdk.java.net/~sherman/8016025/webrev/src/share/classes/java/time/format/DateTimeFormatter.java.sdiff.html -Sherman