From xueming.shen at oracle.com Mon Dec 3 10:22:58 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Dec 2012 10:22:58 -0800 Subject: [threeten-dev] lambda + threeten Message-ID: <50BCEE02.8030002@oracle.com> I experimented the lambda repo + threeten repo to see how much we might need to do when lambda stuff gets into the master. While it still took couple hours to (lots of emacs editing...) sort everything out, it appears it can be done smoothly in hours. The only issue (not straightforward/simply copy/paste) I found is that three j.l.Object methods equals/hashCode/toString can NOT be default-method-ed in ChronoLocalD/DT/ODT/ZDT. It appears to be not allowed. Sorry, if this is a well-known spec that I'm not aware of , I'm a lambda newbie:-) they need to be simply defined as @override method and the (default) impl need to go into their corresponding impl classes. I'm not sure if all those utility methods in "jdk8Methods" have been in jdk8, so I did not touch them this time. But at least so of them are there already. Should we just migrate? Here is the java doc for the combined threeten_lambda http://cr.openjdk.java.net/~sherman/jdk8_threeten/api_lambda/ The webrev/diff for the changes, if interested. http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM And yes, I have my first lambda + threeten test, and trying Stephen's fancy functional interfaces With/MinusAdjuster :-) I might write a blog for our first lambda+threeten repo/binary. -Sherman -------------------------------------------------------------------- LocalDateTime now = LocalDateTime.now(); Random r = new Random(); DateTimeFormatter fmt = DateTimeFormatters.pattern("yyyy-MM-dd HH:mm:ss [EEEE]"); int total = 100; int days = 2; // days to delay int minMon = 2; int maxMon = 6; Streams.repeatedly(total, () -> (now.withYear(2012) .withDayOfYear(r.nextInt(365) + 1) .with(SECOND_OF_DAY, r.nextInt(86400)))) .sorted((d1, d2) -> d1.compareTo(d2)) // .filter(d -> (d.getMonthValue() >= minMon && d.getMonthValue() <= maxMon)) .tee(d -> {System.out.printf(" %-30s ", fmt.print(d));}) .map(d -> (d.with(dd -> (dd.with(EPOCH_DAY, dd.getLong(EPOCH_DAY) + days))))) .tee(d -> {System.out.printf(" --> %-30s ", fmt.print(d));}) .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, (dd.getLong(EPOCH_DAY)- days)))))) .forEach(d -> {System.out.printf(" --> %-30s%n", fmt.print(d));}); From Roger.Riggs at oracle.com Mon Dec 3 10:32:02 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 03 Dec 2012 13:32:02 -0500 Subject: [threeten-dev] lambda + threeten In-Reply-To: <50BCEE02.8030002@oracle.com> References: <50BCEE02.8030002@oracle.com> Message-ID: <50BCF022.8040204@oracle.com> Hi Sherman, Its great to see this. On 12/3/2012 1:22 PM, Xueming Shen wrote: > > I experimented the lambda repo + threeten repo to see how much we > might need to do when lambda stuff gets into the master. While it still > took couple hours to (lots of emacs editing...) sort everything out, it > appears it can be done smoothly in hours. > > The only issue (not straightforward/simply copy/paste) I found is that > three j.l.Object methods equals/hashCode/toString can NOT be > default-method-ed in ChronoLocalD/DT/ODT/ZDT. It appears to be not > allowed. Sorry, if this is a well-known spec that I'm not aware of , I'm > a lambda newbie:-) they need to be simply defined as @override > method and the (default) impl need to go into their corresponding impl > classes. > > I'm not sure if all those utility methods in "jdk8Methods" have been > in jdk8, so I did not touch them this time. But at least so of them > are there already. Should we just migrate? Yes, as is the github version can be used with JDK 7. After we commit to mercurial, we can change to the java.math versions. > > Here is the java doc for the combined threeten_lambda > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/api_lambda/ > > The webrev/diff for the changes, if interested. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM > > And yes, I have my first lambda + threeten test, and trying Stephen's > fancy functional interfaces With/MinusAdjuster :-) > > I might write a blog for our first lambda+threeten repo/binary. I don't know what the non-lambda code would look like but the lambda'fied code below is not good at revealing what the intent of the function is. It still needs comments. So blog away. Thanks,Roger > > -Sherman > > -------------------------------------------------------------------- > LocalDateTime now = LocalDateTime.now(); > Random r = new Random(); > > DateTimeFormatter fmt = > DateTimeFormatters.pattern("yyyy-MM-dd HH:mm:ss [EEEE]"); > > int total = 100; > int days = 2; // days to delay > int minMon = 2; > int maxMon = 6; > > Streams.repeatedly(total, () -> (now.withYear(2012) > > .withDayOfYear(r.nextInt(365) + 1) > .with(SECOND_OF_DAY, > r.nextInt(86400)))) > .sorted((d1, d2) -> d1.compareTo(d2)) > // .filter(d -> (d.getMonthValue() >= minMon && > d.getMonthValue() <= maxMon)) > .tee(d -> {System.out.printf(" %-30s ", fmt.print(d));}) > .map(d -> (d.with(dd -> (dd.with(EPOCH_DAY, > dd.getLong(EPOCH_DAY) + days))))) > .tee(d -> {System.out.printf(" --> %-30s ", > fmt.print(d));}) > .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, > (dd.getLong(EPOCH_DAY)- days)))))) > .forEach(d -> {System.out.printf(" --> %-30s%n", > fmt.print(d));}); > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From brian.goetz at oracle.com Mon Dec 3 10:36:04 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 03 Dec 2012 13:36:04 -0500 Subject: [threeten-dev] lambda + threeten In-Reply-To: <50BCEE02.8030002@oracle.com> References: <50BCEE02.8030002@oracle.com> Message-ID: <50BCF114.5010805@oracle.com> Yes, this was an extensively discussed point in the EG. It came down to consistency in philosophy and user model. The philosophy argument is: default methods are designed for evolving interfaces. Yes, they can be used as a form of traits-lite, which is fine as far as this goes (and it goes pretty far), so long as you don't go all wishful-thinking on us and pretend they are full-blown traits. The desire to let interface methods provide implementations for Object methods is really a way of saying "but I want this to be traits." As long as you think about it as "glass 98% full" rather than "glass 2% empty", you're fine :) The user-model argument is: we have dramatically reduced the pain surrounding reasoning about multiple inheritance by adopting some very simple rules, the foremost of which is "class methods always win." If there is an implementation on the class hierarchy, we don't even look at the interface hierarchy. Not only does this guarantee compatibility, it is very simple to reason about. This means that anything inherited from Object wins. We could have, of course, changed the rules, but that would have made the feature more complicated to address a use case that is already sliding down a slippery slope; attempts to define Object methods in interfaces assumes that you are using those interfaces as if they can only be singly inherited. The reality is that methods like toString, equals, and hashCode are tightly bound to the object's state, and the state lives in the class, not the interfaces. Unless we could enforce that only one interface was managing the state, such a feature would cause more trouble than it solves. Default methods may reduce the need for abstract classes, but they don't eliminate it. Fields are one reason we still need them; Object methods are another. Glad to hear the conversion was mostly painless! On 12/3/2012 1:22 PM, Xueming Shen wrote: > > I experimented the lambda repo + threeten repo to see how much we > might need to do when lambda stuff gets into the master. While it still > took couple hours to (lots of emacs editing...) sort everything out, it > appears it can be done smoothly in hours. > > The only issue (not straightforward/simply copy/paste) I found is that > three j.l.Object methods equals/hashCode/toString can NOT be > default-method-ed in ChronoLocalD/DT/ODT/ZDT. It appears to be not > allowed. Sorry, if this is a well-known spec that I'm not aware of , I'm > a lambda newbie:-) they need to be simply defined as @override > method and the (default) impl need to go into their corresponding impl > classes. > > I'm not sure if all those utility methods in "jdk8Methods" have been > in jdk8, so I did not touch them this time. But at least so of them > are there already. Should we just migrate? > > Here is the java doc for the combined threeten_lambda > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/api_lambda/ > > The webrev/diff for the changes, if interested. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM > > And yes, I have my first lambda + threeten test, and trying Stephen's > fancy functional interfaces With/MinusAdjuster :-) > > I might write a blog for our first lambda+threeten repo/binary. > > -Sherman > > -------------------------------------------------------------------- > LocalDateTime now = LocalDateTime.now(); > Random r = new Random(); > > DateTimeFormatter fmt = > DateTimeFormatters.pattern("yyyy-MM-dd HH:mm:ss [EEEE]"); > > int total = 100; > int days = 2; // days to delay > int minMon = 2; > int maxMon = 6; > > Streams.repeatedly(total, () -> (now.withYear(2012) > > .withDayOfYear(r.nextInt(365) + 1) > .with(SECOND_OF_DAY, > r.nextInt(86400)))) > .sorted((d1, d2) -> d1.compareTo(d2)) > // .filter(d -> (d.getMonthValue() >= minMon && > d.getMonthValue() <= maxMon)) > .tee(d -> {System.out.printf(" %-30s ", fmt.print(d));}) > .map(d -> (d.with(dd -> (dd.with(EPOCH_DAY, > dd.getLong(EPOCH_DAY) + days))))) > .tee(d -> {System.out.printf(" --> %-30s ", > fmt.print(d));}) > .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, > (dd.getLong(EPOCH_DAY)- days)))))) > .forEach(d -> {System.out.printf(" --> %-30s%n", > fmt.print(d));}); > From xueming.shen at oracle.com Mon Dec 3 10:48:41 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Dec 2012 10:48:41 -0800 Subject: [threeten-dev] lambda + threeten In-Reply-To: <50BCF022.8040204@oracle.com> References: <50BCEE02.8030002@oracle.com> <50BCF022.8040204@oracle.com> Message-ID: <50BCF409.4010503@oracle.com> It's the test for the "fancy" functional interface :-) for example, for the "minus adjuster" here you can simply use .map(d -> (d.minusDays(days))) instead of .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, (dd.getLong(EPOCH_DAY)- days)))))) And the test does nothing:-) it simply adds two days, print them out, and then map them back to the original data. -Sherman On 12/03/2012 10:32 AM, Roger Riggs wrote: > Hi Sherman, > > > I don't know what the non-lambda code would look like but the lambda'fied > code below is not good at revealing what the intent of the function is. > It still needs comments. So blog away. > > Thanks,Roger > >> >> -Sherman >> >> -------------------------------------------------------------------- >> LocalDateTime now = LocalDateTime.now(); >> Random r = new Random(); >> >> DateTimeFormatter fmt = >> DateTimeFormatters.pattern("yyyy-MM-dd HH:mm:ss [EEEE]"); >> >> int total = 100; >> int days = 2; // days to delay >> int minMon = 2; >> int maxMon = 6; >> >> Streams.repeatedly(total, () -> (now.withYear(2012) >> .withDayOfYear(r.nextInt(365) + 1) >> .with(SECOND_OF_DAY, r.nextInt(86400)))) >> .sorted((d1, d2) -> d1.compareTo(d2)) >> // .filter(d -> (d.getMonthValue() >= minMon && d.getMonthValue() <= maxMon)) >> .tee(d -> {System.out.printf(" %-30s ", fmt.print(d));}) >> .map(d -> (d.with(dd -> (dd.with(EPOCH_DAY, dd.getLong(EPOCH_DAY) + days))))) >> .tee(d -> {System.out.printf(" --> %-30s ", fmt.print(d));}) >> .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, (dd.getLong(EPOCH_DAY)- days)))))) >> .forEach(d -> {System.out.printf(" --> %-30s%n", fmt.print(d));}); >> > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to developing practices and products that help protect the environment > From xueming.shen at oracle.com Mon Dec 3 11:32:20 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 03 Dec 2012 19:32:20 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added directories javax.time.chrono.global and jdk8 docs list Message-ID: <20121203193314.29E4F47CFB@hg.openjdk.java.net> Changeset: 3146d42896d0 Author: sherman Date: 2012-12-03 11:30 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3146d42896d0 Added directories javax.time.chrono.global and jdk8 docs list ! make/docs/CORE_PKGS.gmk From Roger.Riggs at oracle.com Mon Dec 3 12:29:36 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 03 Dec 2012 15:29:36 -0500 Subject: [threeten-dev] Fwd: [threeten-develop] Updated ZDT/ODT In-Reply-To: References: Message-ID: <50BD0BB0.6070601@oracle.com> fyi, The changes to refactor and decouple OffsetDateTime from ZoneDateTime have been completed and will be merged into the mercurial repository soon. This addresses the underlying issue in #148 without removing ODT: https://github.com/ThreeTen/threeten/issues/148 Please send comments to both threeten-dev at openjdk.java.net and threeten-develop at lists.sourceforge.net. -------- Original Message -------- Subject: [threeten-develop] Updated ZDT/ODT Date: Mon, 3 Dec 2012 01:10:19 +0000 From: Stephen Colebourne Reply-To: threeten-develop at lists.sourceforge.net To: threeten-develop at lists.sourceforge.net The updated ZonedDateTime, OffsetDateTime, ZoneId and ZoneOffset are now in github master. Reviews welcome. Javadoc http://threeten.github.com/threeten/dev/javadoc/index.html Code https://github.com/ThreeTen/threeten thanks Stephen From xueming.shen at oracle.com Mon Dec 3 18:14:06 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Dec 2012 18:14:06 -0800 Subject: [threeten-dev] lambda + threeten In-Reply-To: References: <50BCEE02.8030002@oracle.com> <50BCF022.8040204@oracle.com> <50BCF409.4010503@oracle.com> Message-ID: <50BD5C6E.40609@oracle.com> We do have LocalDateTime.minusDays(long) to return LDT. Where does the DateTime come from. It appears all three work. "fluent" .map(d -> (d.minusDays(days))) long, field .map(d -> (d.minus(days, DAYS))) minusAdjuster .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, (dd.getLong(EPOCH_DAY)- days)))))) One of the reasons that I thought the API provides too many ways to do the same thing. -sherman On 12/3/12 4:40 PM, Stephen Colebourne wrote: > .map(d -> (d.minusDays(days))) > would not work (as the type is DateTime), but this will work: > .map(d -> (d.minus(days, DAYS))) > > It would be worth exploring if generics could be added to > WithAdjuster/MinusAdjuster etc to allow lambda adjusters to capture > the actual target type, and thus allow methods like minusDays() to be > called. I suspect it doesn't work, but it should be tried. > > Stephen > > > On 3 December 2012 18:48, Xueming Shen > wrote: > > > It's the test for the "fancy" functional interface :-) for > example, for > the "minus adjuster" here you can simply use > > .map(d -> (d.minusDays(days))) > instead of > .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, > (dd.getLong(EPOCH_DAY)- days)))))) > > And the test does nothing:-) it simply adds two days, print them > out, and then > map them back to the original data. > > -Sherman > > > On 12/03/2012 10:32 AM, Roger Riggs wrote: >> Hi Sherman, >> >> >> >> I don't know what the non-lambda code would look like but the >> lambda'fied >> code below is not good at revealing what the intent of the >> function is. >> It still needs comments. So blog away. >> >> Thanks,Roger >> >>> >>> -Sherman >>> >>> -------------------------------------------------------------------- >>> >>> LocalDateTime now = LocalDateTime.now(); >>> Random r = new Random(); >>> >>> DateTimeFormatter fmt = >>> DateTimeFormatters.pattern("yyyy-MM-dd HH:mm:ss >>> [EEEE]"); >>> >>> int total = 100; >>> int days = 2; // days to delay >>> int minMon = 2; >>> int maxMon = 6; >>> >>> Streams.repeatedly(total, () -> (now.withYear(2012) >>> .withDayOfYear(r.nextInt(365) + 1) >>> .with(SECOND_OF_DAY, r.nextInt(86400)))) >>> .sorted((d1, d2) -> d1.compareTo(d2)) >>> // .filter(d -> (d.getMonthValue() >= minMon && >>> d.getMonthValue() <= maxMon)) >>> .tee(d -> {System.out.printf(" %-30s ", >>> fmt.print(d));}) >>> .map(d -> (d.with(dd -> (dd.with(EPOCH_DAY, >>> dd.getLong(EPOCH_DAY) + days))))) >>> .tee(d -> {System.out.printf(" --> %-30s ", >>> fmt.print(d));}) >>> .map(d -> (d.minus(dd -> (dd.with(EPOCH_DAY, >>> (dd.getLong(EPOCH_DAY)- days)))))) >>> .forEach(d -> {System.out.printf(" --> >>> %-30s%n", fmt.print(d));}); >>> >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is >> committed to developing practices and products that help protect >> the environment >> > > From yoshito_umaoka at us.ibm.com Tue Dec 4 05:48:31 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 4 Dec 2012 07:48:31 -0600 Subject: [threeten-dev] Handling Leap Month in Chronology subclass Message-ID: Hello all, I recently walked through JSR-310 APIs in detail. In general, overall design looked great and I did not see any major issues. I have one question about implementing Chronology subclass supporting Chinese calendar and its variants. Chinese calendar is a lunisolar calendar system and leap month might be inserted at certain rule. It differs from Hijrah calendar that insert leap month at the end of year cycle (13th month). In ICU project, we found than leap months in Chinese calendar require extra field to indicate leap month. This is doable with java.util.Calendar subclass, although additional field is a little bit tricky. I'm wondering if there is a good way to support such calendar with JSR-310 Chronology without messing up month numbering. I have a few more minor comments about JSR-310 design and will post them in a separate message. Thanks, Yoshito Umaoka (ICU Project at IBM) From Roger.Riggs at oracle.com Tue Dec 4 08:20:16 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 04 Dec 2012 11:20:16 -0500 Subject: [threeten-dev] Switching to the OpenJDK threeten-dev repository Message-ID: <50BE22C0.8000404@oracle.com> A reminder that as of the end of today (Dec 4th) we should mainly be using the threeten-dev mercurial repository. The change will allow more efficient integration with the JDK. http://openjdk.java.net/projects/threeten/ The github issue tracker will continue to be used on Github. I will complete the merging of any commit from github through dated (Dec 4th). (This last round of updates has been particularly manual.) I'll send an email when I have completed the merges. After today, changes can be made to the github repository but each developer will need to do their own merges into the threeten-dev repository. Roger From scolebourne at joda.org Tue Dec 4 10:20:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 4 Dec 2012 18:20:38 +0000 Subject: [threeten-dev] Handling Leap Month in Chronology subclass In-Reply-To: References: Message-ID: On 4 December 2012 13:48, wrote: > I have one question about implementing Chronology subclass supporting > Chinese calendar and its variants. > > Chinese calendar is a lunisolar calendar system and leap month might be > inserted at certain rule. It differs from Hijrah calendar that insert leap > month at the end of year cycle (13th month). > In ICU project, we found than leap months in Chinese calendar require > extra field to indicate leap month. This is doable with java.util.Calendar > subclass, although additional field is a little bit tricky. > > I'm wondering if there is a good way to support such calendar with JSR-310 > Chronology without messing up month numbering. I think this is a good question. My feeling is that an additional field that only has meaning in the Chinese calendar system is hard for users, as the vast majority of users won't know it exists, and thus end up with the wrong date in calculations. The main alternatives are - the month-of-year is a count rather than with reference to the local month number. So if the months go 1,2,3,3,4,5 then the count would go 1,2,3,4,5,6 - the extra month is treated as additional days of the month. So rather than having 30 days, the month has 60 days (or whatever the correct rule is). Neither of these are pretty or nice, but they are effective (on the development side). The second part of the problem is then mapping the value back to something meaningful during printing/parsing. I suspect that the additional days-of-month approach is easier to process. eg if (dayOfMonth > 30) { // output month indicator and (dayOfMonth - 30) } else { // dayOfMonth } However I do not know without further consideration what would could be used to trigger this logic. Look forward to your other comments. Stephen From scolebourne at joda.org Tue Dec 4 10:23:47 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 4 Dec 2012 18:23:47 +0000 Subject: [threeten-dev] Zone or Zoned DateTime Message-ID: Views on this please. Should we stick with ZonedDateTime, or change to ZoneDateTime? It is one letter difference, and not much semantic difference. I'm so used to Zoned that I don't really think about it, but if there are lots of arguments for Zone then I might consider a change. Stephen From Roger.Riggs at oracle.com Tue Dec 4 11:26:03 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 04 Dec 2012 14:26:03 -0500 Subject: [threeten-dev] Zone or Zoned DateTime In-Reply-To: References: Message-ID: <50BE4E4B.4050000@oracle.com> Hi, I would go with ZoneDateTime; similar to OffsetDateTime the qualifier is a noun describing the extra data. But given the trouble I've had with patching files including renames across repositories, I'd wait until tomorrow to rename it in the Mercurial repository. Roger On 12/4/2012 1:23 PM, Stephen Colebourne wrote: > Views on this please. > > Should we stick with ZonedDateTime, or change to ZoneDateTime? > > It is one letter difference, and not much semantic difference. I'm so > used to Zoned that I don't really think about it, but if there are > lots of arguments for Zone then I might consider a change. > > Stephen -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Dec 4 11:53:41 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 04 Dec 2012 11:53:41 -0800 Subject: [threeten-dev] Zone or Zoned DateTime In-Reply-To: <50BE4E4B.4050000@oracle.com> References: <50BE4E4B.4050000@oracle.com> Message-ID: <50BE54C5.3060200@oracle.com> Agreed. ZoneDateTime is better than ZonedDateTime, and do it in the jdk8 threeten repository:-) Let me try one more time on "ZoneId -> Zone" naming. Zone can be defined/specified as an abstraction/identity/id of a "zone", not necessary to explicitly to have the "id" in its name. It a lightweight abstraction, immutable, similar to what we do for the Locale. I believe the name "ZoneId" originally came from the idea of separating the "id" and the "rules", put the "id" into the name may help. But it does not appear to me too bad to name it "Zone", as the abstraction of the time zone, and this thing has its "rule", we call it ZoneRules... Especially, now we have ZoneOffset subclass ZoneId, it is a little hard(?) to explain a "offset" is a subclass of a "id", but it's easy/natural to say ZoneOffset is a special "Zone". Personally I feel Zone fits well into the rest of the "zone" family. -Sherman On 12/04/2012 11:26 AM, Roger Riggs wrote: > Hi, > > I would go with ZoneDateTime; similar to OffsetDateTime the qualifier > is a noun describing the extra data. > > But given the trouble I've had with patching files including renames across repositories, > I'd wait until tomorrow to rename it in the Mercurial repository. > > Roger > > > On 12/4/2012 1:23 PM, Stephen Colebourne wrote: >> Views on this please. >> >> Should we stick with ZonedDateTime, or change to ZoneDateTime? >> >> It is one letter difference, and not much semantic difference. I'm so >> used to Zoned that I don't really think about it, but if there are >> lots of arguments for Zone then I might consider a change. >> >> Stephen > From xueming.shen at oracle.com Tue Dec 4 15:32:43 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 04 Dec 2012 15:32:43 -0800 Subject: [threeten-dev] take down two fmt providers Message-ID: <50BE881B.5000905@oracle.com> This change is to take the "text" and "style" providers to be private and then later hook up with those jdk8 calendar/data provider. http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmt_Provider/ -Sherman From Brian.Harris at morganstanley.com Tue Dec 4 14:03:38 2012 From: Brian.Harris at morganstanley.com (Harris, Brian) Date: Tue, 4 Dec 2012 22:03:38 +0000 Subject: [threeten-dev] [threeten-develop] Zone or Zoned DateTime In-Reply-To: References: Message-ID: <28F1E4DF81064C4E8C89AE6007D2091116BF3EE2@HZWEX2009N4.msad.ms.com> I prefer ZoneDateTime because its less awkward to say aloud, and aligns with other Zone* classes. But mostly because it's nicer to say. -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Tuesday, December 04, 2012 10:24 AM To: threeten-develop at lists.sourceforge.net Cc: threeten-dev at openjdk.java.net Subject: [threeten-develop] Zone or Zoned DateTime Views on this please. Should we stick with ZonedDateTime, or change to ZoneDateTime? It is one letter difference, and not much semantic difference. I'm so used to Zoned that I don't really think about it, but if there are lots of arguments for Zone then I might consider a change. Stephen ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ threeten-develop mailing list threeten-develop at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From yoshito_umaoka at us.ibm.com Tue Dec 4 20:02:29 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 4 Dec 2012 22:02:29 -0600 Subject: [threeten-dev] javax.time.format.DateTimeFormattter#toFormat(Class parseType) API specification Message-ID: Hi all, I have some comments and questions about public Format DateTimeFormatter#toFormat(Class parseType) API specification [ http://threeten.sourceforge.net/apidocs-2012-10-25/javax/time/format/DateTimeFormatter.html#toFormat%28java.lang.Class%29 ]. The specification says: "Returns this formatter as a java.text.Format instance that will parse to the specified type." I think the implementation is likely supporting only some known object types and the method would throw IllegalArgumentException or something if the given parseType is not supported. I think the spec should clarify what kind of argument is likely supported here and type of exception (or returning null?) when unsupported type is specified. Also, it says: "The format will throw IndexOutOfBoundsException in line with those thrown by the print and parse methods." This description does not sound right. My understanding is "The format" is an instance of java.text.Format subclass. Format defines two parse methods - 1) Object parseObject(String) and 2) abstract Object parseObject(String, ParsePosition) - I do not know what "print" method in the spec actually means (Format defines "format" methods, not "print"). In addition to these, it's difficult to understand why IndexOutOfBoundsException might be thrown by "The format". By the contract of java.textFormat, format method should not throw any exception and parseObject should throw java.text.ParseException on parse failure. So I have no idea where this IndexOutOfBoundsException come from. Thanks, Yoshito Umaoka (ICU Project at IBM) From yoshito_umaoka at us.ibm.com Tue Dec 4 20:36:48 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 4 Dec 2012 22:36:48 -0600 Subject: [threeten-dev] Possible addition of pattern letters in CLDR Message-ID: public static DateTimeFormatter pattern(String pattern) is quite interesting. It mentions - "The pattern string is also similar, but not identical, to that defined by the Unicode Common Locale Data Repository (CLDR)." With my quick review, following pattern letters are not available in LDML specification n nano-of-second number/fraction 987654321 N nano-of-day number/fraction 1234000000 I time-zone ID zoneID America/Los_Angeles I think all of these make sense. In longer term, I don't want to see different pattern definition across similar implementations. If these are final, I'm happy to work on CLDR side and propose these pattern letters registered in the LDML specification. X zone-offset 'Z' for zero offset-X Z; -0800; -08:00; This one is tricky. We recently added ISO 8601 style offset format in the LDML specification with "ZZZZZ" LDML "ZZZZZ" formats UTC to "Z" and non-UTC offsets using longer format such as "-08:00" (with colon). Z zone-offset offset-Z +0000; -0800; -08:00; On the other hand, pattern letter "Z" in the LDML specification uses the following definition- Z, ZZ, ZZZ -> RFC822 format ZZZZ -> Localized GMT format, such as "GMT-08:00" "UTC-08:00"... I personally think CLDR may introduce pattern X, supporting both long/short offset format, and deprecate "ZZZZZ" (or simply leave it as an alias definition). For offset format, CLDR community is now seeking for shorter offset format support. For example, "GMT-3" instead of "GMT-03:00". Anyway, I'll consult with CLDR community members to find out if CLDR can provide compatible definitions for these too. Thanks, Yoshito Umaoka (ICU Project at IBM) From yoshito_umaoka at us.ibm.com Tue Dec 4 20:54:56 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 4 Dec 2012 22:54:56 -0600 Subject: [threeten-dev] Era value Message-ID: This is purely a question - not pointing out any issues in the spec. The Era#getValue() spec says: "The era in use at 1970-01-01 must have the value 1...." I'm wondering if this requirement is really necessary. In some calendar systems, there is only one era (well, conceptually, nothing before epoch). Of course, we could artificially invent post epoch era as era 0. Also, Japanese/Chinese dynasty eras could be over 100. If we use an era including 1970-01-01 as era 1, era value could ends up 3 digits negative value, which just look awkward. I was thinking about the reason behind this, but I could not see any convincing reasons. Can someone explain why this is a requirement? Thanks, Yoshito Umaoka (ICU Project at IBM) From xueming.shen at oracle.com Tue Dec 4 22:13:21 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 04 Dec 2012 22:13:21 -0800 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> Message-ID: <50BEE601.7080200@oracle.com> Agree this should be discussed in public mailing list. My fault, I thought I was asking a simple/solved question:-) My take on this is that we should provide a bridge between these two systems, but not integrate these two together (in which you try to provide convenient conversion between all those different date/time types, or even go a little further to make it possible to access all corresponding threeten fields from a GregorianCalendar). Date <-> Instant appears to be a must, in which it provides the connection/conversion at the bottom between two different systems, so we don't need Date <-> ODT for example. How to support the Date <-> Instant? I believe we only need ONE straightforward/direct conversion, don't need to provide multiple convenient vehicles here, developer should just use this entry point to convert between these two types. As you suggested, use nio.file as an example, a simple pair of File.toPath() and Path.toFile() should be good enough. Date.toInstant() and "util.Date must support the same fields as Instant - INSTANT_SECONDS and the three fractional seconds fields" are obviously redundant. With this, now you can do Date date = ...; Instant instant = date.toInstant(); or Instant instant = Instant.from(date); If we don't need two, which one is better? DateTimeAccessor appears to be convenient, with this, you can also do OffsetDateTime.from(date), and any "extended" date/time that knows INSTANT_SECONDS+fractional sec fields can work with u.Date as well. But it also brings us the biggest problem, all of the sudden, j.u.Date can fly freely inside the new JSR310 system. Conveniently, our datetime formatter also magically work with j.u.Date. Is this something you want to see? It appears to be an integration of two systems, not a bridge. Sure, it provides convenience, but it also has the consequence, you now have a mutable DateTimeAccessor running around your JSR310 code. So personally I think a simple Date.toInstant() is the best choice, it provide a "single" entry point for all those "old" date/time. The code that uses JSR310 date/time should just work with new date/time, old date/time need to be converted into new types to get in. A Instant.toDate() will be a little confusing, I would suggest just do Date.fromInstant(). So my vote will be Date.to/fromInstant(). In theory, it's doable to bridge the conversion of GregorianCalendar and ZDT by GregorianCalendar <-> Date <-> Instant <-> ZDT, but obviously the "zone" is missing, it's probably not desirable to use "default". So, it appears GregorianCalendar <-> ZDT is another candidate. For same reason I mentioned above, I don't think you want to "integrate" GregorianCalendar into the new system, stop it by forcing it to be the immutable ZDT before any new code can touch it. Otherwise, the worse thing is that, not like j.u.Date, those "setting" methods of GregorianCalendar are not deprecated. Should we do the Calendar <-> Instant, personally I don't think we want to do it. There is a direct conversion between Date <-> Calendar via setTime/getTimeInMillis, so I don't think developer will whine too much on missing a "convenient" direct conversion between these two. But I will probably not be too strong to against the idea of having to/fromInstant() pair on it, especially the toInstant(), given Calendar/GregrianCalendar is one of the most frequently used date/time types in current system. -Sherman On 12/4/12 2:56 PM, Stephen Colebourne wrote: > This should really be public... > > On 4 December 2012 19:46, Roger Riggs wrote: >> I'd like to see the simplest practical coupling. >> >> I'd rather developers get used to use the 310 types.from() methods to convert. > The closest JDK parallel is the addition of the new file system API. > The old one - File - has a method toPath(). The same principle applies > here. Not having toInstant() is just being mean to developers. > >> In my opinion, the classes should implement DateTimeAccessor. They >> should also have some additional methods: >> Date.toInstant() >> Date.from(DateTimeAccessor) >> Calendar.toInstant() >> Calendar.from(DateTimeAccessor) >> GregorianCalendar.toZonedDateTime() >> GregorianCalendar.from(DateTimeAccessor) >> >> What fields are required to say it supports DateTimeAccessor? > util.Date must support the same fields as Instant - INSTANT_SECONDS > and the three fractional seconds fields. > Calendar is the same. > GregorianCalendar should support the full range of additional fields. > > Supporting only ZoneId, which would be enough for conversion to ZDT, > is possible with a future JDK adding the remaining fields. However, > this would be a violation of the spirit of DateTimeAccessor though, > and I suspect users would complain. > >> GregorianCalendar might benefit from toLocalDate() and toLocalTime(). >> >> Special handling will be needed for the sql subtypes of util.Date - >> sql.Date, sql.Time and sql.Timestamp. >> >> If JDBC is going to encourage using the new 310 types then >> these do not need to be enhanced. > If util.Date implements DateTimeAccessor then these three classes > *have* to be dealt with too. They will inherit the implementation from > util.Date, which is entirely wrong for the three subclasses. > > sql.Date should act like a LocalDate, sql.Time like a LocalTime > (confirm with Douglas). Neither should return INSTANT_SECONDS. > > >> xml.XMLGregorianCalendar should implement DateTimeAccessor >> >> xml.Duration should implement PlusAdjuster and MinusAdjuster >> >> I'd leave these out, it encourages mixing APIs; not just interoperation >> >> TimeUnit should implement PeriodUnit >> (DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is >> exactly 24 hours) >> >> Keep the cross coupling of the APIs to what is really needed, >> mixing the APIs will make developers dizzy. >> >> FileTime should implement DateTimeAccessor >> (amusingly, the toString method follows the broken XML Schema text >> which wrongly has the year before 0001 as -0001). >> >> We'll need to consult with the other API owners about the couplings. > Ultimately these APIs are outside 310/my control. It is my opinion > that the above should be implemented, and if they are not developers > will have a harder job than they should. In addition, some conversions > (like FileTime) may be tricky (due to the missing year zero) so these > implementations will actually reduce bugs. > > I do know that the developers of FileTime considered using 310 but the > schedules obviously didn't match up. > > Stephen From xueming.shen at oracle.com Tue Dec 4 22:33:33 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:33:33 +0000 Subject: [threeten-dev] hg: threeten/threeten: 45 new changesets Message-ID: <20121205063336.5241D47E00@hg.openjdk.java.net> Changeset: 56264ff5e1d5 Author: katleman Date: 2012-09-13 13:14 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/56264ff5e1d5 Added tag jdk8-b56 for changeset 76844579fa4b ! .hgtags Changeset: 2ba6f4da4bf3 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/2ba6f4da4bf3 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! .hgignore ! Makefile + NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 + common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 + common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh + common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/spec.sh.in ! common/autoconf/toolchain.m4 + common/bin/boot_cycle.sh ! common/bin/compare-objects.sh + common/bin/test_builds.sh + common/bin/unicode2x.sed + common/makefiles/HotspotWrapper.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk + common/makefiles/javadoc/CORE_PKGS.gmk + common/makefiles/javadoc/Javadoc.gmk + common/makefiles/javadoc/NON_CORE_PKGS.gmk + common/makefiles/javadoc/Notes.html Changeset: 522dfac8ca4d Author: katleman Date: 2012-09-19 15:44 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/522dfac8ca4d Merge Changeset: 936702480487 Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/936702480487 Added tag jdk8-b57 for changeset 522dfac8ca4d ! .hgtags Changeset: dae9821589cc Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/dae9821589cc Added tag jdk8-b58 for changeset 936702480487 ! .hgtags Changeset: b9d574659206 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/b9d574659206 Added tag jdk8-b59 for changeset dae9821589cc ! .hgtags Changeset: 4b54d77a6831 Author: dholmes Date: 2012-10-09 02:08 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/rev/4b54d77a6831 8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: e07f499b9dcc Author: katleman Date: 2012-10-10 14:47 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/e07f499b9dcc Merge Changeset: 20ff117b5090 Author: katleman Date: 2012-10-11 09:48 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/20ff117b5090 Added tag jdk8-b60 for changeset e07f499b9dcc ! .hgtags Changeset: 8343ccdd63f1 Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/8343ccdd63f1 Added tag jdk8-b61 for changeset 20ff117b5090 ! .hgtags Changeset: c12e759ac4e8 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/c12e759ac4e8 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! README-builds.html + make/scripts/fixpath.pl ! make/scripts/vsvars.sh Changeset: 8a3fe0ae06a8 Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/8a3fe0ae06a8 Merge Changeset: 4e984be114bd Author: katleman Date: 2012-10-25 09:52 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/4e984be114bd Added tag jdk8-b62 for changeset 8a3fe0ae06a8 ! .hgtags Changeset: 4bde5640fb36 Author: alanb Date: 2012-10-09 13:25 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/rev/4bde5640fb36 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile Changeset: ce2b111ee869 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/ce2b111ee869 Merge Changeset: 744e165aaf33 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/744e165aaf33 Merge Changeset: ce212cd7ea69 Author: lana Date: 2012-10-25 20:04 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/ce212cd7ea69 Merge Changeset: e64f2cb57d05 Author: ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author: ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author: katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags Changeset: dd1a80efa7cf Author: anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author: lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/65dca75b2a26 Merge Changeset: e20ffc02e437 Author: erikj Date: 2012-11-03 16:15 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/e20ffc02e437 8002183: Increased max number of paths to list in ListPathsSafely to 16000. Reviewed-by: ohair ! common/makefiles/MakeBase.gmk Changeset: ed9e5635fc80 Author: erikj Date: 2012-11-03 16:28 -0700 URL: http://hg.openjdk.java.net/threeten/threeten/rev/ed9e5635fc80 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/JavaCompilation.gmk Changeset: 1c8370a55b30 Author: katleman Date: 2012-11-07 15:32 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/1c8370a55b30 Merge Changeset: 838a64965131 Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/838a64965131 Added tag jdk8-b64 for changeset 1c8370a55b30 ! .hgtags Changeset: 8bbc72864a41 Author: ohrstrom Date: 2012-11-08 12:24 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/rev/8bbc72864a41 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! common/makefiles/JavaCompilation.gmk Changeset: 78bb27faf889 Author: tbell Date: 2012-11-12 12:34 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/78bb27faf889 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: f2ac4d0edaae Author: tbell Date: 2012-11-13 15:54 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/f2ac4d0edaae 8003274: build-infra: Makefile changes needed for sjavac Summary: changes left in build-infra that are related to sjavac Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeHelpers.gmk Changeset: b772de306dc2 Author: katleman Date: 2012-11-14 12:28 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/b772de306dc2 Merge Changeset: 0e1b5886b06c Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/0e1b5886b06c Added tag jdk8-b65 for changeset b772de306dc2 ! .hgtags Changeset: a2df4ee40ecb Author: tbell Date: 2012-11-14 10:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/a2df4ee40ecb 8002026: build-infra: deploy repository building Summary: Change the compare script to handle deploy build artifacts. Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: c81c4a5d8b50 Author: tbell Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/c81c4a5d8b50 8001875: build-infra: We must be able to force static linking of stdc++ Summary: Ensure that we build with static linking when requested, or do not build at all Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 582c696033f5 Author: tbell Date: 2012-11-14 10:16 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/582c696033f5 8001941: build-infra: --disable-precompiled-headers does not seem to work Summary: With this fix the flag will do what it advertises Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: f59a07f85125 Author: tbell Date: 2012-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/f59a07f85125 8003317: build-infra: Configure fails when current dir is part of a symlink Summary: Call macro for removing symbolic links on a copy of the CURDIR variable before comparing Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: e69396d6d3e8 Author: tbell Date: 2012-11-14 10:20 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/e69396d6d3e8 8003327: build-infra: "/bin/sh: : cannot execute" on solaris Summary: Fix quoting inside cut command used in the pipeline Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/makefiles/MakeHelpers.gmk Changeset: 06f146c05f49 Author: tbell Date: 2012-11-15 00:54 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/rev/06f146c05f49 Merge Changeset: ecf751a69f6a Author: tbell Date: 2012-11-19 14:06 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/ecf751a69f6a 8003300: build-infra: fails on solaris when objcopy is not found Summary: Only call BASIC_FIXUP_EXECUTABLE() if objcopy was found. Reviewed-by: tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: f8b0bacd4de5 Author: erikj Date: 2012-11-28 13:15 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/rev/f8b0bacd4de5 8001460: build-infra: Linker warnings on macosx Summary: Only linking against jvm variant specific dirs if they are expected to exist. Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 6ff2e1280dc3 Author: erikj Date: 2012-11-28 13:40 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/rev/6ff2e1280dc3 8003844: build-infra: docs target isn't working properly Summary: Fixed docs and docs-clean target. Added compare support for docs. Reviewed-by: ohair, jjg, ohrstrom ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7d7dd520ebfd Author: erikj Date: 2012-11-28 13:48 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/rev/7d7dd520ebfd 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Linking against server jvm first if available. Adding filters and exceptions for hotspot lib compare on solaris. Reviewed-by: ohair, ohrstrom ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/bin/compare_exceptions.sh.incl Changeset: 13bb8c326e7b Author: katleman Date: 2012-11-28 14:03 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/13bb8c326e7b Merge Changeset: 16292f54195c Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/rev/16292f54195c Added tag jdk8-b66 for changeset 13bb8c326e7b ! .hgtags From xueming.shen at oracle.com Tue Dec 4 22:35:50 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:35:50 +0000 Subject: [threeten-dev] hg: threeten/threeten/corba: Added tag jdk8-b66 for changeset 65771ad1ca55 Message-ID: <20121205063552.9F1DD47E03@hg.openjdk.java.net> Changeset: 394515ad2a55 Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/corba/rev/394515ad2a55 Added tag jdk8-b66 for changeset 65771ad1ca55 ! .hgtags From xueming.shen at oracle.com Tue Dec 4 22:37:08 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:37:08 +0000 Subject: [threeten-dev] hg: threeten/threeten/hotspot: Added tag jdk8-b66 for changeset 01684f7fee1b Message-ID: <20121205063717.AB52747E06@hg.openjdk.java.net> Changeset: 2f6dc76eb8e5 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2f6dc76eb8e5 Added tag jdk8-b66 for changeset 01684f7fee1b ! .hgtags From xueming.shen at oracle.com Tue Dec 4 22:38:43 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:38:43 +0000 Subject: [threeten-dev] hg: threeten/threeten/jaxp: Added tag jdk8-b66 for changeset e6af1ad464e3 Message-ID: <20121205063849.BFEBC47E09@hg.openjdk.java.net> Changeset: 83df3493ca3c Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/83df3493ca3c Added tag jdk8-b66 for changeset e6af1ad464e3 ! .hgtags From xueming.shen at oracle.com Tue Dec 4 22:39:59 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:39:59 +0000 Subject: [threeten-dev] hg: threeten/threeten/jaxws: Added tag jdk8-b66 for changeset 3eb7f11cb4e0 Message-ID: <20121205064004.85B9B47E0C@hg.openjdk.java.net> Changeset: eb06aa51dfc2 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/eb06aa51dfc2 Added tag jdk8-b66 for changeset 3eb7f11cb4e0 ! .hgtags From xueming.shen at oracle.com Tue Dec 4 22:41:51 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 06:41:51 +0000 Subject: [threeten-dev] hg: threeten/threeten/langtools: Added tag jdk8-b66 for changeset 20230f8b0eef Message-ID: <20121205064159.730FC47E0F@hg.openjdk.java.net> Changeset: 303b09787a69 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/303b09787a69 Added tag jdk8-b66 for changeset 20230f8b0eef ! .hgtags From scolebourne at joda.org Wed Dec 5 02:43:08 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 10:43:08 +0000 Subject: [threeten-dev] Era value In-Reply-To: References: Message-ID: On 5 December 2012 04:54, wrote: > This is purely a question - not pointing out any issues in the spec. > > The Era#getValue() spec says: > > "The era in use at 1970-01-01 must have the value 1...." > > I'm wondering if this requirement is really necessary. In some calendar > systems, there is only one era (well, conceptually, nothing before epoch). > Of course, we could artificially invent post epoch era as era 0. Also, > Japanese/Chinese dynasty eras could be over 100. If we use an era > including 1970-01-01 as era 1, era value could ends up 3 digits negative > value, which just look awkward. > > I was thinking about the reason behind this, but I could not see any > convincing reasons. Can someone explain why this is a requirement? This is simply a way to define values and provide some limitations to implementors. We do define eras for points before the epoch of calendar systems. To match the existing JDK, in Gregorian BC is 0 and AD is 1. Thus it was effective to decare 1 as 1970 with lower numbers for earlier. We could remove this limitation, but I'm not sure I would change the implementation. Stephen From scolebourne at joda.org Wed Dec 5 06:46:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 14:46:38 +0000 Subject: [threeten-dev] Integration with other JDK classes Message-ID: The question is to what degree should existing JDK date/time classes support integration with 310? Key open question to everyone is how much integration should be done? Here is my list and proposls: util.Date - implement DateTimeAccessor (INSTANT_SECONDS and fractional second fields) sql.Date - implement DateTimeAccessor (EPOCH_DAY and related) sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related) sql.Timestamp - implement DateTimeAccessor (all ChronoField) Calendar - implement DateTimeAccessor (all ChronoField) GregorianCalendar - implement DateTimeAccessor (all ChronoField and zone) FileTime should implement DateTimeAccessor xml.XMLGregorianCalendar should implement DateTimeAccessor xml.Duration should implement PlusAdjuster and MinusAdjuster TimeUnit should implement PeriodUnit In addition, some common additional methods would be very helpful: Date.toInstant() util.Date.from(DateTimeAccessor) sql.Date.from(DateTimeAccessor) sql.Time.from(DateTimeAccessor) sql.Timestamp.from(DateTimeAccessor) Calendar.toInstant() Calendar.from(DateTimeAccessor) GregorianCalendar.toZonedDateTime() GregorianCalendar.from(DateTimeAccessor) GregorianCalendar might beneft from toLocalDate() and toLocalTime(). The sql subtypes of util.Date are of course troublesome. The JDBC group need to advise on whether they consider them effectively deprecated or not. DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is exactly 24 hours. I think that is all the JDK date/time classes. I could be wrong... Stephen (This was a private discussion being made public) From misterm at gmail.com Wed Dec 5 06:51:25 2012 From: misterm at gmail.com (Michael Nascimento) Date: Wed, 5 Dec 2012 12:51:25 -0200 Subject: [threeten-dev] Integration with other JDK classes In-Reply-To: References: Message-ID: Seems like a reasonable list of classes and modifications to them. +1. Regards, Michael On Wed, Dec 5, 2012 at 12:46 PM, Stephen Colebourne wrote: > The question is to what degree should existing JDK date/time classes > support integration with 310? > Key open question to everyone is how much integration should be done? > > Here is my list and proposls: > util.Date - implement DateTimeAccessor (INSTANT_SECONDS and fractional > second fields) > sql.Date - implement DateTimeAccessor (EPOCH_DAY and related) > sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related) > sql.Timestamp - implement DateTimeAccessor (all ChronoField) > Calendar - implement DateTimeAccessor (all ChronoField) > GregorianCalendar - implement DateTimeAccessor (all ChronoField and zone) > FileTime should implement DateTimeAccessor > xml.XMLGregorianCalendar should implement DateTimeAccessor > xml.Duration should implement PlusAdjuster and MinusAdjuster > TimeUnit should implement PeriodUnit > > In addition, some common additional methods would be very helpful: > Date.toInstant() > util.Date.from(DateTimeAccessor) > sql.Date.from(DateTimeAccessor) > sql.Time.from(DateTimeAccessor) > sql.Timestamp.from(DateTimeAccessor) > Calendar.toInstant() > Calendar.from(DateTimeAccessor) > GregorianCalendar.toZonedDateTime() > GregorianCalendar.from(DateTimeAccessor) > > GregorianCalendar might beneft from toLocalDate() and toLocalTime(). > > The sql subtypes of util.Date are of course troublesome. The JDBC > group need to advise on whether they consider them effectively > deprecated or not. > > DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is > exactly 24 hours. > > I think that is all the JDK date/time classes. I could be wrong... > > Stephen > (This was a private discussion being made public) From scolebourne at joda.org Wed Dec 5 07:15:59 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 15:15:59 +0000 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: <50BEE601.7080200@oracle.com> References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> Message-ID: On 5 December 2012 06:13, Xueming Shen wrote: > Date <-> Instant appears to be a must, in which it provides the > connection/conversion > at the bottom between two different systems, so we don't need Date <-> ODT > for > example. > > How to support the Date <-> Instant? > > I believe we only need ONE straightforward/direct conversion, don't need to > provide > multiple convenient vehicles here, developer should just use this entry > point to convert > between these two types. As you suggested, use nio.file as an example, a > simple pair > of File.toPath() and Path.toFile() should be good enough. > > Date.toInstant() and "util.Date must support the same fields as Instant - > INSTANT_SECONDS and the three fractional seconds fields" are obviously > redundant. > With this, now you can do > > Date date = ...; > Instant instant = date.toInstant(); > or > Instant instant = Instant.from(date); > > If we don't need two, which one is better? DateTimeAccessor appears to be > convenient, with this, you can also do OffsetDateTime.from(date), and any > "extended" > date/time that knows INSTANT_SECONDS+fractional sec fields can work with > u.Date > as well. But it also brings us the biggest problem, all of the sudden, > j.u.Date can fly > freely inside the new JSR310 system. Conveniently, our datetime formatter > also magically > work with j.u.Date. Is this something you want to see? It appears to be an > integration > of two systems, not a bridge. Sure, it provides convenience, but it also has > the > consequence, you now have a mutable DateTimeAccessor running around your > JSR310 > code. DateTimeAccessor has always been known to be possibly mutable. Its an interface, so nothing there can really be controlled. Having a java.util.Date (or Calendar) work with the new immutable formatter seems like a good thing - easy for developers to fix thread-unsafe static formatters in their current code. Integration is essentially what the system has been designed for. Previous designs did it in different ways, but they all were planned such that the old classes would implement the new interface, allowing general use. > So personally I think a simple Date.toInstant() is the best choice, it > provide a "single" > entry point for all those "old" date/time. The code that uses JSR310 > date/time should > just work with new date/time, old date/time need to be converted into new > types to > get in. > > A Instant.toDate() will be a little confusing, I would suggest just do > Date.fromInstant(). Clearly, this satisfies the basic problem, but its not what was intended in the design (which was DateTimeAccessor). There are actually four sensible options: A) toInstant() and from(Instant), j.u.Date not implement DateTimeAccessor B) toInstant() and from(DateTimeAccessor), j.u.Date not implement DateTimeAccessor C) from(DateTimeAccessor), j.u.Date implements DateTimeAccessor D) toInstant() and from(DateTimeAccessor), j.u.Date implements DateTimeAccessor I'd always intended (D), as it best matches the rest fo 310. Note that (B), (C), (D) allow j.u.Date.from(zoneDateTime) or from(offsetDateTime), which (A) does not, and these seem like useful conversions. OffsetDateTime.from(j.u.Date) will not work in any option, as there is no offset. > In theory, it's doable to bridge the conversion of GregorianCalendar and ZDT > by > > GregorianCalendar <-> Date <-> Instant <-> ZDT, > > but obviously the "zone" is missing, it's probably not desirable to use > "default". So, it > appears GregorianCalendar <-> ZDT is another candidate. For same reason I > mentioned > above, I don't think you want to "integrate" GregorianCalendar into the new > system, stop > it by forcing it to be the immutable ZDT before any new code can touch it. > Otherwise, > the worse thing is that, not like j.u.Date, those "setting" methods of > GregorianCalendar > are not deprecated. Again, this works but isn't ideal. My aim was to provide an easy migration, not a hard one. Stephen From scolebourne at joda.org Wed Dec 5 07:17:47 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 15:17:47 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: Message-ID: On 5 December 2012 15:14, Nikolay Metchev wrote: > On a related note should the java.text.DateFormat class and subclasses be > modified as well? If not should it be marked as deprecated? There is no need to alter DateFormat that I can see. Developers should use the new formatter. The question is (partly) whether the new formatter should accept the old Date/Calendar classes. Stephen From scolebourne at joda.org Wed Dec 5 07:24:30 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 15:24:30 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: On 5 December 2012 15:02, Lance Andersen - Oracle wrote: >> The sql subtypes of util.Date are of course troublesome. The JDBC >> group need to advise on whether they consider them effectively >> deprecated or not. > > -1 > > No we cannot deprecate these at this time, too much existing code out there and people will not want the noise from the javadoc or annotation. These classes have been used since JDBC 1.0 and the better approach is to document > the preferred way going forward My question was really whether the JDBC group care about enhancing the sql classes, or whether they are content to let them be and get everyone to move to the new types. In other words, if someone is going into their code and updating it to use 310 classes on the Java side (everywhere), do you also want them to change the JDBC logic (and thus remove references to sql.Date etc) or to be able to use 310 classes in the rest of their codebase, but the old sql JDBC classes withing the JDBC code. Stephen From Lance.Andersen at oracle.com Wed Dec 5 07:02:56 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Dec 2012 10:02:56 -0500 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: Message-ID: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> On Dec 5, 2012, at 9:46 AM, Stephen Colebourne wrote: > The question is to what degree should existing JDK date/time classes > support integration with 310? > Key open question to everyone is how much integration should be done? > > Here is my list and proposls: > util.Date - implement DateTimeAccessor (INSTANT_SECONDS and fractional > second fields) > sql.Date - implement DateTimeAccessor (EPOCH_DAY and related) > sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related) > sql.Timestamp - implement DateTimeAccessor (all ChronoField) I have not looked at this interface enough to see the amount of work this would require. This would also require new JCK tests which I had not planned for. > Calendar - implement DateTimeAccessor (all ChronoField) > GregorianCalendar - implement DateTimeAccessor (all ChronoField and zone) > FileTime should implement DateTimeAccessor > xml.XMLGregorianCalendar should implement DateTimeAccessor > xml.Duration should implement PlusAdjuster and MinusAdjuster > TimeUnit should implement PeriodUnit > > In addition, some common additional methods would be very helpful: > Date.toInstant() > util.Date.from(DateTimeAccessor) > sql.Date.from(DateTimeAccessor) > sql.Time.from(DateTimeAccessor) > sql.Timestamp.from(DateTimeAccessor) Same comment as above. I will talk with Roger and Sherman to see if they have cycles and then I can propose to the JDBC EG > Calendar.toInstant() > Calendar.from(DateTimeAccessor) > GregorianCalendar.toZonedDateTime() > GregorianCalendar.from(DateTimeAccessor) > > GregorianCalendar might beneft from toLocalDate() and toLocalTime(). > > The sql subtypes of util.Date are of course troublesome. The JDBC > group need to advise on whether they consider them effectively > deprecated or not. -1 No we cannot deprecate these at this time, too much existing code out there and people will not want the noise from the javadoc or annotation. These classes have been used since JDBC 1.0 and the better approach is to document the preferred way going forward > > DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is > exactly 24 hours. > > I think that is all the JDK date/time classes. I could be wrong... > > Stephen > (This was a private discussion being made public) > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From nikolaymetchev at gmail.com Wed Dec 5 07:14:40 2012 From: nikolaymetchev at gmail.com (Nikolay Metchev) Date: Wed, 5 Dec 2012 15:14:40 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: Message-ID: On a related note should the java.text.DateFormat class and subclasses be modified as well? If not should it be marked as deprecated? On 5 December 2012 14:46, Stephen Colebourne wrote: > The question is to what degree should existing JDK date/time classes > support integration with 310? > Key open question to everyone is how much integration should be done? > > Here is my list and proposls: > util.Date - implement DateTimeAccessor (INSTANT_SECONDS and fractional > second fields) > sql.Date - implement DateTimeAccessor (EPOCH_DAY and related) > sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related) > sql.Timestamp - implement DateTimeAccessor (all ChronoField) > Calendar - implement DateTimeAccessor (all ChronoField) > GregorianCalendar - implement DateTimeAccessor (all ChronoField and zone) > FileTime should implement DateTimeAccessor > xml.XMLGregorianCalendar should implement DateTimeAccessor > xml.Duration should implement PlusAdjuster and MinusAdjuster > TimeUnit should implement PeriodUnit > > In addition, some common additional methods would be very helpful: > Date.toInstant() > util.Date.from(DateTimeAccessor) > sql.Date.from(DateTimeAccessor) > sql.Time.from(DateTimeAccessor) > sql.Timestamp.from(DateTimeAccessor) > Calendar.toInstant() > Calendar.from(DateTimeAccessor) > GregorianCalendar.toZonedDateTime() > GregorianCalendar.from(DateTimeAccessor) > > GregorianCalendar might beneft from toLocalDate() and toLocalTime(). > > The sql subtypes of util.Date are of course troublesome. The JDBC > group need to advise on whether they consider them effectively > deprecated or not. > > DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is > exactly 24 hours. > > I think that is all the JDK date/time classes. I could be wrong... > > Stephen > (This was a private discussion being made public) > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > From Lance.Andersen at oracle.com Wed Dec 5 07:33:33 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Dec 2012 10:33:33 -0500 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: On Dec 5, 2012, at 10:24 AM, Stephen Colebourne wrote: > On 5 December 2012 15:02, Lance Andersen - Oracle > wrote: >>> The sql subtypes of util.Date are of course troublesome. The JDBC >>> group need to advise on whether they consider them effectively >>> deprecated or not. >> >> -1 >> >> No we cannot deprecate these at this time, too much existing code out there and people will not want the noise from the javadoc or annotation. These classes have been used since JDBC 1.0 and the better approach is to document >> the preferred way going forward > > My question was really whether the JDBC group care about enhancing the > sql classes, or whether they are content to let them be and get > everyone to move to the new types. I would rather let them be and just use the 310 classes if they desire. As we discussed before we will add support for specific 310 types via set/getObject which is how we would envision people taking advantage of new data types including 310. So as developers are ready to move they will, I just do not see a big advantage in adding new features to the old classes as they have enough baggage as it is. Best Lance > > In other words, if someone is going into their code and updating it to > use 310 classes on the Java side (everywhere), do you also want them > to change the JDBC logic (and thus remove references to sql.Date etc) > or to be able to use 310 classes in the rest of their codebase, but > the old sql JDBC classes withing the JDBC code. > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Wed Dec 5 08:07:30 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 05 Dec 2012 08:07:30 -0800 Subject: [threeten-dev] Fwd: Re: j.u.Date/Calendrical/GregorianCalendar In-Reply-To: <50BEE601.7080200@oracle.com> References: <50BEE601.7080200@oracle.com> Message-ID: <50BF7142.4060000@oracle.com> Forwarded to threeten-develop at lists.sourceforge.net -------- Original Message -------- Message-ID: <50BEE601.7080200 at oracle.com> Date: Tue, 04 Dec 2012 22:13:21 -0800 From: Xueming Shen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Colebourne CC: Roger Riggs , threeten-dev at openjdk.java.net Subject: Re: j.u.Date/Calendrical/GregorianCalendar References: <50BE312C.9030708 at oracle.com> <50BE532F.9040903 at oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agree this should be discussed in public mailing list. My fault, I thought I was asking a simple/solved question:-) My take on this is that we should provide a bridge between these two systems, but not integrate these two together (in which you try to provide convenient conversion between all those different date/time types, or even go a little further to make it possible to access all corresponding threeten fields from a GregorianCalendar). Date <-> Instant appears to be a must, in which it provides the connection/conversion at the bottom between two different systems, so we don't need Date <-> ODT for example. How to support the Date <-> Instant? I believe we only need ONE straightforward/direct conversion, don't need to provide multiple convenient vehicles here, developer should just use this entry point to convert between these two types. As you suggested, use nio.file as an example, a simple pair of File.toPath() and Path.toFile() should be good enough. Date.toInstant() and "util.Date must support the same fields as Instant - INSTANT_SECONDS and the three fractional seconds fields" are obviously redundant. With this, now you can do Date date = ...; Instant instant = date.toInstant(); or Instant instant = Instant.from(date); If we don't need two, which one is better? DateTimeAccessor appears to be convenient, with this, you can also do OffsetDateTime.from(date), and any "extended" date/time that knows INSTANT_SECONDS+fractional sec fields can work with u.Date as well. But it also brings us the biggest problem, all of the sudden, j.u.Date can fly freely inside the new JSR310 system. Conveniently, our datetime formatter also magically work with j.u.Date. Is this something you want to see? It appears to be an integration of two systems, not a bridge. Sure, it provides convenience, but it also has the consequence, you now have a mutable DateTimeAccessor running around your JSR310 code. So personally I think a simple Date.toInstant() is the best choice, it provide a "single" entry point for all those "old" date/time. The code that uses JSR310 date/time should just work with new date/time, old date/time need to be converted into new types to get in. A Instant.toDate() will be a little confusing, I would suggest just do Date.fromInstant(). So my vote will be Date.to/fromInstant(). In theory, it's doable to bridge the conversion of GregorianCalendar and ZDT by GregorianCalendar <-> Date <-> Instant <-> ZDT, but obviously the "zone" is missing, it's probably not desirable to use "default". So, it appears GregorianCalendar <-> ZDT is another candidate. For same reason I mentioned above, I don't think you want to "integrate" GregorianCalendar into the new system, stop it by forcing it to be the immutable ZDT before any new code can touch it. Otherwise, the worse thing is that, not like j.u.Date, those "setting" methods of GregorianCalendar are not deprecated. Should we do the Calendar <-> Instant, personally I don't think we want to do it. There is a direct conversion between Date <-> Calendar via setTime/getTimeInMillis, so I don't think developer will whine too much on missing a "convenient" direct conversion between these two. But I will probably not be too strong to against the idea of having to/fromInstant() pair on it, especially the toInstant(), given Calendar/GregrianCalendar is one of the most frequently used date/time types in current system. -Sherman On 12/4/12 2:56 PM, Stephen Colebourne wrote: > This should really be public... > > On 4 December 2012 19:46, Roger Riggs wrote: >> I'd like to see the simplest practical coupling. >> >> I'd rather developers get used to use the 310 types.from() methods to convert. > The closest JDK parallel is the addition of the new file system API. > The old one - File - has a method toPath(). The same principle applies > here. Not having toInstant() is just being mean to developers. > >> In my opinion, the classes should implement DateTimeAccessor. They >> should also have some additional methods: >> Date.toInstant() >> Date.from(DateTimeAccessor) >> Calendar.toInstant() >> Calendar.from(DateTimeAccessor) >> GregorianCalendar.toZonedDateTime() >> GregorianCalendar.from(DateTimeAccessor) >> >> What fields are required to say it supports DateTimeAccessor? > util.Date must support the same fields as Instant - INSTANT_SECONDS > and the three fractional seconds fields. > Calendar is the same. > GregorianCalendar should support the full range of additional fields. > > Supporting only ZoneId, which would be enough for conversion to ZDT, > is possible with a future JDK adding the remaining fields. However, > this would be a violation of the spirit of DateTimeAccessor though, > and I suspect users would complain. > >> GregorianCalendar might benefit from toLocalDate() and toLocalTime(). >> >> Special handling will be needed for the sql subtypes of util.Date - >> sql.Date, sql.Time and sql.Timestamp. >> >> If JDBC is going to encourage using the new 310 types then >> these do not need to be enhanced. > If util.Date implements DateTimeAccessor then these three classes > *have* to be dealt with too. They will inherit the implementation from > util.Date, which is entirely wrong for the three subclasses. > > sql.Date should act like a LocalDate, sql.Time like a LocalTime > (confirm with Douglas). Neither should return INSTANT_SECONDS. > > >> xml.XMLGregorianCalendar should implement DateTimeAccessor >> >> xml.Duration should implement PlusAdjuster and MinusAdjuster >> >> I'd leave these out, it encourages mixing APIs; not just interoperation >> >> TimeUnit should implement PeriodUnit >> (DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is >> exactly 24 hours) >> >> Keep the cross coupling of the APIs to what is really needed, >> mixing the APIs will make developers dizzy. >> >> FileTime should implement DateTimeAccessor >> (amusingly, the toString method follows the broken XML Schema text >> which wrongly has the year before 0001 as -0001). >> >> We'll need to consult with the other API owners about the couplings. > Ultimately these APIs are outside 310/my control. It is my opinion > that the above should be implemented, and if they are not developers > will have a harder job than they should. In addition, some conversions > (like FileTime) may be tricky (due to the missing year zero) so these > implementations will actually reduce bugs. > > I do know that the developers of FileTime considered using 310 but the > schedules obviously didn't match up. > > Stephen From roger.riggs at oracle.com Wed Dec 5 08:08:03 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 05 Dec 2012 16:08:03 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 41 new changesets Message-ID: <20121205161624.0366A47E3B@hg.openjdk.java.net> Changeset: 947934b09ab0 Author: rriggs Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/947934b09ab0 ThreeTen: 6c12c56f80e2702fb6b9da468d0ab6fc25a1f1c8 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 09:41:07 +0000 Subject: Rename dateFromYearDay() to dateYearDay() ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/Era.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/chrono/ISOEra.java ! src/share/classes/javax/time/chrono/global/HijrahChrono.java ! src/share/classes/javax/time/chrono/global/HijrahEra.java ! src/share/classes/javax/time/chrono/global/JapaneseChrono.java ! src/share/classes/javax/time/chrono/global/MinguoChrono.java ! src/share/classes/javax/time/chrono/global/MinguoEra.java ! src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java ! src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceEra.java Changeset: 384f607a4489 Author: rriggs Date: 2012-11-29 10:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/384f607a4489 ThreeTen: d0a92418b7ed812cd2527e461fdd33a919ba8ec9 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 10:24:45 +0000 Subject: Javadoc and suppress warnings ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/Era.java Changeset: 57740f7e7840 Author: rriggs Date: 2012-11-29 11:44 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/57740f7e7840 ThreeTen: 41a158fb248137c9fce9581763b6676bc39132a8 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 11:44:59 +0000 Subject: Better error message ! src/share/classes/javax/time/ZonedDateTime.java Changeset: c721ca4c8793 Author: rriggs Date: 2012-11-29 11:59 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c721ca4c8793 ThreeTen: 39234eb377a8f96cedacc1f46288d09a7ce1871f Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 11:59:08 +0000 Subject: Override all date factory methods on ISOChrono ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ISOChrono.java Changeset: c126a2c2ccab Author: rriggs Date: 2012-11-29 12:40 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c126a2c2ccab ThreeTen: e7f7e344bd599353bf1d811fbf307ab20a505113 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 12:40:03 +0000 Subject: Rename TZDB to Tzdb to match common coding standards - src/share/classes/javax/time/zone/TZDBZoneRulesCompiler.java + src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! src/share/classes/javax/time/zone/TzdbZoneRulesProvider.java + test/javax/time/tck/javax/time/zone/TestTzdbZoneRulesCompiler.java Changeset: 1dfe16fbe22d Author: rriggs Date: 2012-11-29 14:30 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1dfe16fbe22d ThreeTen: 9f1d42639be68460dc9cc3b1454fc243f3087404 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 14:30:33 +0000 Subject: Simplify query mechanism and add TIME_PRECISION query ! make/netbeans/threeten/build.xml ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/calendrical/DateTimeBuilder.java ! src/share/classes/javax/time/chrono/ISOEra.java ! src/share/classes/javax/time/chrono/global/HijrahEra.java ! src/share/classes/javax/time/chrono/global/MinguoEra.java ! src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDate.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDateTime.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoOffsetDateTime.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceDateTimeAccessor.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceEra.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/test/javax/time/TestInstant.java Changeset: d57fbfd561dc Author: rriggs Date: 2012-11-29 14:38 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d57fbfd561dc ThreeTen: b04d80943bc86e578e29e4385f42fc1eb5fd5123 Orig-User: Stephen Colebourne Orig-Date: Thu, 29 Nov 2012 14:38:46 +0000 Subject: Update Javadoc from fractional formatter change ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/ZonedDateTime.java Changeset: 0186b264b089 Author: rriggs Date: 2012-11-30 21:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0186b264b089 ThreeTen: b161f07fbc4d836cd2ff51a48719b2925f57535b Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 21:21:20 +0000 Subject: Javadoc ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/ZonedDateTime.java Changeset: 59739afcf2c1 Author: rriggs Date: 2012-11-30 21:23 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/59739afcf2c1 ThreeTen: 35c6d32b1f18cd87b0d2fc43c6f291fad05f0544 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 21:23:41 +0000 Subject: ZonedDateTime epoch second factory takes nano-of-second ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: a38ea8a660dd Author: rriggs Date: 2012-11-30 21:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a38ea8a660dd ThreeTen: 704c0cf94bfab393c8ef4655816cada9027cc1c3 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 21:42:41 +0000 Subject: Add now(ZoneId) ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/test/javax/time/TestOffsetDate.java Changeset: 20d10ff74eac Author: rriggs Date: 2012-11-30 21:54 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/20d10ff74eac ThreeTen: c79c53b8453a571fdab19b711b74e665afb3df02 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 21:54:22 +0000 Subject: Re-order methods ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetTime.java Changeset: 69df804495f9 Author: rriggs Date: 2012-11-30 22:00 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/69df804495f9 ThreeTen: b70444a01d201dc34055a1f305d4e2ac28382d22 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 22:00:58 +0000 Subject: Add OffsetDate.ofInstant() ! src/share/classes/javax/time/OffsetDate.java Changeset: 00c3610c667e Author: rriggs Date: 2012-11-30 22:06 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/00c3610c667e ThreeTen: c330c0733a3ebc680cbfeda575374cbffefc5f6b Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 22:06:00 +0000 Subject: Add atDate() ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetTime.java Changeset: 3bf0f44a1600 Author: rriggs Date: 2012-11-30 22:26 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3bf0f44a1600 ThreeTen: aa8cea8e0d8a4816b4de79320e990dae312a3314 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 22:26:51 +0000 Subject: Enhance OffsetDate/OffsetTime tests ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java - test/javax/time/test/javax/time/TestOffsetDate.java - test/javax/time/test/javax/time/TestOffsetTime.java Changeset: f29ea2492a62 Author: rriggs Date: 2012-11-30 23:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f29ea2492a62 ThreeTen: 26f14d3e301948ee659acf90af15d66fe6b1ec22 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 23:42:24 +0000 Subject: Remove OffsetDateTime.withDate() and withTime() ! src/share/classes/javax/time/OffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/test/javax/time/TestOffsetDateTime.java Changeset: 833a34bb7d0b Author: rriggs Date: 2012-11-30 23:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/833a34bb7d0b ThreeTen: d2faeca24440df7829a79b39edefd98f88e3b187 Orig-User: Stephen Colebourne Orig-Date: Fri, 30 Nov 2012 23:42:50 +0000 Subject: Remove OffsetDate.atTime(OffsetTime) and (ints) ! src/share/classes/javax/time/OffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java Changeset: 701d619de03f Author: rriggs Date: 2012-12-01 00:01 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/701d619de03f ThreeTen: 330835c4fae60fcf8b9510e5ed3e4997fc4a7a83 Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 00:01:39 +0000 Subject: Tidy OffsetDateTime Javadoc and implementation ! src/share/classes/javax/time/OffsetDateTime.java Changeset: fc3ced1205b8 Author: rriggs Date: 2012-12-01 00:02 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fc3ced1205b8 ThreeTen: 06574a43ac415d564b9775b6b63c21eee563e717 Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 00:02:43 +0000 Subject: Remove OffsetDateTime.resolve(ZoneId) ! src/share/classes/javax/time/OffsetDateTime.java Changeset: 263f3692163b Author: rriggs Date: 2012-12-01 00:19 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/263f3692163b ThreeTen: 342f782f70d03d9e3fabe8c7ab0f61d0c7ea1d06 Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 00:19:11 +0000 Subject: Better set of OffsetDateTime factories ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/test/javax/time/TestOffsetDateTime_instants.java Changeset: aab421076285 Author: rriggs Date: 2012-12-01 01:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/aab421076285 ThreeTen: 2e8005369ff015059aee1fc3927a7ce39ecfbffb Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 01:12:53 +0000 Subject: Tidy local variable name ! src/share/classes/javax/time/ZonedDateTime.java Changeset: 1773ce20774f Author: rriggs Date: 2012-12-01 01:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1773ce20774f ThreeTen: 219c15d28ab569d25fdcf9d71d76a75deae1af27 Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 01:39:34 +0000 Subject: Refactor ZoneId, ZoneOffset, ZonedDateTime, OffsetDateTime et al ! make/netbeans/threeten/build.xml ! make/netbeans/threeten/nbproject/project.xml ! src/share/classes/javax/time/Clock.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Ser.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java + src/share/classes/javax/time/ZoneRegion.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendrical/ChronoUnit.java ! src/share/classes/javax/time/calendrical/DateTimeBuilder.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java - src/share/classes/javax/time/chrono/ChronoOffsetDateTime.java - src/share/classes/javax/time/chrono/ChronoOffsetDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/chrono/Ser.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoOffsetDateTime.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java - src/share/classes/javax/time/zone/ZoneResolver.java - src/share/classes/javax/time/zone/ZoneResolvers.java ! src/share/classes/javax/time/zone/ZoneRules.java ! test/javax/time/resources/MonthDay.bin ! test/javax/time/resources/OffsetDate.bin ! test/javax/time/resources/OffsetDateTime.bin ! test/javax/time/resources/OffsetTime.bin ! test/javax/time/resources/Year.bin ! test/javax/time/resources/YearMonth.bin ! test/javax/time/resources/ZoneId.bin ! test/javax/time/resources/ZoneOffset.bin ! test/javax/time/resources/ZonedDateTime.bin ! test/javax/time/tck/javax/time/TCKClock_System.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java ! test/javax/time/tck/javax/time/calendrical/TCKYear.java ! test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java - test/javax/time/tck/javax/time/chrono/TestChronoOffsetDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/zone/TCKFixedZoneRules.java ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java ! test/javax/time/tck/javax/time/zone/TCKZoneRulesProvider.java ! test/javax/time/test/javax/time/TestClock_Fixed.java ! test/javax/time/test/javax/time/TestClock_Offset.java ! test/javax/time/test/javax/time/TestClock_Tick.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/TestZoneOffset.java - test/javax/time/test/javax/time/TestZonedDateTime.java - test/javax/time/test/javax/time/calendrical/MockZoneResolverReturnsNull.java ! test/javax/time/test/javax/time/calendrical/TestChronoUnit.java - test/javax/time/test/javax/time/calendrical/TestDateTimeBuilder.java ! test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java ! test/javax/time/test/javax/time/zone/TestFixedZoneRules.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java - test/javax/time/test/javax/time/zone/TestZoneResolvers.java Changeset: cb68dbc7cddd Author: rriggs Date: 2012-12-01 22:46 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cb68dbc7cddd ThreeTen: a23af01be513caa38f9c058b20719939c576bc19 Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 22:46:19 +0000 Subject: Enhance and fix formatting ! src/share/classes/javax/time/format/DateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java Changeset: b423f1b0e280 Author: rriggs Date: 2012-12-01 23:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b423f1b0e280 ThreeTen: f8dbf781c8584b40262db66330f0ac79feb362ad Orig-User: Stephen Colebourne Orig-Date: Sat, 1 Dec 2012 23:32:54 +0000 Subject: Reorder method signature for formatter appendOffset() ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java Changeset: 54d58557a40d Author: rriggs Date: 2012-12-04 15:46 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/54d58557a40d Fix tests for Reorder method signature for formatter appendOffset() ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java Changeset: 8a17c05f3427 Author: rriggs Date: 2012-12-02 00:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8a17c05f3427 ThreeTen: 29e9e66f9e1eea7ba75d19177fae5eb9ed745bf5 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 00:14:51 +0000 Subject: Add appendZoneRegionId() to formatter ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java Changeset: 308bcaba5ec9 Author: rriggs Date: 2012-12-02 00:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/308bcaba5ec9 ThreeTen: 99435f1e9194ce342389fc46105afc36b590f765 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 00:21:51 +0000 Subject: Javadoc ! src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java Changeset: 49259d4af290 Author: rriggs Date: 2012-12-02 00:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/49259d4af290 ThreeTen: 89390eae1f41f22e217c143d742d2240a3eda756 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 00:41:04 +0000 Subject: Undo DateTimeException extends IllegalArgumentException ! src/share/classes/javax/time/DateTimeException.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java Changeset: 0a92f76ca7db Author: rriggs Date: 2012-12-02 10:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0a92f76ca7db ThreeTen: 5a7841573d6635f1e270b751e2a02fba4cc8727a Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 10:21:36 +0000 Subject: Clarify ZoneId IDs ! src/share/classes/javax/time/ZoneId.java Changeset: 60d8f7e48ac6 Author: rriggs Date: 2012-12-02 21:11 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/60d8f7e48ac6 ThreeTen: 33479dae9ec62edc08bb7683f8fa003e7b58e183 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 21:11:03 +0000 Subject: Reimplement ZoneRulesProvider ! make/tools/tzcompiler/Makefile ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneRegion.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/zone/TzdbZoneRulesProvider.java + src/share/classes/javax/time/zone/ZoneRulesException.java ! src/share/classes/javax/time/zone/ZoneRulesProvider.java ! test/javax/time/tck/javax/time/zone/TCKZoneRulesProvider.java ! test/javax/time/test/javax/time/TestZoneId.java Changeset: 2a723fc8e779 Author: rriggs Date: 2012-12-02 21:26 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2a723fc8e779 ThreeTen: 0491d49458dbb019245407aa4a95ca916f90e3f4 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 21:26:56 +0000 Subject: Better lenient parsing for fraction ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java Changeset: 8b1b79f8f530 Author: rriggs Date: 2012-12-02 23:29 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8b1b79f8f530 ThreeTen: 3186fc0253912315d10e1010762b3fccd959bb3c Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 23:29:27 +0000 Subject: Javadoc ! src/share/classes/javax/time/Duration.java Changeset: 090803b3c2fc Author: rriggs Date: 2012-12-02 23:30 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/090803b3c2fc ThreeTen: 4c976090ac87536df9157e6ff29028ebec5dfbf6 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 23:30:12 +0000 Subject: ZonedDateTime.plus/minus time units based on instant time-line ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: b194e5d9b772 Author: rriggs Date: 2012-12-02 23:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b194e5d9b772 ThreeTen: a6e5e05157991367473c163267a520c16c691dc4 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 23:32:45 +0000 Subject: Remove plusDuration/minusDuration as no longer necessary ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: e122ae99736a Author: rriggs Date: 2012-12-02 23:50 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e122ae99736a ThreeTen: 71462fda681852f932e33205016352ed0d122508 Orig-User: Stephen Colebourne Orig-Date: Sun, 2 Dec 2012 23:50:23 +0000 Subject: Rename withLockedOffset() to withFixedOffsetZone() ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: ba739a86c4c5 Author: rriggs Date: 2012-12-03 00:04 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ba739a86c4c5 ThreeTen: f86b6532286454f10d803b0963e068f8645921f9 Orig-User: Stephen Colebourne Orig-Date: Mon, 3 Dec 2012 00:04:47 +0000 Subject: Remove withDate(), keep withTime() ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/test/javax/time/TestLocalDateTime.java Changeset: c9111140c445 Author: rriggs Date: 2012-12-03 00:08 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9111140c445 ThreeTen: 5c63be412308aab7005c041b30dba0c493bec91f Orig-User: Stephen Colebourne Orig-Date: Mon, 3 Dec 2012 00:08:33 +0000 Subject: Javadoc ! src/share/classes/javax/time/Clock.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/calendrical/DateTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/calendrical/package.html ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/global/package.html ! src/share/classes/javax/time/zone/ZoneRules.java ! src/share/classes/javax/time/zone/ZoneRulesProvider.java Changeset: f667cdf5a00b Author: rriggs Date: 2012-12-04 00:00 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f667cdf5a00b ThreeTen: f2d453bd8e21837dc8c002801ca1a1ce52f68b37 Orig-User: Stephen Colebourne Orig-Date: Tue, 4 Dec 2012 00:00:04 +0000 Subject: Javadoc tweaks ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java Changeset: f776b0f78c5a Author: rriggs Date: 2012-12-04 00:52 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f776b0f78c5a ThreeTen: 28da1e02dfbfc8334c672960f372007f2fdbbbbf Orig-User: Stephen Colebourne Orig-Date: Tue, 4 Dec 2012 00:52:02 +0000 Subject: Add Query for ZoneOffset ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: 633a28877758 Author: rriggs Date: 2012-12-04 01:13 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/633a28877758 ThreeTen: 84024a8c782ba4b53da4556ab779f60353b9b448 Orig-User: Stephen Colebourne Orig-Date: Tue, 4 Dec 2012 01:13:14 +0000 Subject: Remove DateTimeConstants ! src/share/classes/javax/time/Clock.java - src/share/classes/javax/time/DateTimeConstants.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/calendrical/ChronoField.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/global/JapaneseChrono.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDateTime.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java ! src/share/classes/javax/time/zone/StandardZoneRules.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java Changeset: 4cc0f3c099e0 Author: rriggs Date: 2012-12-04 01:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4cc0f3c099e0 ThreeTen: 280f25a00d96df7943b89265ece46e593b823926 Orig-User: Stephen Colebourne Orig-Date: Tue, 4 Dec 2012 01:41:33 +0000 Subject: Remove week-of-month and week-of-year ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/calendrical/ChronoField.java ! src/share/classes/javax/time/chrono/global/ChronoDateImpl.java ! src/share/classes/javax/time/chrono/global/JapaneseChrono.java ! src/share/classes/javax/time/chrono/global/JapaneseDate.java ! src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestOffsetDateTime.java Changeset: 219e52c457a4 Author: rriggs Date: 2012-12-05 11:06 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/219e52c457a4 Merge - src/share/classes/javax/time/zone/ZoneOffsetInfo.java From scolebourne at joda.org Wed Dec 5 08:25:30 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 16:25:30 +0000 Subject: [threeten-dev] javax.time.format.DateTimeFormattter#toFormat(Class parseType) API specification In-Reply-To: References: Message-ID: On 5 December 2012 04:02, wrote: > I have some comments and questions about public Format > DateTimeFormatter#toFormat(Class parseType) API specification [ > http://threeten.sourceforge.net/apidocs-2012-10-25/javax/time/format/DateTimeFormatter.html#toFormat%28java.lang.Class%29 > ]. > > The specification says: > > "Returns this formatter as a java.text.Format instance that will parse to > the specified type." > > I think the implementation is likely supporting only some known object > types and the method would throw IllegalArgumentException or something if > the given parseType is not supported. I think the spec should clarify what > kind of argument is likely supported here and type of exception (or > returning null?) when unsupported type is specified. It takes a class that can be resolved to a date, generally a subclass of DateTimeAccessor. > Also, it says: > > "The format will throw IndexOutOfBoundsException in line with those thrown > by the print and parse methods." > > This description does not sound right. My understanding is "The format" is > an instance of java.text.Format subclass. Format defines two parse methods > - 1) Object parseObject(String) and 2) abstract Object parseObject(String, > ParsePosition) - I do not know what "print" method in the spec actually > means (Format defines "format" methods, not "print"). In addition to > these, it's difficult to understand why IndexOutOfBoundsException might be > thrown by "The format". By the contract of java.textFormat, format method > should not throw any exception and parseObject should throw > java.text.ParseException on parse failure. So I have no idea where this > IndexOutOfBoundsException come from. The contract of Format is incomplete. Passing a ParsePosition with a negative number to a SimpleDateFormat will throw a StringIndexOOBException. DateTimeFormatter is allowed to thow IOOBException from parseToBuilder. I'm making various updates to try and clarify the behavior. thanks Stephen From scolebourne at joda.org Wed Dec 5 08:28:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 16:28:38 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: On 5 December 2012 15:33, Lance Andersen - Oracle wrote: >> My question was really whether the JDBC group care about enhancing the >> sql classes, or whether they are content to let them be and get >> everyone to move to the new types. > > I would rather let them be and just use the 310 classes if they desire. > > As we discussed before we will add support for specific 310 types via set/getObject which is how we would envision people taking advantage of new data types including 310. > > So as developers are ready to move they will, I just do not see a big advantage in adding new features to the old classes as they have enough baggage as it is. I'm happy to not upgrade the sql classes. However it should be noted that any methods, such as toInstant() or from(...) will be inherited by the sql classes, providing another oddity for developers. Stephen From scolebourne at joda.org Wed Dec 5 08:31:03 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 16:31:03 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: <50BF6D13.7050707@christopherschultz.net> References: <50BF6D13.7050707@christopherschultz.net> Message-ID: On 5 December 2012 15:49, Christopher Schultz wrote: > It seems to me that the 310 API should be the new standard that > java.util.Calendar never was: java.util.Calendar didn't really work with > any existing classes (e.g. java.text.SimpleDateFormat) and so most code > I see uses Calendar as much as possible but then has to fall-back to > java.util.Date. If components like java.text.SimpleDateFormat, > java.sql.PreparedStatement, etc. can support the new classes from 310, > no changes will need to be made to java.util.Date and java.util.Calendar > and they can be fully deprecated. The 310 classes will work directly with JDBC, and they will have their own new formatter. Date/Calendar aren't going to be deprecated, so its a case of how much interoperation to provide. The intention has been to not provide any reference to the "old" classes from the "new" 310 ones (in the public API). Stephen From Lance.Andersen at oracle.com Wed Dec 5 08:35:16 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Dec 2012 11:35:16 -0500 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: On Dec 5, 2012, at 11:28 AM, Stephen Colebourne wrote: > On 5 December 2012 15:33, Lance Andersen - Oracle > wrote: >>> My question was really whether the JDBC group care about enhancing the >>> sql classes, or whether they are content to let them be and get >>> everyone to move to the new types. >> >> I would rather let them be and just use the 310 classes if they desire. >> >> As we discussed before we will add support for specific 310 types via set/getObject which is how we would envision people taking advantage of new data types including 310. >> >> So as developers are ready to move they will, I just do not see a big advantage in adding new features to the old classes as they have enough baggage as it is. > > I'm happy to not upgrade the sql classes. However it should be noted > that any methods, such as toInstant() or from(...) will be inherited > by the sql classes, providing another oddity for developers. So java.util.Date was extended? Then this will cause issues if the sql classes do not at least override and throw an Exception such as setMinutes(). So we will need to discuss this I guess and who will do the work > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From scolebourne at joda.org Wed Dec 5 08:37:55 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 16:37:55 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: On 5 December 2012 16:35, Lance Andersen - Oracle wrote: >> I'm happy to not upgrade the sql classes. However it should be noted >> that any methods, such as toInstant() or from(...) will be inherited >> by the sql classes, providing another oddity for developers. > > So java.util.Date was extended? Then this will cause issues if the sql classes do not at least override and throw an Exception such as setMinutes(). > > So we will need to discuss this I guess and who will do the work j.u.Date ,ay get a toInstant() methods and a from(...) static method. sql.Date and sql.Time may want to block the toInstant(). Stephen From Lance.Andersen at oracle.com Wed Dec 5 09:30:53 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Dec 2012 12:30:53 -0500 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: <7C0928BF-C82E-44D1-9D48-5AAE97B07EEF@oracle.com> Message-ID: <1BB43F9B-ABCC-4529-A632-D846ABB26AA9@oracle.com> On Dec 5, 2012, at 11:37 AM, Stephen Colebourne wrote: > On 5 December 2012 16:35, Lance Andersen - Oracle > wrote: >>> I'm happy to not upgrade the sql classes. However it should be noted >>> that any methods, such as toInstant() or from(...) will be inherited >>> by the sql classes, providing another oddity for developers. >> >> So java.util.Date was extended? Then this will cause issues if the sql classes do not at least override and throw an Exception such as setMinutes(). >> >> So we will need to discuss this I guess and who will do the work > > j.u.Date ,ay get a toInstant() methods and a from(...) static method. > sql.Date and sql.Time may want to block the toInstant(). thanks for the info. let me follow up with Douglas, Roger and Sherman and then I can figure out what we really need to do to these lovely classes :-) Best Lance > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Wed Dec 5 09:34:59 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 05 Dec 2012 09:34:59 -0800 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> Message-ID: <50BF85C3.2050101@oracle.com> To implement DateTimeAccessor on Date/GregorianCalendar will not make the migration easier, it will actually prevent from migrating the old code to new one. My experience indicates in most cases, developer will simply pass around the old Date and GregorianC into the new date/time based code, if they can. Sure the spec of DateTimeAccessor does not say it should be implemented as mutable and yes, we have that "DateTimeBuilder" around. But I think one of the design goals of threeten is to have all date/time around immutable, and this has been one of major reasons lots of suggestions have been rejected in the past year, why we want to open the door now for two well-known mutable date/time types from the "old" world. I don't see any reason why developer would be upset if they have to do date.toInstant()/ cal.toZonedDateTime() before pass their old date/time into the new system. Performance might be a concern for some apps, but this might just motivate them to go up level a little to see if those Date and GregorianCalendar should be Instant and ZDT at first place. -Sherman On 12/05/2012 07:15 AM, Stephen Colebourne wrote: > On 5 December 2012 06:13, Xueming Shen wrote: >> Date<-> Instant appears to be a must, in which it provides the >> connection/conversion >> at the bottom between two different systems, so we don't need Date<-> ODT >> for >> example. >> >> How to support the Date<-> Instant? >> >> I believe we only need ONE straightforward/direct conversion, don't need to >> provide >> multiple convenient vehicles here, developer should just use this entry >> point to convert >> between these two types. As you suggested, use nio.file as an example, a >> simple pair >> of File.toPath() and Path.toFile() should be good enough. >> >> Date.toInstant() and "util.Date must support the same fields as Instant - >> INSTANT_SECONDS and the three fractional seconds fields" are obviously >> redundant. >> With this, now you can do >> >> Date date = ...; >> Instant instant = date.toInstant(); >> or >> Instant instant = Instant.from(date); >> >> If we don't need two, which one is better? DateTimeAccessor appears to be >> convenient, with this, you can also do OffsetDateTime.from(date), and any >> "extended" >> date/time that knows INSTANT_SECONDS+fractional sec fields can work with >> u.Date >> as well. But it also brings us the biggest problem, all of the sudden, >> j.u.Date can fly >> freely inside the new JSR310 system. Conveniently, our datetime formatter >> also magically >> work with j.u.Date. Is this something you want to see? It appears to be an >> integration >> of two systems, not a bridge. Sure, it provides convenience, but it also has >> the >> consequence, you now have a mutable DateTimeAccessor running around your >> JSR310 >> code. > DateTimeAccessor has always been known to be possibly mutable. Its an > interface, so nothing there can really be controlled. Having a > java.util.Date (or Calendar) work with the new immutable formatter > seems like a good thing - easy for developers to fix thread-unsafe > static formatters in their current code. > > Integration is essentially what the system has been designed for. > Previous designs did it in different ways, but they all were planned > such that the old classes would implement the new interface, allowing > general use. > >> So personally I think a simple Date.toInstant() is the best choice, it >> provide a "single" >> entry point for all those "old" date/time. The code that uses JSR310 >> date/time should >> just work with new date/time, old date/time need to be converted into new >> types to >> get in. >> >> A Instant.toDate() will be a little confusing, I would suggest just do >> Date.fromInstant(). > Clearly, this satisfies the basic problem, but its not what was > intended in the design (which was DateTimeAccessor). > > There are actually four sensible options: > > A) toInstant() and from(Instant), j.u.Date not implement DateTimeAccessor > B) toInstant() and from(DateTimeAccessor), j.u.Date not implement > DateTimeAccessor > C) from(DateTimeAccessor), j.u.Date implements DateTimeAccessor > D) toInstant() and from(DateTimeAccessor), j.u.Date implements DateTimeAccessor > > I'd always intended (D), as it best matches the rest fo 310. > > Note that (B), (C), (D) allow j.u.Date.from(zoneDateTime) or > from(offsetDateTime), which (A) does not, and these seem like useful > conversions. > > OffsetDateTime.from(j.u.Date) will not work in any option, as there is > no offset. > >> In theory, it's doable to bridge the conversion of GregorianCalendar and ZDT >> by >> >> GregorianCalendar<-> Date<-> Instant<-> ZDT, >> >> but obviously the "zone" is missing, it's probably not desirable to use >> "default". So, it >> appears GregorianCalendar<-> ZDT is another candidate. For same reason I >> mentioned >> above, I don't think you want to "integrate" GregorianCalendar into the new >> system, stop >> it by forcing it to be the immutable ZDT before any new code can touch it. >> Otherwise, >> the worse thing is that, not like j.u.Date, those "setting" methods of >> GregorianCalendar >> are not deprecated. > Again, this works but isn't ideal. My aim was to provide an easy > migration, not a hard one. > > Stephen From richard.warburton at gmail.com Wed Dec 5 09:46:51 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Wed, 5 Dec 2012 17:46:51 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: <50BF6D13.7050707@christopherschultz.net> References: <50BF6D13.7050707@christopherschultz.net> Message-ID: > Would it be feasible to limit all integration with existing APIs to the > new API itself? I don't really see the need to modify, say, > java.util.Date. If we provide conversion methods in the new API to > import/export java.util.Date, that should be sufficient and will not > change the existing APIs -- which I see as a definite win. > When this was discussed before there was a preference expressed to try and keep the integration code on the old classes. This has the advantage that it keeps the new API clean and only people who need to interact with the old Date and calendar APIs need to see the conversion methods. regards, Richard From douglas.surber at oracle.com Wed Dec 5 10:10:00 2012 From: douglas.surber at oracle.com (Douglas Surber) Date: Wed, 05 Dec 2012 10:10:00 -0800 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: References: Message-ID: <6.2.5.6.2.20121205085347.061ef6c8@oracle.com> Stephen, Can you confirm that all of the following work in your proposal? LocalTime t1 = LocalTime.from(aJavaSqlTime); LocalTime t2 = LocalTime.from(aJavaSqlTimestamp); LocalDate t3 = LocalDate.from(aJavaSqlDate); LocalDate t4 = LocalDate.from(aJavaSqlTimestamp); LocalDateTime t5 = LocalDateTime.from(aJavaSqlTimestamp); With the addition methods java.sql.Time t6 = java.sql.Time.from(aLocalTime); java.sql.Date t7 = java.sql.Date.from(aLocalDate); java.sql.Timestamp t8 = java.sql.Timestamp.from(aLocalDateTime); java.sql.Timestamp t9 = java.sql.Timestamp.from(anOffsetDateTime); java.sql.Timestamp t10 = java.sql.Timestamp.from(aZonedDateTime); I guess these would work as well. java.sql.Time t11 = java.sql.Time.from(aLocalDateTime); java.sql.Time t12 = java.sql.Time.from(anOffsetDateTime); java.sql.Time t13 = java.sql.Time.from(aZonedDateTime); java.sql.Date t14 = java.sql.Date.from(aLocalDateTime); java.sql.Date t15 = java.sql.Date.from(anOffsetDateTime); java.sql.Date t16 = java.sql.Date.from(aZonedDateTime); What happens with these? OffsetDateTime t17 = OffsetDateTime.from(aJavaSqlTimestamp); ZonedDateTime t18 = ZonedDateTime.from(aJavaSqlTimestamp); I would expect them to fail as java.sql.Timestamp does not have an offset or zone id. Thanks. Douglas At 06:46 AM 12/5/2012, Stephen Colebourne wrote: >The question is to what degree should existing JDK date/time classes >support integration with 310? >Key open question to everyone is how much integration should be >done? > >Here is my list and proposls: >util.Date - implement DateTimeAccessor (INSTANT_SECONDS and >fractional >second fields) >sql.Date - implement DateTimeAccessor (EPOCH_DAY and related) >sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related) >sql.Timestamp - implement DateTimeAccessor (all ChronoField) >Calendar - implement DateTimeAccessor (all ChronoField) >GregorianCalendar - implement DateTimeAccessor (all ChronoField and >zone) >FileTime should implement DateTimeAccessor >xml.XMLGregorianCalendar should implement DateTimeAccessor >xml.Duration should implement PlusAdjuster and MinusAdjuster >TimeUnit should implement PeriodUnit > >In addition, some common additional methods would be very helpful: >Date.toInstant() >util.Date.from(DateTimeAccessor) >sql.Date.from(DateTimeAccessor) >sql.Time.from(DateTimeAccessor) >sql.Timestamp.from(DateTimeAccessor) >Calendar.toInstant() >Calendar.from(DateTimeAccessor) >GregorianCalendar.toZonedDateTime() >GregorianCalendar.from(DateTimeAccessor) > >GregorianCalendar might beneft from toLocalDate() and toLocalTime(). > >The sql subtypes of util.Date are of course troublesome. The JDBC >group need to advise on whether they consider them effectively >deprecated or not. > >DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is >exactly 24 hours. > >I think that is all the JDK date/time classes. I could be wrong... > >Stephen >(This was a private discussion being made public) > >------------------------------------------------------------------------------ >LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >Remotely access PCs and mobile devices and provide instant support >Improve your efficiency, and focus on delivering more value-add >services >Discover what IT Professionals Know. Rescue delivers >http://p.sf.net/sfu/logmein_12329d2d >_______________________________________________ >threeten-develop mailing list >threeten-develop at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/threeten-develop From xueming.shen at oracle.com Wed Dec 5 11:08:45 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 19:08:45 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Took fmt text/style providers private. Message-ID: <20121205190857.3B31F47E4E@hg.openjdk.java.net> Changeset: e16b200f15f5 Author: sherman Date: 2012-12-05 11:08 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e16b200f15f5 Took fmt text/style providers private. Repared the broken tz compiler from last merge ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/format/DateTimeTextProvider.java - src/share/classes/javax/time/format/SimpleDateTimeFormatStyleProvider.java - src/share/classes/javax/time/format/SimpleDateTimeTextProvider.java ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java - test/javax/time/tck/javax/time/format/TCKSimpleDateTimeTextProvider.java - test/javax/time/tck/javax/time/zone/TestTzdbZoneRulesCompiler.java + test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java From xueming.shen at oracle.com Wed Dec 5 11:12:24 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 19:12:24 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121205191247.8607F47E51@hg.openjdk.java.net> Changeset: df5619994dc3 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/df5619994dc3 Added tag jdk8-b66 for changeset 4d337fae2250 ! .hgtags Changeset: 5855ad837019 Author: sherman Date: 2012-12-05 11:12 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5855ad837019 Merge From scolebourne at joda.org Wed Dec 5 14:42:09 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 22:42:09 +0000 Subject: [threeten-dev] [threeten-develop] Integration with other JDK classes In-Reply-To: <6.2.5.6.2.20121205085347.061ef6c8@oracle.com> References: <6.2.5.6.2.20121205085347.061ef6c8@oracle.com> Message-ID: On 5 December 2012 18:10, Douglas Surber wrote: > Can you confirm that all of the following work in your proposal? > LocalTime t1 = LocalTime.from(aJavaSqlTime); > LocalTime t2 = LocalTime.from(aJavaSqlTimestamp); > > LocalDate t3 = LocalDate.from(aJavaSqlDate); > LocalDate t4 = LocalDate.from(aJavaSqlTimestamp); > > LocalDateTime t5 = LocalDateTime.from(aJavaSqlTimestamp); I'm not sure I have a precise proposal ;-) None of them will happen without work on the part of JDBC and agreement with Roger/Sherman. To make the above work requires java.util.Date (or each of the three subclasses) to implement DateTimeAccessor. Implementing that interface is a reasonable size commitment, but does provide power as the benefit. For example, implementing the interface would allow the conversions above, and use of the sql classes in the 310 formatters. The question is whether the value is really there to implement the interface, or whether it causes more harm than good. The alternative is to add - sql.Time.toLocalTime() - sql.Date.toLocalDate() - sql.Timestamp.toLocalDateTime() which allow fewer conversions (and less power) but also help "encourage" users to use the 310 classes. > With the addition methods > > java.sql.Time t6 = java.sql.Time.from(aLocalTime); > java.sql.Date t7 = java.sql.Date.from(aLocalDate); > java.sql.Timestamp t8 = java.sql.Timestamp.from(aLocalDateTime); > java.sql.Timestamp t9 = java.sql.Timestamp.from(anOffsetDateTime); > java.sql.Timestamp t10 = java.sql.Timestamp.from(aZonedDateTime); I do believe that adding from(DateTimeAccessor) to each of the three sql classes would be beneficial if (and only if) you want developers to carry on using those classes. Since JDBC will be updated to allow use of LocalDate etc anyway, it could be argued that there will be no need to convert to the sql classes in JDK8. (BTW, the above assumes that Timestamp maps to LocalDateTime - I assume that is the mapping the JDBC team has in their heads? > I guess these would work as well. > java.sql.Time t11 = java.sql.Time.from(aLocalDateTime); > java.sql.Time t12 = java.sql.Time.from(anOffsetDateTime); > java.sql.Time t13 = java.sql.Time.from(aZonedDateTime); > java.sql.Date t14 = java.sql.Date.from(aLocalDateTime); > java.sql.Date t15 = java.sql.Date.from(anOffsetDateTime); > java.sql.Date t16 = java.sql.Date.from(aZonedDateTime); If from(DateTimeAccessor) is added, all these would work. > What happens with these? > OffsetDateTime t17 = OffsetDateTime.from(aJavaSqlTimestamp); > ZonedDateTime t18 = ZonedDateTime.from(aJavaSqlTimestamp); > > I would expect them to fail as java.sql.Timestamp does not have an > offset or zone id. These would fail, and would only compile if the sql classes implement DateTimeAccessor. Stephen From xueming.shen at oracle.com Wed Dec 5 14:46:02 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 05 Dec 2012 14:46:02 -0800 Subject: [threeten-dev] default method for interface Message-ID: <50BFCEAA.6030905@oracle.com> Do I miss anything? http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM2/ From scolebourne at joda.org Wed Dec 5 14:53:44 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 22:53:44 +0000 Subject: [threeten-dev] default method for interface In-Reply-To: <50BFCEAA.6030905@oracle.com> References: <50BFCEAA.6030905@oracle.com> Message-ID: TestDateTimes_implementation should probably be deleted. Stephen On 5 December 2012 22:46, Xueming Shen wrote: > Do I miss anything? > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM2/ From scolebourne at joda.org Wed Dec 5 15:14:42 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 23:14:42 +0000 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: References: Message-ID: On 5 December 2012 04:36, wrote: > "The pattern string is also similar, but not identical, to that defined by > the Unicode Common Locale Data Repository (CLDR)." This is the relevent section of comments in the code FIELD_MAP.put('G', ChronoField.ERA); // Java, CLDR (different to both for 1/2 chars) FIELD_MAP.put('y', ChronoField.YEAR); // CLDR // FIELD_MAP.put('y', ChronoField.YEAR_OF_ERA); // Java, CLDR // TODO redefine from above // FIELD_MAP.put('u', ChronoField.YEAR); // CLDR // TODO // FIELD_MAP.put('Y', ISODateTimeField.WEEK_BASED_YEAR); // Java7, CLDR (needs localized week number) // TODO // FIELD_MAP.put('Q', QuarterYearField.QUARTER_OF_YEAR); // CLDR (removed quarter from 310) // FIELD_MAP.put('q', QuarterYearField.QUARTER_OF_YEAR); // CLDR (needs standalone data) // TODO FIELD_MAP.put('M', ChronoField.MONTH_OF_YEAR); // Java, CLDR // FIELD_MAP.put('L', ChronoField.MONTH_OF_YEAR); // Java, CLDR (needs standalone data) // TODO // FIELD_MAP.put('w', ISODateTimeField.WEEK_OF_WEEK_BASED_YEAR); // Java, CLDR (needs localized week number) // TODO FIELD_MAP.put('D', ChronoField.DAY_OF_YEAR); // Java, CLDR FIELD_MAP.put('d', ChronoField.DAY_OF_MONTH); // Java, CLDR FIELD_MAP.put('F', ChronoField.ALIGNED_WEEK_OF_MONTH); // Java, CLDR FIELD_MAP.put('E', ChronoField.DAY_OF_WEEK); // Java, CLDR (different to both for 1/2 chars) // FIELD_MAP.put('e', ChronoField.DAY_OF_WEEK); // CLDR (needs localized week number) // TODO // FIELD_MAP.put('c', ChronoField.DAY_OF_WEEK); // CLDR (needs standalone data) // TODO FIELD_MAP.put('a', ChronoField.AMPM_OF_DAY); // Java, CLDR FIELD_MAP.put('H', ChronoField.HOUR_OF_DAY); // Java, CLDR FIELD_MAP.put('k', ChronoField.CLOCK_HOUR_OF_DAY); // Java, CLDR FIELD_MAP.put('K', ChronoField.HOUR_OF_AMPM); // Java, CLDR FIELD_MAP.put('h', ChronoField.CLOCK_HOUR_OF_AMPM); // Java, CLDR FIELD_MAP.put('m', ChronoField.MINUTE_OF_HOUR); // Java, CLDR FIELD_MAP.put('s', ChronoField.SECOND_OF_MINUTE); // Java, CLDR FIELD_MAP.put('S', ChronoField.NANO_OF_SECOND); // CLDR (Java uses milli-of-second number) FIELD_MAP.put('A', ChronoField.MILLI_OF_DAY); // CLDR FIELD_MAP.put('n', ChronoField.NANO_OF_SECOND); // 310 FIELD_MAP.put('N', ChronoField.NANO_OF_DAY); // 310 // reserved - z,Z,X,I,p // Java - X - compatible, but extended to 4 and 5 letters // Java - u - clashes with CLDR, go with CLDR (year-proleptic) here // CLDR - U - cycle year name, not supported by 310 yet // CLDR - l - deprecated // CLDR - W - week-of-month following CLDR rules // CLDR - j - not relevant // CLDR - g - modified-julian-day // CLDR - z - time-zone names // TODO properly // CLDR - Z - different approach here // TODO bring 310 in line with CLDR // CLDR - v,V - extended time-zone names // 310 - I - time-zone id // 310 - p - prefix for padding If you can decode my comments you'll find a variety of differences. > With my quick review, following pattern letters are not available in LDML > specification > > n nano-of-second number/fraction 987654321 > N nano-of-day number/fraction 1234000000 > I time-zone ID zoneID America/Los_Angeles > > I think all of these make sense. In longer term, I don't want to see > different pattern definition across similar implementations. If these are > final, I'm happy to work on CLDR side and propose these pattern letters > registered in the LDML specification. It would be good to see these in LDML. As of now, n and N are simple numbers, not fractions. (Previously, I used 'f' as a prefix turning the next letter into a fraction) However, "I" is interesting. In 310 we now have three underlying concepts offsets from UTC/Greenwich, regional time-zone IDs and general time-zone IDs (either an offset ID or a region ID). Most text formats would want to print both the offset and the time-zone ID, but they would not want to print the time-zone ID if it is an offset (as opposed to a region). Thus, "I" should probably be the subset of all time-zone IDs that represent regions. This works well in 310 where we have this distinction, but may be tricky in LDML. > X zone-offset 'Z' for zero offset-X Z; -0800; -08:00; > > This one is tricky. We recently added ISO 8601 style offset format in the > LDML specification with "ZZZZZ" > LDML "ZZZZZ" formats UTC to "Z" and non-UTC offsets using longer format > such as "-08:00" (with colon). > > Z zone-offset offset-Z +0000; -0800; > -08:00; > > On the other hand, pattern letter "Z" in the LDML specification uses the > following definition- > > Z, ZZ, ZZZ -> RFC822 format > ZZZZ -> Localized GMT format, such as "GMT-08:00" "UTC-08:00"... > > I personally think CLDR may introduce pattern X, supporting both > long/short offset format, and deprecate "ZZZZZ" (or simply leave it as an > alias definition). > > For offset format, CLDR community is now seeking for shorter offset format > support. For example, "GMT-3" instead of "GMT-03:00". We don't have that right now. > Anyway, I'll consult with CLDR community members to find out if CLDR can > provide compatible definitions for these too. Keep us informed. We may have some ability to tweak these patterns for the next few months, but it will be increasingly difficult. Stephen From xueming.shen at oracle.com Wed Dec 5 15:19:02 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 05 Dec 2012 15:19:02 -0800 Subject: [threeten-dev] default method for interface In-Reply-To: References: <50BFCEAA.6030905@oracle.com> Message-ID: <50BFD666.9090407@oracle.com> removed. http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM2/ On 12/5/12 2:53 PM, Stephen Colebourne wrote: > TestDateTimes_implementation should probably be deleted. > Stephen > > On 5 December 2012 22:46, Xueming Shen wrote: >> Do I miss anything? >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/defaultM2/ From xueming.shen at oracle.com Wed Dec 5 15:56:06 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 05 Dec 2012 23:56:06 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Switched to use real jdk8 interface default method support. Message-ID: <20121205235640.7D61347EC8@hg.openjdk.java.net> Changeset: e41f9697d8f2 Author: sherman Date: 2012-12-05 15:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e41f9697d8f2 Switched to use real jdk8 interface default method support. ! src/share/classes/javax/time/Clock.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendrical/DateTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/calendrical/DateTimeBuilder.java ! src/share/classes/javax/time/calendrical/ISOWeeks.java ! src/share/classes/javax/time/calendrical/JulianDayField.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/Era.java ! src/share/classes/javax/time/chrono/global/ChronoDateImpl.java ! src/share/classes/javax/time/chrono/global/HijrahDate.java ! src/share/classes/javax/time/chrono/global/JapaneseEra.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDate.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceDateTimeAccessor.java - src/share/classes/javax/time/jdk8/DefaultInterfaceEra.java - src/share/classes/javax/time/jdk8/Jdk8Methods.java - src/share/classes/javax/time/jdk8/package.html ! src/share/classes/javax/time/zone/StandardZoneRules.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java - test/javax/time/test/javax/time/TestDateTimes_implementation.java ! test/javax/time/test/javax/time/calendrical/MockFieldValue.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java From xueming.shen at oracle.com Wed Dec 5 16:05:41 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 06 Dec 2012 00:05:41 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Removed the javax.time.jdk8 from the doc Message-ID: <20121206000552.6F95E47ECB@hg.openjdk.java.net> Changeset: 041c61342a88 Author: sherman Date: 2012-12-05 16:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/041c61342a88 Removed the javax.time.jdk8 from the doc ! make/docs/CORE_PKGS.gmk ! make/netbeans/threeten/build.xml From masayoshi.okutsu at oracle.com Wed Dec 5 22:36:39 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 06 Dec 2012 15:36:39 +0900 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: <50BF85C3.2050101@oracle.com> References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> <50BF85C3.2050101@oracle.com> Message-ID: <50C03CF7.6090706@oracle.com> I agree with Sherman. The new things should be imported into the old ones. But not the other way around. The conversion between java.util.Calendar and 310 is very tricky. java.util.Calendar to 310: How about a similar approach to DateTimeFormatter.parse? Something like this: public T to(class type) Performance may not be great, but it's clean. 310 to java.util.Calendar: I prefer to introduce a Builder class in Calendar. I was planning to add Calendar.Builder support in JDK 8 for some different reasons. Also, TimeZone needs something like getTimeZone(ZoneID), and maybe another one from a ZoneOffset. Thanks, Masayoshi On 12/6/2012 2:34 AM, Xueming Shen wrote: > To implement DateTimeAccessor on Date/GregorianCalendar will not make > the migration easier, it will actually prevent from migrating the old > code to > new one. My experience indicates in most cases, developer will simply > pass > around the old Date and GregorianC into the new date/time based code, if > they can. > > Sure the spec of DateTimeAccessor does not say it should be implemented > as mutable and yes, we have that "DateTimeBuilder" around. But I think > one of the design goals of threeten is to have all date/time around > immutable, > and this has been one of major reasons lots of suggestions have been > rejected in the past year, why we want to open the door now for two > well-known mutable date/time types from the "old" world. I don't see any > reason why developer would be upset if they have to do date.toInstant()/ > cal.toZonedDateTime() before pass their old date/time into the new > system. > Performance might be a concern for some apps, but this might just > motivate > them to go up level a little to see if those Date and > GregorianCalendar should > be Instant and ZDT at first place. > > -Sherman > > On 12/05/2012 07:15 AM, Stephen Colebourne wrote: >> On 5 December 2012 06:13, Xueming Shen wrote: >>> Date<-> Instant appears to be a must, in which it provides the >>> connection/conversion >>> at the bottom between two different systems, so we don't need >>> Date<-> ODT >>> for >>> example. >>> >>> How to support the Date<-> Instant? >>> >>> I believe we only need ONE straightforward/direct conversion, don't >>> need to >>> provide >>> multiple convenient vehicles here, developer should just use this entry >>> point to convert >>> between these two types. As you suggested, use nio.file as an >>> example, a >>> simple pair >>> of File.toPath() and Path.toFile() should be good enough. >>> >>> Date.toInstant() and "util.Date must support the same fields as >>> Instant - >>> INSTANT_SECONDS and the three fractional seconds fields" are obviously >>> redundant. >>> With this, now you can do >>> >>> Date date = ...; >>> Instant instant = date.toInstant(); >>> or >>> Instant instant = Instant.from(date); >>> >>> If we don't need two, which one is better? DateTimeAccessor appears >>> to be >>> convenient, with this, you can also do OffsetDateTime.from(date), >>> and any >>> "extended" >>> date/time that knows INSTANT_SECONDS+fractional sec fields can work >>> with >>> u.Date >>> as well. But it also brings us the biggest problem, all of the sudden, >>> j.u.Date can fly >>> freely inside the new JSR310 system. Conveniently, our datetime >>> formatter >>> also magically >>> work with j.u.Date. Is this something you want to see? It appears to >>> be an >>> integration >>> of two systems, not a bridge. Sure, it provides convenience, but it >>> also has >>> the >>> consequence, you now have a mutable DateTimeAccessor running around >>> your >>> JSR310 >>> code. >> DateTimeAccessor has always been known to be possibly mutable. Its an >> interface, so nothing there can really be controlled. Having a >> java.util.Date (or Calendar) work with the new immutable formatter >> seems like a good thing - easy for developers to fix thread-unsafe >> static formatters in their current code. >> >> Integration is essentially what the system has been designed for. >> Previous designs did it in different ways, but they all were planned >> such that the old classes would implement the new interface, allowing >> general use. >> >>> So personally I think a simple Date.toInstant() is the best choice, it >>> provide a "single" >>> entry point for all those "old" date/time. The code that uses JSR310 >>> date/time should >>> just work with new date/time, old date/time need to be converted >>> into new >>> types to >>> get in. >>> >>> A Instant.toDate() will be a little confusing, I would suggest just do >>> Date.fromInstant(). >> Clearly, this satisfies the basic problem, but its not what was >> intended in the design (which was DateTimeAccessor). >> >> There are actually four sensible options: >> >> A) toInstant() and from(Instant), j.u.Date not implement >> DateTimeAccessor >> B) toInstant() and from(DateTimeAccessor), j.u.Date not implement >> DateTimeAccessor >> C) from(DateTimeAccessor), j.u.Date implements DateTimeAccessor >> D) toInstant() and from(DateTimeAccessor), j.u.Date implements >> DateTimeAccessor >> >> I'd always intended (D), as it best matches the rest fo 310. >> >> Note that (B), (C), (D) allow j.u.Date.from(zoneDateTime) or >> from(offsetDateTime), which (A) does not, and these seem like useful >> conversions. >> >> OffsetDateTime.from(j.u.Date) will not work in any option, as there is >> no offset. >> >>> In theory, it's doable to bridge the conversion of GregorianCalendar >>> and ZDT >>> by >>> >>> GregorianCalendar<-> Date<-> Instant<-> ZDT, >>> >>> but obviously the "zone" is missing, it's probably not desirable to use >>> "default". So, it >>> appears GregorianCalendar<-> ZDT is another candidate. For same >>> reason I >>> mentioned >>> above, I don't think you want to "integrate" GregorianCalendar into >>> the new >>> system, stop >>> it by forcing it to be the immutable ZDT before any new code can >>> touch it. >>> Otherwise, >>> the worse thing is that, not like j.u.Date, those "setting" methods of >>> GregorianCalendar >>> are not deprecated. >> Again, this works but isn't ideal. My aim was to provide an easy >> migration, not a hard one. >> >> Stephen > From scolebourne at joda.org Thu Dec 6 02:45:44 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 6 Dec 2012 10:45:44 +0000 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: <50C03CF7.6090706@oracle.com> References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> <50BF85C3.2050101@oracle.com> <50C03CF7.6090706@oracle.com> Message-ID: On 6 December 2012 06:36, Masayoshi Okutsu wrote: > I agree with Sherman. The new things should be imported into the old ones. > But not the other way around. > > The conversion between java.util.Calendar and 310 is very tricky. > > java.util.Calendar to 310: > > How about a similar approach to DateTimeFormatter.parse? Something like > this: > > public T to(class type) This would probably require reflection to implement, so isn't really ideal. I think toInstant() and toZoneDateTime() cover most cases. > 310 to java.util.Calendar: > > I prefer to introduce a Builder class in Calendar. I was planning to add > Calendar.Builder support in JDK 8 for some different reasons. Also, TimeZone > needs something like getTimeZone(ZoneID), and maybe another one from a > ZoneOffset. Or from(ZoneId) ? ZoneOffset is now a subclass of ZoneId, so does not need a separate method. Stephen From scolebourne at joda.org Thu Dec 6 08:42:12 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 06 Dec 2012 16:42:12 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121206164304.22EEC47F32@hg.openjdk.java.net> Changeset: 50e735489e89 Author: scolebourne Date: 2012-12-06 12:50 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/50e735489e89 Remove generics warnings ! test/javax/time/tck/javax/time/chrono/TestChrono.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java Changeset: 2da410d420b7 Author: scolebourne Date: 2012-12-06 13:09 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2da410d420b7 Merge - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDate.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoLocalDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceChronoZonedDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceDateTime.java - src/share/classes/javax/time/jdk8/DefaultInterfaceDateTimeAccessor.java - src/share/classes/javax/time/jdk8/DefaultInterfaceEra.java - src/share/classes/javax/time/jdk8/Jdk8Methods.java - src/share/classes/javax/time/jdk8/package.html - test/javax/time/test/javax/time/TestDateTimes_implementation.java From scolebourne at joda.org Thu Dec 6 08:45:25 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 06 Dec 2012 16:45:25 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix ant build Message-ID: <20121206164536.33DB347F35@hg.openjdk.java.net> Changeset: 2b1e1fc3488c Author: scolebourne Date: 2012-12-06 16:43 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2b1e1fc3488c Fix ant build ! make/netbeans/threeten/build.xml From scolebourne at joda.org Thu Dec 6 11:22:57 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 6 Dec 2012 19:22:57 +0000 Subject: [threeten-dev] Zone or Zoned DateTime In-Reply-To: References: Message-ID: Class renamed to ZoneDateTime by popular demand. Stephen On 4 December 2012 18:23, Stephen Colebourne wrote: > Views on this please. > > Should we stick with ZonedDateTime, or change to ZoneDateTime? > > It is one letter difference, and not much semantic difference. I'm so > used to Zoned that I don't really think about it, but if there are > lots of arguments for Zone then I might consider a change. > > Stephen From scolebourne at joda.org Thu Dec 6 11:19:37 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 06 Dec 2012 19:19:37 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121206192029.137DE47F4B@hg.openjdk.java.net> Changeset: 61c0dd069667 Author: scolebourne Date: 2012-12-06 18:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/61c0dd069667 Fix unchecked warning ! src/share/classes/javax/time/chrono/Era.java Changeset: 84e6fbb3e0bd Author: scolebourne Date: 2012-12-06 19:04 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/84e6fbb3e0bd Rename ZonedDateTime to ZoneDateTime ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/Ser.java + src/share/classes/javax/time/ZoneDateTime.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneRegion.java - src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendrical/ChronoUnit.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java + src/share/classes/javax/time/chrono/ChronoZoneDateTime.java + src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java - src/share/classes/javax/time/chrono/ChronoZonedDateTime.java - src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/chrono/Ser.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/package.html ! src/share/classes/javax/time/zone/ZoneRulesProvider.java + test/javax/time/resources/ZoneDateTime.bin - test/javax/time/resources/ZonedDateTime.bin ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java + test/javax/time/tck/javax/time/TCKZoneDateTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java - test/javax/time/tck/javax/time/TCKZonedDateTime.java + test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java - test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/test/javax/time/TestClock_Tick.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java Changeset: f4756a3ea358 Author: scolebourne Date: 2012-12-06 19:19 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f4756a3ea358 Rename ZonedDateTime to ZoneDateTime - Javadoc ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZoneDateTime.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTime.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/format/DateTimeFormatters.java From xueming.shen at oracle.com Thu Dec 6 12:18:23 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 06 Dec 2012 12:18:23 -0800 Subject: [threeten-dev] some makefile and test update Message-ID: <50C0FD8F.9000604@oracle.com> This is proposed changeset is to (1) move the tzdb "build" stuff from the make/tool/tzcompiler + make/sun/javazic into make/javax/time/Makefile. For two reason - make the new build infra" stuff to work -the tzdb.jar actually has the dependency on those zone impl, so it's more reasonable to update the tzdb.jar if those imples updated. (2) move the TestNG def from the top test properties file TEST.ROOT into the "local" test/javax/time/TEST.properties. http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test -Sherman From scolebourne at joda.org Thu Dec 6 16:38:17 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 7 Dec 2012 00:38:17 +0000 Subject: [threeten-dev] some makefile and test update In-Reply-To: <50C0FD8F.9000604@oracle.com> References: <50C0FD8F.9000604@oracle.com> Message-ID: Looks like the TZDB generation includes solar files and maybe others that 310 was deliberately omitting. Stephen On Dec 6, 2012 8:18 PM, "Xueming Shen" wrote: > This is proposed changeset is to > > (1) move the tzdb "build" stuff from the make/tool/tzcompiler + > make/sun/javazic > into make/javax/time/Makefile. For two reason > - make the new build infra" stuff to work > -the tzdb.jar actually has the dependency on those zone impl, so it's > more > reasonable to update the tzdb.jar if those imples updated. > > (2) move the TestNG def from the top test properties file > TEST.ROOT into the "local" test/javax/time/TEST.**properties. > > http://cr.openjdk.java.net/~**sherman/jdk8_threeten/**tzdbbuild_test > > -Sherman > From xueming.shen at oracle.com Thu Dec 6 17:47:09 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 06 Dec 2012 17:47:09 -0800 Subject: [threeten-dev] some makefile and test update In-Reply-To: References: <50C0FD8F.9000604@oracle.com> Message-ID: <50C14A9D.40902@oracle.com> Any reason that can not be in? since the plan is to migrate the jdk existing tzdb code to use/share the tzdb.jar date, probaby vis StandardZoneRules (I did the prototype early this year). So the tzdb.jar will need all data jdk currently supports for compatibility reason. Though I'm not sure those solar files really matter or not. On 12/6/12 4:38 PM, Stephen Colebourne wrote: > > Looks like the TZDB generation includes solar files and maybe others > that 310 was deliberately omitting. > Stephen > > On Dec 6, 2012 8:18 PM, "Xueming Shen" > wrote: > > This is proposed changeset is to > > (1) move the tzdb "build" stuff from the make/tool/tzcompiler + > make/sun/javazic > into make/javax/time/Makefile. For two reason > - make the new build infra" stuff to work > -the tzdb.jar actually has the dependency on those zone impl, > so it's more > reasonable to update the tzdb.jar if those imples updated. > > (2) move the TestNG def from the top test properties file > TEST.ROOT into the "local" test/javax/time/TEST.properties. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test > > > -Sherman > From masayoshi.okutsu at oracle.com Thu Dec 6 21:40:58 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 07 Dec 2012 14:40:58 +0900 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> <50BF85C3.2050101@oracle.com> <50C03CF7.6090706@oracle.com> Message-ID: <50C1816A.6060402@oracle.com> On 12/6/2012 7:45 PM, Stephen Colebourne wrote: > On 6 December 2012 06:36, Masayoshi Okutsu wrote: >> I agree with Sherman. The new things should be imported into the old ones. >> But not the other way around. >> >> The conversion between java.util.Calendar and 310 is very tricky. >> >> java.util.Calendar to 310: >> >> How about a similar approach to DateTimeFormatter.parse? Something like >> this: >> >> public T to(class type) > This would probably require reflection to implement, so isn't really > ideal. I thought it'd be a piece of cake to implement it with DateTimeBuilder.build(Class), but it wasn't. I had to take a look at the "real documentation" to determine what fields need to be set to produce an instance of the given class... > I think toInstant() and toZoneDateTime() cover most cases. But a Calendar isn't always a GregorianCalendar. I prototyped the method. Here's a demo. :-) import java.util.*; import javax.time.*; import javax.time.chrono.*; import javax.time.chrono.global.*; public class To310Test { public static void main(String[] args) { Calendar cal = Calendar.getInstance(); LocalDate ld = cal.to(LocalDate.class); System.out.println(cal.getTime() + " -> " + ld); LocalDateTime ldt = cal.to(LocalDateTime.class); System.out.println(cal.getTime() + " -> " + ldt); ZoneDateTime zdt = cal.to(ZoneDateTime.class); System.out.println(cal.getTime() + " -> " + zdt); Calendar jcal = Calendar.getInstance(Locale.forLanguageTag("ja-JP-u-ca-japanese")); @SuppressWarnings("unchecked") ChronoLocalDate jld = (ChronoLocalDate) jcal.to(JapaneseChrono.INSTANCE.dateNow().getClass()); System.out.println(cal.getTime() + " -> " + jld); zdt = jcal.to(ZoneDateTime.class); System.out.println(cal.getTime() + " -> " + zdt); } } It's output: Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07 Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T05:25:05.285 Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T14:25:05.285+09:00[Asia/Tokyo] Fri Dec 07 14:25:05 JST 2012 -> Japanese Heisei 24-12-07 Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T14:25:05.656+09:00[Asia/Tokyo] It's not pretty, but works with the Japanese calendar. LocalDateTime seems to ignore ZoneID in a DateTimeBuilder, but I guess it shouldn't. Thanks, Masayoshi From xueming.shen at oracle.com Fri Dec 7 00:24:26 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 07 Dec 2012 00:24:26 -0800 Subject: [threeten-dev] j.u.Formatter Message-ID: <50C1A7BA.6080100@oracle.com> Hi, Here is the webrev for the change of adding the support of jsr310 new date/time in j.u.Formatter. http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/ Here is the result of the Test310 http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/result The current proposal/impl does not use the default timezone for Instant. Different compared to what j.u.Formatter does for "long" and j.u.Date. I'm not so sure about if the "GMT" should be added to the fixed offset for "Z". Any opinion? Stephen, it appears the ODT/OD/OT might want to return the ZoneOffset when queried by Query.ZONE_ID, given ZoneOffset is a ZoneId now. Opinion? -Sherman From scolebourne at joda.org Fri Dec 7 04:04:17 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 7 Dec 2012 12:04:17 +0000 Subject: [threeten-dev] some makefile and test update In-Reply-To: <50C14A9D.40902@oracle.com> References: <50C0FD8F.9000604@oracle.com> <50C14A9D.40902@oracle.com> Message-ID: In my opinion, we should exclude those IDs that are pretty useless from TZDB We use africa antarctica asia australasia backward etcetera europe northamerica southamerica We exclude solar and pacificnew. There will be cases where you cannot convert a TimeZone to a ZoneId anyway (such as user defined zones) so having some additional ones doesn't seem like a big deal. A bit of a clear up is part of 310's mission. Stephen On 7 December 2012 01:47, Xueming Shen wrote: > Any reason that can not be in? since the plan is to migrate the jdk existing > tzdb code > to use/share the tzdb.jar date, probaby vis StandardZoneRules (I did the > prototype > early this year). So the tzdb.jar will need all data jdk currently supports > for compatibility > reason. Though I'm not sure those solar files really matter or not. > > > On 12/6/12 4:38 PM, Stephen Colebourne wrote: > > Looks like the TZDB generation includes solar files and maybe others that > 310 was deliberately omitting. > Stephen > > On Dec 6, 2012 8:18 PM, "Xueming Shen" wrote: >> >> This is proposed changeset is to >> >> (1) move the tzdb "build" stuff from the make/tool/tzcompiler + >> make/sun/javazic >> into make/javax/time/Makefile. For two reason >> - make the new build infra" stuff to work >> -the tzdb.jar actually has the dependency on those zone impl, so it's >> more >> reasonable to update the tzdb.jar if those imples updated. >> >> (2) move the TestNG def from the top test properties file >> TEST.ROOT into the "local" test/javax/time/TEST.properties. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test >> >> -Sherman > > From scolebourne at joda.org Fri Dec 7 04:33:23 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 7 Dec 2012 12:33:23 +0000 Subject: [threeten-dev] [threeten-develop] j.u.Formatter In-Reply-To: <50C1A7BA.6080100@oracle.com> References: <50C1A7BA.6080100@oracle.com> Message-ID: On 7 December 2012 08:24, Xueming Shen wrote: > Here is the webrev for the change of adding the support of jsr310 new > date/time > in j.u.Formatter. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/ You have manual manipulation of ChronoField.HOUR_OF_DAY, when you should use ChronoField.HOUR_OF_AM_PM, ChronoField.CLOCK_HOUR_OF_AM_PM and , ChronoField.CLOCK_HOUR_OF_DAY > Here is the result of the Test310 > http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/result > > The current proposal/impl does not use the default timezone for Instant. > Different compared to what j.u.Formatter does for "long" and j.u.Date. That seems reasonable. The default time-zone is generally troublesome. > I'm not so sure about if the "GMT" should be added to the fixed offset > for "Z". Any opinion? I think we should not output "GMTZ", but we do accept it in parsing. > Stephen, it appears the ODT/OD/OT might want to return the ZoneOffset > when queried by Query.ZONE_ID, given ZoneOffset is a ZoneId now. Your changes to OD/OT/ODT are certinaly questionable. The idea of the ZONE_ID query was to return the "concept" of zone, not anything that implements ZoneId. However, this may be too strong for users. One option may be a new query of ZONE_OR_OFFSET which can cross-convert an offset if it doesn't find a zone. Note that ZDT.query(ZONE_ID) can return a ZoneOffset because that is stored in the conceptual zone instance variable as returned by getZone(). Whereas ODT does not have a getZone() method, thus ZONE_ID was intended to return null. Stephen From scolebourne at joda.org Fri Dec 7 04:48:45 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 7 Dec 2012 12:48:45 +0000 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: <50C1816A.6060402@oracle.com> References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> <50BF85C3.2050101@oracle.com> <50C03CF7.6090706@oracle.com> <50C1816A.6060402@oracle.com> Message-ID: On 7 December 2012 05:40, Masayoshi Okutsu wrote: >> This would probably require reflection to implement, so isn't really >> ideal. > > I thought it'd be a piece of cake to implement it with > DateTimeBuilder.build(Class), but it wasn't. I'd still like DateTimeBuilder to go away. So I wouldn't rely on that. > I had to take a look at the > "real documentation" to determine what fields need to be set to produce an > instance of the given class... >> I think toInstant() and toZoneDateTime() cover most cases. > > > But a Calendar isn't always a GregorianCalendar. I was proposing toZoneDateTime() on GregorianCalendar only. Stephen > I prototyped the method. Here's a demo. :-) > > import java.util.*; > import javax.time.*; > import javax.time.chrono.*; > import javax.time.chrono.global.*; > > public class To310Test { > public static void main(String[] args) { > Calendar cal = Calendar.getInstance(); > LocalDate ld = cal.to(LocalDate.class); > System.out.println(cal.getTime() + " -> " + ld); > LocalDateTime ldt = cal.to(LocalDateTime.class); > System.out.println(cal.getTime() + " -> " + ldt); > ZoneDateTime zdt = cal.to(ZoneDateTime.class); > System.out.println(cal.getTime() + " -> " + zdt); > > Calendar jcal = > Calendar.getInstance(Locale.forLanguageTag("ja-JP-u-ca-japanese")); > @SuppressWarnings("unchecked") > ChronoLocalDate jld > = (ChronoLocalDate) > jcal.to(JapaneseChrono.INSTANCE.dateNow().getClass()); > System.out.println(cal.getTime() + " -> " + jld); > zdt = jcal.to(ZoneDateTime.class); > System.out.println(cal.getTime() + " -> " + zdt); > } > } > > It's output: > > Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07 > Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T05:25:05.285 > Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T14:25:05.285+09:00[Asia/Tokyo] > Fri Dec 07 14:25:05 JST 2012 -> Japanese Heisei 24-12-07 > Fri Dec 07 14:25:05 JST 2012 -> 2012-12-07T14:25:05.656+09:00[Asia/Tokyo] > > It's not pretty, but works with the Japanese calendar. > > LocalDateTime seems to ignore ZoneID in a DateTimeBuilder, but I guess it > shouldn't. > > Thanks, > Masayoshi > From Roger.Riggs at oracle.com Fri Dec 7 06:03:33 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 07 Dec 2012 09:03:33 -0500 Subject: [threeten-dev] some makefile and test update In-Reply-To: References: <50C0FD8F.9000604@oracle.com> <50C14A9D.40902@oracle.com> Message-ID: <50C1F735.70607@oracle.com> I think the point is that TimeZone and ZoneId will be using a single timezone database and the pre-existing information is needed for backward compatibility. It is a separate question as to whether any information provided by TimeZone can be dropped. Roger On 12/7/2012 7:04 AM, Stephen Colebourne wrote: > In my opinion, we should exclude those IDs that are pretty useless from TZDB > We use africa antarctica asia australasia backward etcetera europe > northamerica southamerica > We exclude solar and pacificnew. > > There will be cases where you cannot convert a TimeZone to a ZoneId > anyway (such as user defined zones) so having some additional ones > doesn't seem like a big deal. A bit of a clear up is part of 310's > mission. > > Stephen > > > On 7 December 2012 01:47, Xueming Shen wrote: >> Any reason that can not be in? since the plan is to migrate the jdk existing >> tzdb code >> to use/share the tzdb.jar date, probaby vis StandardZoneRules (I did the >> prototype >> early this year). So the tzdb.jar will need all data jdk currently supports >> for compatibility >> reason. Though I'm not sure those solar files really matter or not. >> >> >> On 12/6/12 4:38 PM, Stephen Colebourne wrote: >> >> Looks like the TZDB generation includes solar files and maybe others that >> 310 was deliberately omitting. >> Stephen >> >> On Dec 6, 2012 8:18 PM, "Xueming Shen" wrote: >>> This is proposed changeset is to >>> >>> (1) move the tzdb "build" stuff from the make/tool/tzcompiler + >>> make/sun/javazic >>> into make/javax/time/Makefile. For two reason >>> - make the new build infra" stuff to work >>> -the tzdb.jar actually has the dependency on those zone impl, so it's >>> more >>> reasonable to update the tzdb.jar if those imples updated. >>> >>> (2) move the TestNG def from the top test properties file >>> TEST.ROOT into the "local" test/javax/time/TEST.properties. >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test >>> >>> -Sherman >> -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From masayoshi.okutsu at oracle.com Fri Dec 7 06:47:06 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 07 Dec 2012 23:47:06 +0900 Subject: [threeten-dev] j.u.Date/Calendrical/GregorianCalendar In-Reply-To: References: <50BE312C.9030708@oracle.com> <50BE532F.9040903@oracle.com> <50BEE601.7080200@oracle.com> <50BF85C3.2050101@oracle.com> <50C03CF7.6090706@oracle.com> <50C1816A.6060402@oracle.com> Message-ID: <50C2016A.5070308@oracle.com> On 12/7/2012 9:48 PM, Stephen Colebourne wrote: > On 7 December 2012 05:40, Masayoshi Okutsu wrote: >>> This would probably require reflection to implement, so isn't really >>> ideal. >> I thought it'd be a piece of cake to implement it with >> DateTimeBuilder.build(Class), but it wasn't. > I'd still like DateTimeBuilder to go away. So I wouldn't rely on that. Yep. It's poorly designed and implemented.. > >> I had to take a look at the >> "real documentation" to determine what fields need to be set to produce an >> instance of the given class... >>> I think toInstant() and toZoneDateTime() cover most cases. >> >> But a Calendar isn't always a GregorianCalendar. > I was proposing toZoneDateTime() on GregorianCalendar only. It's not an acceptable solution to support only GregorianCalendar. Masayoshi From xueming.shen at oracle.com Fri Dec 7 08:26:09 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 07 Dec 2012 08:26:09 -0800 Subject: [threeten-dev] some makefile and test update In-Reply-To: References: <50C0FD8F.9000604@oracle.com> <50C14A9D.40902@oracle.com> Message-ID: <50C218A1.6090507@oracle.com> On 12/7/12 4:04 AM, Stephen Colebourne wrote: > In my opinion, we should exclude those IDs that are pretty useless from TZDB > We use africa antarctica asia australasia backward etcetera europe > northamerica southamerica > We exclude solar and pacificnew. There will have to be there for compatibility, if the existing j.u.TimeZone is to migrate to use the threeten tzdb.jar (which is the plan for now). It's not a small deal to remove something from the jdk/jre, even if they are "useless" for almost everyone. It isn't for TimeZone->TonzId case, it's for TimeZone to still have the data for those "useless" zones. I can take them off for now, if you prefer, as we are not adding in the code to use tzdb.jar for TimeZone now. -Sherman > > There will be cases where you cannot convert a TimeZone to a ZoneId > anyway (such as user defined zones) so having some additional ones > doesn't seem like a big deal. A bit of a clear up is part of 310's > mission. > > Stephen > > > On 7 December 2012 01:47, Xueming Shen wrote: >> Any reason that can not be in? since the plan is to migrate the jdk existing >> tzdb code >> to use/share the tzdb.jar date, probaby vis StandardZoneRules (I did the >> prototype >> early this year). So the tzdb.jar will need all data jdk currently supports >> for compatibility >> reason. Though I'm not sure those solar files really matter or not. >> >> >> On 12/6/12 4:38 PM, Stephen Colebourne wrote: >> >> Looks like the TZDB generation includes solar files and maybe others that >> 310 was deliberately omitting. >> Stephen >> >> On Dec 6, 2012 8:18 PM, "Xueming Shen" wrote: >>> This is proposed changeset is to >>> >>> (1) move the tzdb "build" stuff from the make/tool/tzcompiler + >>> make/sun/javazic >>> into make/javax/time/Makefile. For two reason >>> - make the new build infra" stuff to work >>> -the tzdb.jar actually has the dependency on those zone impl, so it's >>> more >>> reasonable to update the tzdb.jar if those imples updated. >>> >>> (2) move the TestNG def from the top test properties file >>> TEST.ROOT into the "local" test/javax/time/TEST.properties. >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test >>> >>> -Sherman >> From xueming.shen at oracle.com Fri Dec 7 08:42:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 07 Dec 2012 08:42:13 -0800 Subject: [threeten-dev] [threeten-develop] j.u.Formatter In-Reply-To: References: <50C1A7BA.6080100@oracle.com> Message-ID: <50C21C65.7040707@oracle.com> On 12/7/12 4:33 AM, Stephen Colebourne wrote: > On 7 December 2012 08:24, Xueming Shen wrote: >> Here is the webrev for the change of adding the support of jsr310 new >> date/time >> in j.u.Formatter. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/ > You have manual manipulation of ChronoField.HOUR_OF_DAY, when you should use > ChronoField.HOUR_OF_AM_PM, ChronoField.CLOCK_HOUR_OF_AM_PM and , > ChronoField.CLOCK_HOUR_OF_DAY > >> Here is the result of the Test310 >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/result >> >> The current proposal/impl does not use the default timezone for Instant. >> Different compared to what j.u.Formatter does for "long" and j.u.Date. > That seems reasonable. The default time-zone is generally troublesome. > >> I'm not so sure about if the "GMT" should be added to the fixed offset >> for "Z". Any opinion? > I think we should not output "GMTZ", but we do accept it in parsing. > >> Stephen, it appears the ODT/OD/OT might want to return the ZoneOffset >> when queried by Query.ZONE_ID, given ZoneOffset is a ZoneId now. > Your changes to OD/OT/ODT are certinaly questionable. The idea of the > ZONE_ID query was to return the "concept" of zone, not anything that > implements ZoneId. However, this may be too strong for users. One This "idea" definitely is not specified in the spec of Query.ZONE_ID, in which is specified to query for a ZoneId object from the datetime. ZoneOffset is not anything "implements" ZoneId, it extends ZoneId now, which means it is a ZoneId object. Given current spec it is actually a bug, if ODT/OD/OT fails to return the ZoneOffset when queried by ZONE_ID. The spec of Query.ZONE_ID appears to have a type, it says "...must return the chronology" now. -Sherman > option may be a new query of ZONE_OR_OFFSET which can cross-convert an > offset if it doesn't find a zone. > > Note that ZDT.query(ZONE_ID) can return a ZoneOffset because that is > stored in the conceptual zone instance variable as returned by > getZone(). Whereas ODT does not have a getZone() method, thus ZONE_ID > was intended to return null. > > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > 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 Dec 7 10:23:54 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 07 Dec 2012 10:23:54 -0800 Subject: [threeten-dev] [threeten-develop] j.u.Formatter In-Reply-To: <50C21C65.7040707@oracle.com> References: <50C1A7BA.6080100@oracle.com> <50C21C65.7040707@oracle.com> Message-ID: <50C2343A.3040105@oracle.com> On 12/07/2012 08:42 AM, Xueming Shen wrote: > On 12/7/12 4:33 AM, Stephen Colebourne wrote: >> On 7 December 2012 08:24, Xueming Shen wrote: >>> Here is the webrev for the change of adding the support of jsr310 new >>> date/time >>> in j.u.Formatter. >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/ >> You have manual manipulation of ChronoField.HOUR_OF_DAY, when you should use >> ChronoField.HOUR_OF_AM_PM, ChronoField.CLOCK_HOUR_OF_AM_PM and , >> ChronoField.CLOCK_HOUR_OF_DAY >> We only need ChronoField.HOUR_OF_DAY and ChronoField.CLOCK_HOUR_OF_AMPM here. I have updated the webrev for ths, and separated 4. http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/test/java/util/Formatter/Test310.java.html For Query.ZONE_ID on ODT/OD/OT, if we don't have a consensus here, I can hardcode in j.u.Formatter for now to query Query.OfFSET for these three. Thanks! -Sherman From xueming.shen at oracle.com Fri Dec 7 10:45:38 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 07 Dec 2012 10:45:38 -0800 Subject: [threeten-dev] some makefile and test update In-Reply-To: <50C218A1.6090507@oracle.com> References: <50C0FD8F.9000604@oracle.com> <50C14A9D.40902@oracle.com> <50C218A1.6090507@oracle.com> Message-ID: <50C23952.1020202@oracle.com> To avoid blocking the progress. I have updated the changeset to only build the threeten specific zones for now. Will figure out the best approach later when we migrate the j.u.TimeZone data. -Sherman On 12/07/2012 08:26 AM, Xueming Shen wrote: > On 12/7/12 4:04 AM, Stephen Colebourne wrote: >> In my opinion, we should exclude those IDs that are pretty useless from TZDB >> We use africa antarctica asia australasia backward etcetera europe >> northamerica southamerica >> We exclude solar and pacificnew. > > There will have to be there for compatibility, if the existing j.u.TimeZone is to > migrate to use the threeten tzdb.jar (which is the plan for now). It's not a small > deal to remove something from the jdk/jre, even if they are "useless" for almost > everyone. It isn't for TimeZone->TonzId case, it's for TimeZone to still have the > data for those "useless" zones. I can take them off for now, if you prefer, as we > are not adding in the code to use tzdb.jar for TimeZone now. > > -Sherman > >> >> There will be cases where you cannot convert a TimeZone to a ZoneId >> anyway (such as user defined zones) so having some additional ones >> doesn't seem like a big deal. A bit of a clear up is part of 310's >> mission. >> >> Stephen >> >> >> On 7 December 2012 01:47, Xueming Shen wrote: >>> Any reason that can not be in? since the plan is to migrate the jdk existing >>> tzdb code >>> to use/share the tzdb.jar date, probaby vis StandardZoneRules (I did the >>> prototype >>> early this year). So the tzdb.jar will need all data jdk currently supports >>> for compatibility >>> reason. Though I'm not sure those solar files really matter or not. >>> >>> >>> On 12/6/12 4:38 PM, Stephen Colebourne wrote: >>> >>> Looks like the TZDB generation includes solar files and maybe others that >>> 310 was deliberately omitting. >>> Stephen >>> >>> On Dec 6, 2012 8:18 PM, "Xueming Shen" wrote: >>>> This is proposed changeset is to >>>> >>>> (1) move the tzdb "build" stuff from the make/tool/tzcompiler + >>>> make/sun/javazic >>>> into make/javax/time/Makefile. For two reason >>>> - make the new build infra" stuff to work >>>> -the tzdb.jar actually has the dependency on those zone impl, so it's >>>> more >>>> reasonable to update the tzdb.jar if those imples updated. >>>> >>>> (2) move the TestNG def from the top test properties file >>>> TEST.ROOT into the "local" test/javax/time/TEST.properties. >>>> >>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbbuild_test >>>> >>>> -Sherman >>> > From xueming.shen at oracle.com Fri Dec 7 10:55:37 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 07 Dec 2012 18:55:37 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Moved tzdb.jar build into mke/javax/time/Makefile Message-ID: <20121207185549.E52ED47FBE@hg.openjdk.java.net> Changeset: 63cc7e1f2df6 Author: sherman Date: 2012-12-07 10:56 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/63cc7e1f2df6 Moved tzdb.jar build into mke/javax/time/Makefile Moved TestNG.dirs properties into local test/javax/time/TEST.properties ! make/javax/time/Makefile ! make/sun/javazic/Makefile ! make/tools/Makefile ! src/share/classes/javax/time/zone/TzdbZoneRulesProvider.java ! test/TEST.ROOT + test/javax/time/TEST.properties From xueming.shen at oracle.com Fri Dec 7 10:57:26 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 07 Dec 2012 18:57:26 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Removed make/tools/tzcompiler/Makefile Message-ID: <20121207185737.CE0C647FBF@hg.openjdk.java.net> Changeset: 8794035ebdc3 Author: sherman Date: 2012-12-07 10:57 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8794035ebdc3 Removed make/tools/tzcompiler/Makefile - make/tools/tzcompiler/Makefile From roger.riggs at oracle.com Fri Dec 7 12:40:10 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 07 Dec 2012 20:40:10 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121207204044.DCCFA47FC5@hg.openjdk.java.net> Changeset: b2745080cf29 Author: rriggs Date: 2012-12-07 14:33 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b2745080cf29 Remove extraneous output from TestPeriodParser ! test/javax/time/test/javax/time/TestPeriodParser.java Changeset: 9c243fa7c187 Author: rriggs Date: 2012-12-07 15:31 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9c243fa7c187 updates to the ant script to enable command line override to supply tests to be run ! make/netbeans/threeten/build.xml From xueming.shen at oracle.com Sat Dec 8 00:02:37 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 08 Dec 2012 00:02:37 -0800 Subject: [threeten-dev] ZoneTextPrinterParser.print(...) Message-ID: <50C2F41D.5020102@oracle.com> Opinion? http://cr.openjdk.java.net/~sherman/jdk8_threeten/ztext_printer Naoto "promised" to have the cache mechanism somewhere in resource handling place, so the "cache" will be gone. The test take 14s+ on my old linux machine, but consider it's a 160 locales x 569 timezones x 100 run, it probably is not too bad. It may not be necessary to go over all them... The test failed on "ROC" and "Etc/GMT", it appears TimeZone is doing something special for these zones. I'm excluding them out for now. -Sherman From scolebourne at joda.org Sat Dec 8 01:50:19 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 8 Dec 2012 09:50:19 +0000 Subject: [threeten-dev] ZoneTextPrinterParser.print(...) In-Reply-To: <50C2F41D.5020102@oracle.com> References: <50C2F41D.5020102@oracle.com> Message-ID: On 8 December 2012 08:02, Xueming Shen wrote: > Opinion? > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/ztext_printer To obtain the instant from the DateTimeAccessor I would do this: Instant.from(accessor) rather than specifically looking for the two types. I'm not sure I would bother with the Type enum. Would an int suffice here? If the enum is kept, I'd use upper case constant names. Stephen > Naoto "promised" to have the cache mechanism somewhere in resource handling > place, so the "cache" will be gone. > > The test take 14s+ on my old linux machine, but consider it's a > 160 locales x 569 timezones x 100 run, it probably is not too bad. It may > not be > necessary to go over all them... > > The test failed on "ROC" and "Etc/GMT", it appears TimeZone is doing > something special > for these zones. I'm excluding them out for now. > > -Sherman From xueming.shen at oracle.com Sat Dec 8 11:13:01 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 08 Dec 2012 11:13:01 -0800 Subject: [threeten-dev] ZoneTextPrinterParser.print(...) In-Reply-To: References: <50C2F41D.5020102@oracle.com> Message-ID: <50C3913D.1090404@oracle.com> On 12/8/12 1:50 AM, Stephen Colebourne wrote: > On 8 December 2012 08:02, Xueming Shen wrote: >> Opinion? >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ztext_printer > To obtain the instant from the DateTimeAccessor I would do this: > Instant.from(accessor) > rather than specifically looking for the two types. Good point. webrev has been updated as suggested (also changed the enum to int). I also updated the j.u.formatter as well. How is the ZoneOffset & ZoneId conclusion? It's good to do as well? :-) http://cr.openjdk.java.net/~sherman/jdk8_threeten/juf/ -Sherman > > I'm not sure I would bother with the Type enum. Would an int suffice > here? If the enum is kept, I'd use upper case constant names. > > Stephen > >> Naoto "promised" to have the cache mechanism somewhere in resource handling >> place, so the "cache" will be gone. >> >> The test take 14s+ on my old linux machine, but consider it's a >> 160 locales x 569 timezones x 100 run, it probably is not too bad. It may >> not be >> necessary to go over all them... >> >> The test failed on "ROC" and "Etc/GMT", it appears TimeZone is doing >> something special >> for these zones. I'm excluding them out for now. >> >> -Sherman From Roger.Riggs at oracle.com Mon Dec 10 08:55:11 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2012 11:55:11 -0500 Subject: [threeten-dev] Webrev for updates to WeekDefinition Message-ID: <50C613EF.3000907@oracle.com> Hi, Changes to address Issue #67 Implement Week Rules is proposed in this webrev. http://cr.openjdk.java.net/~rriggs/weekdef-webrev/ Comments? -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Mon Dec 10 10:38:06 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 10 Dec 2012 10:38:06 -0800 Subject: [threeten-dev] Fwd: Re: [threeten-develop] j.u.Formatter Message-ID: <50C62C0E.7080005@oracle.com> -------- Original Message -------- Message-ID: <50C62BCF.6040004 at oracle.com> Date: Mon, 10 Dec 2012 10:37:03 -0800 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: threeten-develop at lists.sourceforge.net Subject: Re: [threeten-develop] [threeten-dev] j.u.Formatter References: <50C1A7BA.6080100 at oracle.com> <50C21C65.7040707 at oracle.com> <50C2343A.3040105 at oracle.com> In-Reply-To: <50C2343A.3040105 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It appears we don't have an agreement on whether or not ODT/OD/OT should respond to Query.ZONE_ID. I updated the j.u.Formatter to hardcode the case of ODT/OD/OT. And I also move the test case into test/javax/time/test to make the test run easier (excluded from the build.xml though) http://cr.openjdk.java.net/~sherman/jdk8_threeten/juf/ -Sherman On 12/07/2012 10:23 AM, Xueming Shen wrote: > On 12/07/2012 08:42 AM, Xueming Shen wrote: >> On 12/7/12 4:33 AM, Stephen Colebourne wrote: >>> On 7 December 2012 08:24, Xueming Shen wrote: >>>> Here is the webrev for the change of adding the support of jsr310 new >>>> date/time >>>> in j.u.Formatter. >>>> >>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/ >>> You have manual manipulation of ChronoField.HOUR_OF_DAY, when you should use >>> ChronoField.HOUR_OF_AM_PM, ChronoField.CLOCK_HOUR_OF_AM_PM and , >>> ChronoField.CLOCK_HOUR_OF_DAY >>> > We only need ChronoField.HOUR_OF_DAY and ChronoField.CLOCK_HOUR_OF_AMPM > here. I have updated the webrev for ths, and separated 4. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/test/java/util/Formatter/Test310.java.html > > For Query.ZONE_ID on ODT/OD/OT, if we don't have a consensus here, I can hardcode in > j.u.Formatter for now to query Query.OfFSET for these three. > > Thanks! > -Sherman > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > 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 Dec 10 13:59:57 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 10 Dec 2012 16:59:57 -0500 Subject: [threeten-dev] [threeten-develop] Webrev for updates to WeekDefinition In-Reply-To: References: <50C613EF.3000907@oracle.com> Message-ID: <50C65B5D.10604@oracle.com> Thanks for the comments: The webrev has been updated. On 12/10/2012 12:22 PM, Stephen Colebourne wrote: > The Javadoc for dayofWeek() should describe the numering scheme (ie 1 > to 7, not 0 to 6). ok > > The javadoc for week methods has "Week one(1)" but there should be an > extra space "Week one (1)" to match the week zero comment. ok > > I would put a dashed line before the start of the class ;-) ok > > The doIsSupported() method is incomplete for the week fields. It > should only return true if the data each week field relies on is > available. ok, DOW only requires ISO DOW, weekOfMonth requires ISO DOW and Month, weekOfYear requires ISO DOW and year. > > Line 410, the range constants should be upper case. ok > > The doRange() method is not implemented. For the week methods it > should work out the actual range based on the month/year. what a pain for little gain, but can be computed from range of the base field (month or year). > > Not sure how the code handles the case of day-of-week and > week-of-month/year with different week definitions. Should merging > only happen in resolve() if they have the same week definition? The > standard ISO day-of-week should always work, but not sure about mixing > week definitions. Not a problem, the computation for dayOfWeek is based on ISO week and the WeekDefinition of either weekOfMonth or weekOfYear respectively. If fields from two different WeekDefinitions are attempted to be resolved they will conflict in that both will try to define the day of month or year. > > I've realised that the toString() on the field should include the > toString() of the week definition. This is because otherwise > developers will get confused combining day-of-week and week-of-month > with different week definitions. ok > > Line 474 comment looks wrong. updated, Thanks, Roger > > Stephen > > > On 10 December 2012 16:55, Roger Riggs > wrote: > > Hi, > > Changes to address Issue #67 Implement Week Rules > is proposed in > this webrev. > > http://cr.openjdk.java.net/~rriggs/weekdef-webrev/ > > > Comments? > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is > committed to developing practices and products that help protect > the environment > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add > services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From scolebourne at joda.org Mon Dec 10 16:11:23 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 00:11:23 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets Message-ID: <20121211001303.3AACC4702A@hg.openjdk.java.net> Changeset: 9453fdb3106e Author: scolebourne Date: 2012-12-10 23:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9453fdb3106e Add default method to DateTimeField ! src/share/classes/javax/time/calendrical/ChronoField.java ! src/share/classes/javax/time/calendrical/DateTimeField.java ! src/share/classes/javax/time/calendrical/ISOWeeks.java ! src/share/classes/javax/time/calendrical/JulianDayField.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java ! test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java Changeset: 0ebf84c00729 Author: scolebourne Date: 2012-12-10 23:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0ebf84c00729 Add default methods to ZoneRules ! src/share/classes/javax/time/zone/StandardZoneRules.java ! src/share/classes/javax/time/zone/ZoneRules.java Changeset: 47a03718d4e7 Author: scolebourne Date: 2012-12-10 23:43 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/47a03718d4e7 Document descriptions of default methods Also alter semantics of mutable implementations ! src/share/classes/javax/time/calendrical/DateTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java Changeset: cf8289b214a9 Author: scolebourne Date: 2012-12-10 23:44 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cf8289b214a9 Merge - make/tools/tzcompiler/Makefile Changeset: ac9d0bd41c88 Author: scolebourne Date: 2012-12-11 00:08 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ac9d0bd41c88 Add default methods to ChronoUnit ! src/share/classes/javax/time/calendrical/ChronoUnit.java ! src/share/classes/javax/time/calendrical/PeriodUnit.java Changeset: 098aa0f884f3 Author: scolebourne Date: 2012-12-11 00:09 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/098aa0f884f3 Document default methods ! src/share/classes/javax/time/calendrical/ChronoField.java ! src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTime.java ! src/share/classes/javax/time/chrono/Era.java From xueming.shen at oracle.com Mon Dec 10 18:31:58 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 11 Dec 2012 02:31:58 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added the threeten date/time type support in j.u.Formatter Message-ID: <20121211023233.925C147034@hg.openjdk.java.net> Changeset: 373c0c3a9ff5 Author: sherman Date: 2012-12-10 18:33 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/373c0c3a9ff5 Added the threeten date/time type support in j.u.Formatter ! make/netbeans/threeten/build.xml ! src/share/classes/java/util/Formatter.java + test/javax/time/test/java/util/TestFormatter.java From xueming.shen at oracle.com Mon Dec 10 22:19:58 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 10 Dec 2012 22:19:58 -0800 Subject: [threeten-dev] ZoneIdPrinterParser.parser and SubstringTree Message-ID: <50C6D08E.9030503@oracle.com> Stephen, SubstringTree + zid parsing code currently only works with the case that the ZondID is the last piece of the input text (I added back the TestZoneIdParser with a new startMatch). It appears there are at least two issues here. (1) L#2574, the last matched zoneid will get lost if there are more chars in the input, which will fail the last try tree.get(...). (2) There are two possible reasons tree.get(...) returns null. A mismatch OR the end of the branch reached (longest zid found, no more try). Here is the webrev to fix them. I also change the substringMap to only be initialized (create the HashMap) if needed. My test suggests only less than 40 out of 500+ nodes (from current zid list) are parent node that really needs a HashaMap. This might not be a big issue given the the zid is mostly likely a one-time initialization. But we will probably use this for the ZoneText parser as well, in which there will be one for each locale, each style... http://cr.openjdk.java.net/~sherman/jdk8_threeten/zid_parser -Sherman From scolebourne at joda.org Tue Dec 11 00:29:30 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 11 Dec 2012 08:29:30 +0000 Subject: [threeten-dev] ZoneIdPrinterParser.parser and SubstringTree In-Reply-To: <50C6D08E.9030503@oracle.com> References: <50C6D08E.9030503@oracle.com> Message-ID: On 11 December 2012 06:19, Xueming Shen wrote: > SubstringTree + zid parsing code currently only works with the case that the > ZondID is > the last piece of the input text (I added back the TestZoneIdParser with a > new startMatch). I have a memory that the last time I looked at this it didn't seem quite right. Thanks for fixing and for the optimisation. Patch looks OK. Stephen > It appears there are at least two issues here. > > (1) L#2574, the last matched zoneid will get lost if there are more chars in > the input, which > will fail the last try tree.get(...). > > (2) There are two possible reasons tree.get(...) returns null. A mismatch OR > the end of the branch > reached (longest zid found, no more try). > > Here is the webrev to fix them. I also change the substringMap to only be > initialized (create > the HashMap) if needed. My test suggests only less than 40 out of 500+ nodes > (from current > zid list) are parent node that really needs a HashaMap. This might not be a > big issue given the > the zid is mostly likely a one-time initialization. But we will probably use > this for the ZoneText > parser as well, in which there will be one for each locale, each style... > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/zid_parser > > -Sherman > > From scolebourne at joda.org Tue Dec 11 02:50:03 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 10:50:03 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121211105107.42CEC4704D@hg.openjdk.java.net> Changeset: 91b6e0615e67 Author: scolebourne Date: 2012-12-11 09:27 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/91b6e0615e67 Rename LocalTime.MIDDAY to NOON Name is clearer, and less confusing in IDEs ! src/share/classes/javax/time/LocalTime.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestLocalTime.java Changeset: c8bcbd13ed88 Author: scolebourne Date: 2012-12-11 10:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c8bcbd13ed88 Enhance from(DateTimeAccessor), Javadoc and LocalTime implementation ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/ZoneOffset.java Changeset: f4f646c88ec9 Author: scolebourne Date: 2012-12-11 10:49 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f4f646c88ec9 Add suppress warnings ! src/share/classes/javax/time/calendrical/ChronoField.java ! src/share/classes/javax/time/calendrical/ChronoUnit.java From Roger.Riggs at oracle.com Tue Dec 11 06:04:14 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2012 09:04:14 -0500 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets In-Reply-To: <20121211001303.3AACC4702A@hg.openjdk.java.net> References: <20121211001303.3AACC4702A@hg.openjdk.java.net> Message-ID: <50C73D5E.7060606@oracle.com> Hi Stephen, Catching RuntimeException in PeriodUnit.isSupported seems like an overly broad catchall; Can it be narrowed to DateTimeException? Roger On 12/10/2012 7:11 PM, scolebourne at joda.org wrote: > > Changeset: ac9d0bd41c88 > Author: scolebourne > Date: 2012-12-11 00:08 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ac9d0bd41c88 > > Add default methods to ChronoUnit > > ! src/share/classes/javax/time/calendrical/ChronoUnit.java > ! src/share/classes/javax/time/calendrical/PeriodUnit.java > > > From roger.riggs at oracle.com Tue Dec 11 07:28:57 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 11 Dec 2012 15:28:57 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20121211153012.A895E47060@hg.openjdk.java.net> Changeset: b44f5a7a2f29 Author: rriggs Date: 2012-12-10 11:43 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b44f5a7a2f29 Implement fields for WeekDefinition DayOfWeek, WeekOfMonth, WeekOfYear; Add tests for WeekDefinition and for consistency of calendars with java.util.Calendars ! src/share/classes/javax/time/calendrical/WeekDefinition.java + test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java + test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java + test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java + test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java Changeset: 597307a4b018 Author: rriggs Date: 2012-12-10 16:55 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/597307a4b018 WeekDefinition implement doRange, javadoc clarification of day numbering, create computed fields curing construction; added test for ranges on the computed fields ! src/share/classes/javax/time/calendrical/WeekDefinition.java ! test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java Changeset: beb82f9c0b9e Author: rriggs Date: 2012-12-11 10:16 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/beb82f9c0b9e Merge Changeset: b9e54f68bc05 Author: rriggs Date: 2012-12-11 10:25 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b9e54f68bc05 Fix javadoc broken links to global calendars, Adjuster ! src/share/classes/javax/time/ZoneDateTime.java ! src/share/classes/javax/time/calendrical/WeekDefinition.java ! src/share/classes/javax/time/chrono/package.html From scolebourne at joda.org Tue Dec 11 07:33:28 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 15:33:28 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 7 new changesets Message-ID: <20121211153448.0F64547061@hg.openjdk.java.net> Changeset: 6874e2679220 Author: scolebourne Date: 2012-12-11 11:45 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6874e2679220 Additional tests for date comparator ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java Changeset: 75e16a5beb23 Author: scolebourne Date: 2012-12-11 12:05 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/75e16a5beb23 Javadoc ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java Changeset: 64d60b87c2dc Author: scolebourne Date: 2012-12-11 12:18 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/64d60b87c2dc Fix text output ! src/share/classes/javax/time/chrono/Chrono.java Changeset: e9fdb7a1c953 Author: scolebourne Date: 2012-12-11 12:18 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e9fdb7a1c953 Fix ZoneId getText() to call formatter ! src/share/classes/javax/time/ZoneId.java Changeset: 5fcde84b89ec Author: scolebourne Date: 2012-12-11 13:31 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5fcde84b89ec Remove withTime() methods ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZoneDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKZoneDateTime.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java Changeset: b04014bf13d9 Author: scolebourne Date: 2012-12-11 15:22 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b04014bf13d9 Add truncatedTo(PeriodUnit) Fixes #41 ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/ZoneDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneDateTime.java Changeset: 51e8c0e8f33d Author: scolebourne Date: 2012-12-11 15:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/51e8c0e8f33d Merge ! src/share/classes/javax/time/ZoneDateTime.java From scolebourne at joda.org Tue Dec 11 07:40:51 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 15:40:51 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Enhance formatter based on feedback Message-ID: <20121211154104.3A6B047063@hg.openjdk.java.net> Changeset: ae27443e609e Author: scolebourne Date: 2012-12-11 15:40 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ae27443e609e Enhance formatter based on feedback ! src/share/classes/javax/time/format/DateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java From Roger.Riggs at oracle.com Tue Dec 11 08:08:28 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Dec 2012 11:08:28 -0500 Subject: [threeten-dev] hg: threeten/threeten/jdk: Enhance formatter based on feedback In-Reply-To: <20121211154104.3A6B047063@hg.openjdk.java.net> References: <20121211154104.3A6B047063@hg.openjdk.java.net> Message-ID: <50C75A7C.7010008@oracle.com> Hi Stephen, A bit more expansive comment would be appreciated to understand which feedback and the nature of the improvement. Including something that would distinguish this commit from another commit. Thanks, Roger On 12/11/2012 10:40 AM, scolebourne at joda.org wrote: > Changeset: ae27443e609e > Author: scolebourne > Date: 2012-12-11 15:40 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ae27443e609e > > Enhance formatter based on feedback > > ! src/share/classes/javax/time/format/DateTimeFormatter.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Dec 11 08:26:05 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 11 Dec 2012 16:26:05 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fixed ZoneIdParserPrinter Message-ID: <20121211162626.AB5E447066@hg.openjdk.java.net> Changeset: 010722066876 Author: sherman Date: 2012-12-11 08:24 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/010722066876 Fixed ZoneIdParserPrinter ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java From scolebourne at joda.org Tue Dec 11 10:33:25 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 18:33:25 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 10 new changesets Message-ID: <20121211183534.D6CA247074@hg.openjdk.java.net> Changeset: 4b71ae61b5bd Author: scolebourne Date: 2012-12-11 16:48 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4b71ae61b5bd Add ofInstant() to LocalDateTime See #44 ! src/share/classes/javax/time/LocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java Changeset: a649f778da41 Author: scolebourne Date: 2012-12-11 17:01 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a649f778da41 Add MAX/MIN constants for Instant ! src/share/classes/javax/time/Instant.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/test/javax/time/TestInstant.java Changeset: 59bf70880cba Author: scolebourne Date: 2012-12-11 17:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/59bf70880cba Add MIN/MAX constants to ZoneOffset ! src/share/classes/javax/time/ZoneOffset.java ! test/javax/time/tck/javax/time/TCKZoneDateTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java Changeset: e318931c1156 Author: scolebourne Date: 2012-12-11 17:20 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e318931c1156 Remove ofEpochSecond() factories on ZDT/ODT. Methods were intended for advanced use cases. Can use factories on LDT/Instant instead. ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZoneDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKZoneDateTime.java Changeset: 6cd088028dae Author: scolebourne Date: 2012-12-11 17:28 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6cd088028dae Consistently use zone rather than zoneId ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTime.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java Changeset: e951160d841c Author: scolebourne Date: 2012-12-11 18:08 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e951160d841c Make ensureXxx() methods package scoped. Fixup implementatons to use methods via defaulted interface. Fix Javadoc. ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/chrono/global/ChronoDateImpl.java ! src/share/classes/javax/time/chrono/global/HijrahDate.java ! src/share/classes/javax/time/chrono/global/JapaneseDate.java ! src/share/classes/javax/time/chrono/global/MinguoDate.java ! src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java Changeset: 5620bffe646c Author: scolebourne Date: 2012-12-11 18:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5620bffe646c Fix Javadoc ! src/share/classes/javax/time/zone/ZoneRules.java Changeset: 610864a41846 Author: scolebourne Date: 2012-12-11 18:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/610864a41846 Tweaks to overview Javadoc ! src/share/classes/javax/time/overview.html Changeset: 0e6eaa3b0146 Author: scolebourne Date: 2012-12-11 18:28 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e6eaa3b0146 Fix Javadoc ! src/share/classes/javax/time/calendrical/WeekDefinition.java Changeset: b6bfd75e65f0 Author: scolebourne Date: 2012-12-11 18:30 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b6bfd75e65f0 Merge From scolebourne at joda.org Tue Dec 11 10:41:21 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 18:41:21 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Remove fixedUTC() clock factory. Message-ID: <20121211184133.2D9694708D@hg.openjdk.java.net> Changeset: aad17e290d83 Author: scolebourne Date: 2012-12-11 18:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/aad17e290d83 Remove fixedUTC() clock factory. Special case here isn't justified. ! src/share/classes/javax/time/Clock.java ! test/javax/time/test/javax/time/TestClock_Fixed.java From scolebourne at joda.org Tue Dec 11 11:01:26 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 19:01:26 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Javadoc Message-ID: <20121211190147.9CED34708E@hg.openjdk.java.net> Changeset: 2c29f2f706d4 Author: scolebourne Date: 2012-12-11 19:01 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2c29f2f706d4 Javadoc ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/ZoneDateTime.java From scolebourne at joda.org Tue Dec 11 11:19:15 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 11 Dec 2012 19:19:15 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121211191945.A23744708F@hg.openjdk.java.net> Changeset: bd56a2246149 Author: scolebourne Date: 2012-12-11 19:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd56a2246149 Fix compile error from fixedUTC clock removal. ! test/javax/time/tck/javax/time/TCKClock_System.java ! test/javax/time/test/javax/time/TestInstant.java Changeset: 2d21508e95d8 Author: scolebourne Date: 2012-12-11 19:18 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2d21508e95d8 Rename nextOrCurrent() to nextOrSame() et al. Avoids use of "current" with connotations of now. Fixes #157 ! src/share/classes/javax/time/calendrical/DateTimeAdjusters.java ! src/share/classes/javax/time/calendrical/DateTimeBuilder.java ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java ! test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java From scolebourne at joda.org Wed Dec 12 00:33:17 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 12 Dec 2012 08:33:17 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121212083351.F38CC470B5@hg.openjdk.java.net> Changeset: 23c58a72b70e Author: scolebourne Date: 2012-12-11 20:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/23c58a72b70e Javadoc ! src/share/classes/javax/time/calendrical/package.html ! src/share/classes/javax/time/overview.html Changeset: e4cdd97e23d2 Author: scolebourne Date: 2012-12-11 22:36 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e4cdd97e23d2 Change from h4 to h5 for better Javadoc ! src/share/classes/javax/time/calendrical/DateTime.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java From scolebourne at joda.org Wed Dec 12 02:33:56 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 12 Dec 2012 10:33:56 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix Period.toString() Message-ID: <20121212103441.1214D470BA@hg.openjdk.java.net> Changeset: 45047f7a6e97 Author: scolebourne Date: 2012-12-12 10:33 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/45047f7a6e97 Fix Period.toString() Fixes #165 ! src/share/classes/javax/time/Period.java ! test/javax/time/test/javax/time/TestPeriod.java From Roger.Riggs at oracle.com Wed Dec 12 12:56:23 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2012 15:56:23 -0500 Subject: [threeten-dev] Package structure for Threeten in JDK Message-ID: <50C8EF77.5050409@oracle.com> Hi, After some discussion within Oracle and with the JDK architects and incorporating the discussion of issue#149 Design split between embedded core and general JDK I propose the following package structure for Threeten. * java.time - basic human and machine time (ISO) o Clock, Duration, Instant o LocalTime, LocalDate, LocalDateTime o ZonedDateTime, ZoneId, ZoneOffset o Period * java.time.chrono - the date-time framework and advanced functions o DateTime, DateTimeAccessor, DateTimeField, PeriodUnit o ChronoField, ChronoUnit, DateTimeValueRange o DateTimeAdjusters o Julian Day field o WeekDefinition, ISOWeeks o Chrono, ISOChrono, ChronoLocalDate, ChronoLocalDateTime, ChronoZoneDateTime, Era o YearMonth, MonthDay, Yea o OffsetTime, OffsetDateTime, OffsetDate * java.time.format - formatting * java.time.zone - timezone * java.time.global - global calendars o Japanese, ThaiBuddhist, Minguo, Hijrah All of the packages except java.time.global are tightly integrated and would form a module to be included with all Java Runtimes. The global calendars should be (a module) and decoupled from the base. For reference the current javadoc is: http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ Comments appreciated. Roger From Roger.Riggs at oracle.com Wed Dec 12 13:53:17 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Dec 2012 16:53:17 -0500 Subject: [threeten-dev] [threeten-develop] Zone or Zoned DateTime In-Reply-To: References: <50C0F1C6.3020203@oracle.com> <6.2.5.6.2.20121206124240.062f15d0@oracle.com> <6.2.5.6.2.20121210161700.06a4b5c8@oracle.com> <50C7A5E5.2050905@o2.pl> <6.2.5.6.2.20121211135413.04cc1770@oracle.com> <50C7C728.1050103@redhat.com> Message-ID: <50C8FCCD.4020002@oracle.com> Hi Stephen, The input we have so far is about 50-50 with good rational language based reasons for ZonedDateTime. It does matter to more than a few folks here at Oracle and I think we now agree on to use original spelling. Given the amount of flak we've taken for changing it/ allowing it to be changed, we need to revert this change to the previous spelling. If that's not the best use of your time, I can make the change. Roger On 12/12/2012 1:43 PM, Stephen Colebourne wrote: > Naming is always subjective. > > The original comment made me think about the issue and questioned my > previous naming. The change occurred because I felt it was the right > thing to do - its simpler, especially for non-English speakers. > > I'm not going to do a poll at this stage. In six months time, no-one > will care one way or another. > > Stephen > > > On 11 December 2012 23:52, David M. Lloyd wrote: >> Well, maybe use a real polling thing for it. >> >> There are other options too: >> >> - DateTimeWithTimeZone >> - DateTimeTimeZone >> - DateTimeZone >> - DateTimeWithZone >> - DateTimeAndZone >> >> On 12/11/2012 04:22 PM, Jesper Steen M?ller wrote: >>> Why not take a vote on it in a larger audience, like it has been done a few times earlier? >>> >>> A) ZonedDateTime - because 'zoned' is a participle adjective in the phrase "zoned date time": ZonedDateTime makes it clear that the zone modifies the DateTime, not the other way around. The other Zone classes are information of one form or another about time zones, e.g. ZoneId. >>> >>> B) ZoneDateTime - because ZoneDateTime means the Zone specialism of DateTime in standard Java class naming. That makes it an acceptable name here. It also matches the same prefix as other zone classes, which is a good thing. >>> >>> -Jesper >>> >>> On 11/12/2012, at 22.56, Douglas Surber wrote: >>> >>>> So maybe ten people thought Zoned was a typo and asked about it vs >>>> the thousand people who saw it and said nothing because it is >>>> correct. That's the problem with making decisions based on anecdote. >>>> You only notice the exceptional cases. >>>> >>>> Douglas >>>> >>>> >>>> At 01:30 PM 12/11/2012, Grzegorz Borkowski wrote: >>>>> Perhaps it was me who originally suggested this change (unless there >>>>> >>>>> were other voices too) - it was based on the observation that people >>>>> >>>>> seeing ZonedDateTime for the first time, used to ask "isn't there a >>>>> typo >>>>> in this name, shouldn't it be ZoneDateTime?". >>>>> So even if from the lexical point of view the ZonedDT is more >>>>> precise, I >>>>> think ZoneDT is just more practical. >>>>> >>>>> Greg >>>>> >>>>> W dniu 2012-12-11 01:21, Douglas Surber pisze: >>>>>> At 04:14 PM 12/10/2012, Stephen Colebourne wrote: >>>>>>> Ultimately, I made this change. >>>>>>> >>>>>>> ZoneDateTime means the Zone specialism of DateTime in standard >>>>> Java >>>>>>> class naming. That makes it an acceptable name here. It also >>>>> matches >>>>>>> the same prefix as other zone classes, which is a good thing. >>>>>> Except the other Zone classes are information of one form or >>>>> another >>>>>> about time zones. ZonedDateTime is a DateTime. The time zone >>>>>> information is about the DateTime; the DateTime is not >>>>> information >>>>>> about the time zone. I honestly think that the fact that "Zone" >>>>> is >>>>>> the same in both cases is a good argument against ZoneDateTime as >>>>> the >>>>>> uses are completely different. >>>>>> >>>>>> This is another case where code that has been the same for years >>>>> and >>>>>> been reviewed by hundreds or thousands of people without >>>>> complaint is >>>>>> changed at the very last second for no good reason. >>>>>> >>>>>> Douglas >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>>> Remotely access PCs and mobile devices and provide instant support >>>>> Improve your efficiency, and focus on delivering more value-add >>>>> services >>>>> Discover what IT Professionals Know. Rescue delivers >>>>> http://p.sf.net/sfu/logmein_12329d2d >>>>> _______________________________________________ >>>>> threeten-develop mailing list >>>>> threeten-develop at lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>>> >>>> ------------------------------------------------------------------------------ >>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>> Remotely access PCs and mobile devices and provide instant support >>>> Improve your efficiency, and focus on delivering more value-add services >>>> Discover what IT Professionals Know. Rescue delivers >>>> http://p.sf.net/sfu/logmein_12329d2d >>>> _______________________________________________ >>>> threeten-develop mailing list >>>> threeten-develop at lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >> >> -- >> - DML >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From scolebourne at joda.org Wed Dec 12 15:01:44 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Dec 2012 23:01:44 +0000 Subject: [threeten-dev] Opinion poll on Zone[d]DateTime Message-ID: It seems like a poll is necessary for ZoneDateTime vs ZonedDateTime: http://www.rationalsurvey.com/s/6916 Please note, that I will not necessarily follow the results of the poll, but it will be a good data point. Please distribute this to those you know. thanks Stephen From scolebourne at joda.org Wed Dec 12 16:09:29 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 13 Dec 2012 00:09:29 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121213000952.A3DEF470F1@hg.openjdk.java.net> Changeset: 72ad90d9ed16 Author: scolebourne Date: 2012-12-12 21:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72ad90d9ed16 Clearer Query Javadoc ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java Changeset: 2c3f26801b37 Author: scolebourne Date: 2012-12-13 00:05 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2c3f26801b37 Add ZONE query Fixes #162 ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/calendrical/DateTimeBuilder.java ! src/share/classes/javax/time/chrono/ChronoZoneDateTime.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneDateTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/test/javax/time/TestZoneId.java From xueming.shen at oracle.com Wed Dec 12 22:02:09 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 13 Dec 2012 06:02:09 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added ZoneTextPrinter Message-ID: <20121213060231.E23F9470FB@hg.openjdk.java.net> Changeset: 422eef00ffbc Author: sherman Date: 2012-12-12 22:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/422eef00ffbc Added ZoneTextPrinter ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java + test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java From xueming.shen at oracle.com Wed Dec 12 22:21:57 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 12 Dec 2012 22:21:57 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added ZoneTextPrinter In-Reply-To: <20121213060231.E23F9470FB@hg.openjdk.java.net> References: <20121213060231.E23F9470FB@hg.openjdk.java.net> Message-ID: <50C97405.2050607@oracle.com> This changeset probably breaks the environment that does not build a full jdk, because the javac appears to not recognize sun.util.locale.provider.TimeZonezNameUtility, yet. Probably because it's a "new" sun package, so it's not in the "cached" symbol table yet. As a workaround, you can either use the "TimeZone' workaround (commented out in the source code) or trick the build.xml to add line like into the "main.path" def and then copy the latest rt.jar into /tmp. This should trick the javac to compile the DateTimeFormatterBuilder. One of the goals of this changeset is to encourage you to start to build a full jdk:-) Feel free to push the TimeZone approach as the default for now. But that will not give you the timezone generic name, which will come in soon:-) Btw, it really took me A hour to figure out why my zid test failed due to a "FooLocation" zid, which seems come from nowhere. We really should not test the provider at the same vm. -Sherman On 12/12/12 10:02 PM, xueming.shen at oracle.com wrote: > Changeset: 422eef00ffbc > Author: sherman > Date: 2012-12-12 22:04 -0800 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/422eef00ffbc > > Added ZoneTextPrinter > > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > + test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java > From Roger.Riggs at oracle.com Thu Dec 13 07:08:49 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 10:08:49 -0500 Subject: [threeten-dev] [threeten-develop] Package structure for Threeten in JDK In-Reply-To: <50C906AC.3050602@christopherschultz.net> References: <50C8EF77.5050409@oracle.com> <50C906AC.3050602@christopherschultz.net> Message-ID: <50C9EF81.6060102@oracle.com> Hi Chris, It is refreshing to get comprehensive comments with a fresh point of view. We've been looking at this API for so long it all seems very familiar. By way of explanation, some comments below. On 12/12/2012 5:35 PM, Christopher Schultz wrote: > Roger, > > On 12/12/12 3:56 PM, Roger Riggs wrote: >> After some discussion within Oracle and with the JDK architects and >> incorporating >> the discussion of issue#149 Design split between embedded core and >> general JDK >> I propose the following package structure for Threeten. >> >> * java.time - basic human and machine time (ISO) >> o Clock, Duration, Instant >> o LocalTime, LocalDate, LocalDateTime >> o ZonedDateTime, ZoneId, ZoneOffset >> o Period > So, these are the "basics". When someone asks me "so, what am I supposed > to use, now, instead of Date or Calendar", what do I say? > > Just from the names shown above, it's totally unclear even which one to > look at, first. The names Clock, Instant, Local*, and ZonedDateTime all > seem plausible. > > I realize one of the aims of this API is to finally get a clean > separation between the simple notion of time (e.g. a number that > represents True Time) and all the cultural and political ideas that > confuse everyone (time zones, DST, etc.) and so there is no true > "replacement" for java.util.Date (which handles time zone offset but not > in a manageable way, no DST support) or java.util.Calendar (which > handles time zone via TimeZone *and/or* zone offset and DST via offset > and possible TimeZone). But, there should be at least one class that you > can point to and say "start there", and its name shouldn't be totally > off the wall. If there were just one it would be ZonedDateTime but one of the problems with the current Calendar is that a single type does a bad job of handling the different needs of developer. So, depending on the use case the developer might choose better from LocalTime, LocalDate, LocalDateTime, etc. That will need to be part of the documentation and education about the DateTime API and taken into account on the learning curve. The basic APIs have concrete types with methods to access and manipulate the values that are easy to use and easy to program. > >> * java.time.chrono - the date-time framework and advanced functions >> o DateTime, DateTimeAccessor, DateTimeField, PeriodUnit > So, ZonedDateTime is a "basic" class but "DateTime" is an "advanced" > interface? Just the naming makes it seem like DateTime is the base class > and ZonedDateTime adds something to it... that would seem to imply that > DateTime is more basic than ZonedDateTime, yet the packages they are in > are opposite to that implication. DateTime being an interface was -- > honestly -- a surprise to me even when I got to the end of this message > and had to go back to adjust this comment. I had thought it was a class > the whole time. I guess I just like my interfaces to be adjectives. Because the Threeten API has different types to properly handle multiple kinds of time and date data, there needed to be a common interface that provides access to any of the types. That has gone through many iterations of function and naming but DateTime seemed like best name for its inclusive nature. BTW, DateTime by itself would not convey any information about whether it had a timezone or what calendar it was part of, etc. From that perspective it is too generic to represent a concrete type. > >> o ChronoField, ChronoUnit, DateTimeValueRange >> o DateTimeAdjusters >> o Julian Day field >> o WeekDefinition, ISOWeeks >> o Chrono, ISOChrono, ChronoLocalDate, ChronoLocalDateTime, >> ChronoZoneDateTime, Era >> o YearMonth, MonthDay, Yea >> o OffsetTime, OffsetDateTime, OffsetDate >> * java.time.format - formatting >> * java.time.zone - timezone >> * java.time.global - global calendars >> o Japanese, ThaiBuddhist, Minguo, Hijrah >> >> All of the packages except java.time.global are tightly integrated and >> would form a module to be included with all Java Runtimes. >> The global calendars should be (a module) and decoupled from the base. >> >> For reference the current javadoc is: >> http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ > I have to admit that I've been neither following every discussion nor > participating in everything but that does give me a somewhat fresh > perspective -- one that 99% of Java developers are going to have when > seeing this for the first time. > > I've been reading the API Javadoc and I have to say that I'm dumbfounded > by my initial overview. A comment by a friend and long-time Java > programmer was "Waa? This whole thing seems intentionally ill-conceived. > Did some deep-Python lovers infiltrate the working group to scuttle the > project?". I'll leave the history to Stephen, I've only be at this for a year. > > Some specifics -- and I've only looked in java.time and not the > sub-packages, yet. > > Clock: creates Clock objects. Great. What can they do? They can produce > other Clock objects -- ones in different time zones. Why? Well, to > produce Instants, of course. So, Instants have time zones? Sadly, no. > > Instant: okay, I get this one: it's a point on a universal time line. > There is a total ordering of these things across all of time. What can > you do with an Instant? Well, one of the (alphabetically) first things > you can do is "doWithAdjustment(DateTime). Do /what/ with adjustment? > The javadoc description is nonsense: "Implementation of the strategy to > make an adjustment to the specified date-time object." At least that > tells me that the argument is the object being modified -- or is it? > That method returns a DateTime object. Does it return an adjusted > DateTime object, leaving the original argument in-tact? Or does it > modify the argument *and* return it? What adjustment is even being made? > Well, it turns out that it doesn't matter, because the next sentence in > the javadoc says "This method is not intended to be called by > application code directly.". Fantastic: this is a method that is > intentionally useless to me. Some folks blame this on the Java language, some on the javadoc (alphabetical), some on the IDE's completion methods. A big part of Threeten is a framework for defining how date-time objects inter-operate. And along with that framework is a best-practice for using the API. Personally, I'd rather not make a distinction between framework methods and not but some found it to be an important distinction. Feel free to call any public method, but there is a preferred way to use the API. The 'do' prefix identifies framework methods. > > LocalDate: looking at the name I just *know* it's going to be a classic > "date" object (like year-month-day) plus some local information -- like > time zone which includes DST info, right? Oooh, sorry: it's the exact > /opposite/ -- a date with *no* local information. Thank god there's a > ZonedDate, right? Wrong. It's called OffsetDate, and it doesn't have a > Time Zone. Nope, instead it's got a bunch of offsets -- the bane of > anyone who's ever tried to use java.util.Date and java.util.Calendar. A fine point here, though maybe not in your use case, Timezones are used and expected to do adjustments related to daylight savings time and that implies that they can only be evaluated at a particular time. OffsetDate does not have a time... The use of "Local" is from a local observer point of view. If I put you in a room with a clock and calendar on the wall, that's all you know; nothing about where in the world you are; just time and date and they are only useful to use relative to the local context and anyone else who shares that context. > > Back to LocalDate. The class docs say "However, any application that > makes use of historical dates and requires them to be accurate will find > the ISO-8601 rules unsuitable. In this case, the application code should > use HistoricDate and define an explicit cutover date between the Julian > and Gregorian calendar systems.". There's no indication of what the > cutoff between "recent" and "historical" dates should be. 2000 (Y2K)? > 1970 (epoch)? 1900 (2-byte BCD problems)? 1583? 1582? 0? It doesn't > matter because there is no HistoricalDate class, anyway. Sorry, a gap in the spec and a out of date javadoc. > > Year/YearMonth/Month/MonthDay -- these classes are clearly junk that I > can ignore -- at least until I need to something weird. Probably never. > Actually, I take that back: Year.isLeap has some promise, but this stuff > is mostly useful for people writing calendar widgets. Does it need to be > in the top-level package? > > ZoneId: yay, another TimeZone class! > > ZoneOffset extends ZoneId? Weird. > > Okay, forget just browsing the API. Let's try to actually get something > done. Let's see... what do I do on a regular basis with Java's date/time > APIs? > > Exercise 1: get the current date and time, in my time zone. > > Let's assume that I always have this around: > String zoneId = "America/New_York"; > > Old way: > Calendar now = Calendar.getInstance(TimeZone.getTimeZone(zoneId)); > > New way: > ZoneDateTime now = ZoneDateTime.now(ZoneId.of(zoneId)); > > That wasn't too bad. > > Exercise 2: find the start of this quarter (Q1=Jan 1, Q2=Apr 1, etc.). > > Old way: > Calendar quarter = Calendar.getInstance(TimeZone.getTimeZone(zoneId)); > int month = quarter.get(Calendar.MONTH); > quarter.set(Calendar.DAY_OF_MONTH, 1); > quarter.set(Calendar.MONTH, 3 * (month / 3)); > quarter.getTime(); > > New way: > ZoneDateTime now = ZoneDateTime.now(ZoneId.of(zoneId)); > > Hmm... I'm a little lost. I'm fairly sure the best option is to use a > "WithAdjuster", but I'm not sure if I should be writing my own or if > there is one already that will meet my needs. This seems like it would > be a good candidate for adding to the standard API, since getting > quarterly information is essential to businesses. An earlier draft contained support for Quarters but it got classified as you did with YearMonth and got sidelined. I don't see the leap to an Adjuster unless its some you want to do often. The same logic used above can be used with Threeten. now.withDay(1);withMonth((now.getMonth()-1)/3 * 3) + 1); I myself looked twice to see if Month had help here. Dealing with quarters is domain specific... > > Exercise 3: find out how many days between two dates > (Let's just assume there aren't any complexities like calendar > discontinuities, etc. between the dates) > > Old way: > Calendar now = Calendar.getInstance(TimeZone.getTimeZone(zoneId)); > Calendar then = ...; > long l_now = now.getTimeInMillis(); > long l_then = then.getTimeInMillis(); > long delta = l_now - l_then; // Assume 'then' is in the past > long days = delta / (1000 * 60 * 60 * 24); > > New way: > ZoneDateTime now = ZoneDateTime.now(ZoneId.of(zoneId)); > ZoneDateTime then = ...; > > long days = then.periodUntil(now, ChronoUnit.DAYS); > > That's nice. It will probably deal with all the discontinuities that I > wiped-away above, too. > > It's odd that I can't do that with LocalDate -- 'cause I don't care > about time zone, etc... I'm looking for gross-estimates, here -- because > LocalDate.periodUntil() takes a DateTime. ok, but all the Threeten types are a DateTime; so it works with LocalDate. > So, the API seems to be a lot more useful than it appears at first > glance: you can still (probably) get everything done, but there is just > so much cruft it's hard to see what you're really looking for. > > My first reading was absolutely confusing, and I think the same will be > true of many Java developers out there. Good point, we've spec a lot of time on the API and making it robust and extensible and will need to put more time into the presentation and documentation. > > If some of these distracting classes could be placed into sub-packages, > that would certainly help. If some classes could be re-named (always a > matter of subjectivity, I know), I'm sure confusion could be reduced (cf > LocalDate that's not local to anything, etc.). > > Just my na?ve thoughts on the whole thing. Naming has been difficult and choices of names depend on the reader's point view, use cases and what's important making it harder to settle on universally good names and concepts. Thank you very much, keep the comments coming. The more detailed the better. We are more at the stage of explaining what's been done than changing it (due to the schedule) but will make improvements where possible. Roger > > -chris > > From richard.warburton at gmail.com Thu Dec 13 07:40:32 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Thu, 13 Dec 2012 15:40:32 +0000 Subject: [threeten-dev] [threeten-develop] Package structure for Threeten in JDK In-Reply-To: <50C9EF81.6060102@oracle.com> References: <50C8EF77.5050409@oracle.com> <50C906AC.3050602@christopherschultz.net> <50C9EF81.6060102@oracle.com> Message-ID: > > Some folks blame this on the Java language, some on the javadoc > (alphabetical), > some on the IDE's completion methods. > Its not unreasonable to expect IDE's to suggest completions to more frequently used methods. The eclipse project has already got this somewhat implemented. > A big part of Threeten is a framework for defining how date-time objects > inter-operate. > And along with that framework is a best-practice for using the API. > Personally, I'd rather not make a distinction between framework methods > and not but some found it to be an important distinction. > Feel free to call any public method, but there is a preferred way to use > the API. > The 'do' prefix identifies framework methods. I don't think the 'do' prefix is hugely liked by anyone - but the issue is that interfaces only allow for public methods, so there's no way to correctly scope some methods within the Java Language. For reference there was some issue tracker discussion on this topic: https://github.com/ThreeTen/threeten/issues/122 regards, Richard From scolebourne at joda.org Thu Dec 13 07:42:04 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 13 Dec 2012 15:42:04 +0000 Subject: [threeten-dev] DateTime interface Message-ID: Looking at it again, the DateTime interface is not that well named. Each of the following are implementations of DateTime: DateTime a = LocalDateTime.now() DateTime b = ZoneDateTime.now() DateTime c = LocalDate.now(); DateTime d = LocalTime.now(); DateTime e = Insant.now(); DateTime f = ZoneOffset.UTC; While LocalDateTime and Zone[d]DateTime make sense, the others make far less sense. Why does LocalDate implement DateTime when it has no time? Why does ZoneOffset implement DateTime when it has neither a date nor time? The purpose of the interface is to effectively represent common access to some part of the date/time domain. For a long time, the name was Calendrical, but that wasn't much liked. Some alternatives: - Calendrical - Calend - Moment - TimeAspect - Temporal Personally, I think "temporal" is pretty good. It means "of or relating to time". Other suggestions welcome, although change is not yet certain. Note that there are some other related interfaces: - DateTimeAccessor - DateTimeField - PeriodUnit Some or all of these might also make sense to consider. Stephen From misterm at gmail.com Thu Dec 13 07:43:51 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 13 Dec 2012 13:43:51 -0200 Subject: [threeten-dev] DateTime interface In-Reply-To: References: Message-ID: I like Temporal, +1. Regards, Michael On Thu, Dec 13, 2012 at 1:42 PM, Stephen Colebourne wrote: > Looking at it again, the DateTime interface is not that well named. > > Each of the following are implementations of DateTime: > > DateTime a = LocalDateTime.now() > DateTime b = ZoneDateTime.now() > DateTime c = LocalDate.now(); > DateTime d = LocalTime.now(); > DateTime e = Insant.now(); > DateTime f = ZoneOffset.UTC; > > While LocalDateTime and Zone[d]DateTime make sense, the others make > far less sense. > > Why does LocalDate implement DateTime when it has no time? > Why does ZoneOffset implement DateTime when it has neither a date nor time? > > The purpose of the interface is to effectively represent common access > to some part of the date/time domain. > > For a long time, the name was Calendrical, but that wasn't much liked. > Some alternatives: > - Calendrical > - Calend > - Moment > - TimeAspect > - Temporal > > Personally, I think "temporal" is pretty good. It means "of or > relating to time". > > Other suggestions welcome, although change is not yet certain. > > Note that there are some other related interfaces: > - DateTimeAccessor > - DateTimeField > - PeriodUnit > > Some or all of these might also make sense to consider. > > Stephen From richard.warburton at gmail.com Thu Dec 13 08:03:32 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Thu, 13 Dec 2012 16:03:32 +0000 Subject: [threeten-dev] DateTime interface In-Reply-To: References: Message-ID: +1 for Temporal, and renaming Accessor and Field. regards, Richard From Roger.Riggs at oracle.com Thu Dec 13 08:11:48 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 11:11:48 -0500 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: References: Message-ID: <50C9FE44.5050306@oracle.com> Hi, The API is described as the date-time API and as a whole it manipulates dates, times and related values. The DateTime interface ties all of those concepts and objects together. The code snippet below is not representative of how DateTime is likely to be used. We would not promote that form of usage because the concrete class and its immutability and finality are lost. The DateTime interface predominately appears as an argument in the parameter list of methods as a way to pass any of the concrete types. The context of that class and method define the expectations of the parameter. The current name is a good one for the purpose and better than the suggested alternatives. The ripple effects of changing names add a significant risk; any change must bring a real and indisputable benefit. Roger On 12/13/2012 10:42 AM, Stephen Colebourne wrote: > Looking at it again, the DateTime interface is not that well named. > > Each of the following are implementations of DateTime: > > DateTime a = LocalDateTime.now() > DateTime b = ZoneDateTime.now() > DateTime c = LocalDate.now(); > DateTime d = LocalTime.now(); > DateTime e = Instant.now(); > DateTime f = ZoneOffset.UTC; > > While LocalDateTime and Zone[d]DateTime make sense, the others make > far less sense. > > Why does LocalDate implement DateTime when it has no time? > Why does ZoneOffset implement DateTime when it has neither a date nor time? > > The purpose of the interface is to effectively represent common access > to some part of the date/time domain. > > For a long time, the name was Calendrical, but that wasn't much liked. > Some alternatives: > - Calendrical > - Calend > - Moment > - TimeAspect > - Temporal > > Personally, I think "temporal" is pretty good. It means "of or > relating to time". > > Other suggestions welcome, although change is not yet certain. > > Note that there are some other related interfaces: > - DateTimeAccessor > - DateTimeField > - PeriodUnit > > Some or all of these might also make sense to consider. > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From misterm at gmail.com Thu Dec 13 08:19:44 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 13 Dec 2012 14:19:44 -0200 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50C9FF75.6040805@redhat.com> References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> Message-ID: Stephen's email seems to be motivated to the recent feedback we got on the list. For someone getting to know the API, having DateTime seems to make LocalDateTime or Zone[d]DateTime feel like some specialization (not implementation), while makes LocalDate seem unrelated by looking at its name. I support the proposed change. Regards, Michael On Thu, Dec 13, 2012 at 2:16 PM, David M. Lloyd wrote: > Nah. Temporal is a much better name. > > On 12/13/2012 10:11 AM, Roger Riggs wrote: >> Hi, >> >> The API is described as the date-time API and as a whole it manipulates >> dates, times and related values. The DateTime interface ties all of those >> concepts and objects together. >> >> The code snippet below is not representative of how DateTime is >> likely to be used. We would not promote that form of usage because >> the concrete class and its immutability and finality are lost. >> >> The DateTime interface predominately appears as an argument in the >> parameter list of methods as a way to pass any of the concrete types. >> The context of that class and method define the expectations of the >> parameter. >> >> The current name is a good one for the purpose and better than the >> suggested alternatives. >> >> The ripple effects of changing names add a significant risk; >> any change must bring a real and indisputable benefit. >> >> Roger >> >> >> >> >> On 12/13/2012 10:42 AM, Stephen Colebourne wrote: >>> Looking at it again, the DateTime interface is not that well named. >>> >>> Each of the following are implementations of DateTime: >>> >>> DateTime a = LocalDateTime.now() >>> DateTime b = ZoneDateTime.now() >>> DateTime c = LocalDate.now(); >>> DateTime d = LocalTime.now(); >>> DateTime e = Instant.now(); >>> DateTime f = ZoneOffset.UTC; >>> >>> While LocalDateTime and Zone[d]DateTime make sense, the others make >>> far less sense. >>> >>> Why does LocalDate implement DateTime when it has no time? >>> Why does ZoneOffset implement DateTime when it has neither a date nor time? >>> >>> The purpose of the interface is to effectively represent common access >>> to some part of the date/time domain. >>> >>> For a long time, the name was Calendrical, but that wasn't much liked. >>> Some alternatives: >>> - Calendrical >>> - Calend >>> - Moment >>> - TimeAspect >>> - Temporal >>> >>> Personally, I think "temporal" is pretty good. It means "of or >>> relating to time". >>> >>> Other suggestions welcome, although change is not yet certain. >>> >>> Note that there are some other related interfaces: >>> - DateTimeAccessor >>> - DateTimeField >>> - PeriodUnit >>> >>> Some or all of these might also make sense to consider. >>> >>> Stephen >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed to >> developing practices and products that help protect the environment >> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > > > -- > - DML > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From Roger.Riggs at oracle.com Thu Dec 13 08:24:09 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 11:24:09 -0500 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50C9FF75.6040805@redhat.com> References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> Message-ID: <50CA0129.3090307@oracle.com> David, Please elaborate. It is not common for interface to be adjectives. It would sound odd to say that a "LocalDate is a Temporal". The noun form of the word means: "a bodily part (as a bone or muscle) that is near the temples or the sides of the skull behind the orbits *:* a temporal part " Roger On 12/13/2012 11:16 AM, David M. Lloyd wrote: > Nah. Temporal is a much better name. > > On 12/13/2012 10:11 AM, Roger Riggs wrote: >> Hi, >> >> The API is described as the date-time API and as a whole it manipulates >> dates, times and related values. The DateTime interface ties all of those >> concepts and objects together. >> >> The code snippet below is not representative of how DateTime is >> likely to be used. We would not promote that form of usage because >> the concrete class and its immutability and finality are lost. >> >> The DateTime interface predominately appears as an argument in the >> parameter list of methods as a way to pass any of the concrete types. >> The context of that class and method define the expectations of the >> parameter. >> >> The current name is a good one for the purpose and better than the >> suggested alternatives. >> >> The ripple effects of changing names add a significant risk; >> any change must bring a real and indisputable benefit. >> >> Roger >> >> >> >> >> On 12/13/2012 10:42 AM, Stephen Colebourne wrote: >>> Looking at it again, the DateTime interface is not that well named. >>> >>> Each of the following are implementations of DateTime: >>> >>> DateTime a = LocalDateTime.now() >>> DateTime b = ZoneDateTime.now() >>> DateTime c = LocalDate.now(); >>> DateTime d = LocalTime.now(); >>> DateTime e = Instant.now(); >>> DateTime f = ZoneOffset.UTC; >>> >>> While LocalDateTime and Zone[d]DateTime make sense, the others make >>> far less sense. >>> >>> Why does LocalDate implement DateTime when it has no time? >>> Why does ZoneOffset implement DateTime when it has neither a date nor time? >>> >>> The purpose of the interface is to effectively represent common access >>> to some part of the date/time domain. >>> >>> For a long time, the name was Calendrical, but that wasn't much liked. >>> Some alternatives: >>> - Calendrical >>> - Calend >>> - Moment >>> - TimeAspect >>> - Temporal >>> >>> Personally, I think "temporal" is pretty good. It means "of or >>> relating to time". >>> >>> Other suggestions welcome, although change is not yet certain. >>> >>> Note that there are some other related interfaces: >>> - DateTimeAccessor >>> - DateTimeField >>> - PeriodUnit >>> >>> Some or all of these might also make sense to consider. >>> >>> Stephen >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed to >> developing practices and products that help protect the environment >> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From david.lloyd at redhat.com Thu Dec 13 08:16:53 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Dec 2012 10:16:53 -0600 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50C9FE44.5050306@oracle.com> References: <50C9FE44.5050306@oracle.com> Message-ID: <50C9FF75.6040805@redhat.com> Nah. Temporal is a much better name. On 12/13/2012 10:11 AM, Roger Riggs wrote: > Hi, > > The API is described as the date-time API and as a whole it manipulates > dates, times and related values. The DateTime interface ties all of those > concepts and objects together. > > The code snippet below is not representative of how DateTime is > likely to be used. We would not promote that form of usage because > the concrete class and its immutability and finality are lost. > > The DateTime interface predominately appears as an argument in the > parameter list of methods as a way to pass any of the concrete types. > The context of that class and method define the expectations of the > parameter. > > The current name is a good one for the purpose and better than the > suggested alternatives. > > The ripple effects of changing names add a significant risk; > any change must bring a real and indisputable benefit. > > Roger > > > > > On 12/13/2012 10:42 AM, Stephen Colebourne wrote: >> Looking at it again, the DateTime interface is not that well named. >> >> Each of the following are implementations of DateTime: >> >> DateTime a = LocalDateTime.now() >> DateTime b = ZoneDateTime.now() >> DateTime c = LocalDate.now(); >> DateTime d = LocalTime.now(); >> DateTime e = Instant.now(); >> DateTime f = ZoneOffset.UTC; >> >> While LocalDateTime and Zone[d]DateTime make sense, the others make >> far less sense. >> >> Why does LocalDate implement DateTime when it has no time? >> Why does ZoneOffset implement DateTime when it has neither a date nor time? >> >> The purpose of the interface is to effectively represent common access >> to some part of the date/time domain. >> >> For a long time, the name was Calendrical, but that wasn't much liked. >> Some alternatives: >> - Calendrical >> - Calend >> - Moment >> - TimeAspect >> - Temporal >> >> Personally, I think "temporal" is pretty good. It means "of or >> relating to time". >> >> Other suggestions welcome, although change is not yet certain. >> >> Note that there are some other related interfaces: >> - DateTimeAccessor >> - DateTimeField >> - PeriodUnit >> >> Some or all of these might also make sense to consider. >> >> Stephen >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > -- - DML From misterm at gmail.com Thu Dec 13 08:28:36 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 13 Dec 2012 14:28:36 -0200 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50CA0129.3090307@oracle.com> References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> <50CA0129.3090307@oracle.com> Message-ID: On Thu, Dec 13, 2012 at 2:24 PM, Roger Riggs wrote: > It is not common for interface to be adjectives. AutoCloseable, Cloneable, Comparable, Iterable, Readable, Runnable, Serializable... ? Regards, Michael From Roger.Riggs at oracle.com Thu Dec 13 08:37:20 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 11:37:20 -0500 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> <50CA0129.3090307@oracle.com> Message-ID: <50CA0440.2050007@oracle.com> Hi Michael, Valid point, those are modifiers that describe additional behavior added to an existing type. But the proposed usage is to define a model for the core behaviors of the set of types related to fields access, operations plus/minus and lifecycle, etc. Roger On 12/13/2012 11:28 AM, Michael Nascimento wrote: > On Thu, Dec 13, 2012 at 2:24 PM, Roger Riggs wrote: >> It is not common for interface to be adjectives. > AutoCloseable, Cloneable, Comparable, Iterable, Readable, Runnable, > Serializable... ? > > Regards, > Michael > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From david.lloyd at redhat.com Thu Dec 13 08:30:36 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Dec 2012 10:30:36 -0600 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50CA0129.3090307@oracle.com> References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> <50CA0129.3090307@oracle.com> Message-ID: <50CA02AC.5030602@redhat.com> Really? There are about a bazillion -able and -ible interfaces in the JDK already. Some of them are quite recent. On 12/13/2012 10:24 AM, Roger Riggs wrote: > David, > > Please elaborate. > > It is not common for interface to be adjectives. > > It would sound odd to say that a "LocalDate is a Temporal". > > The noun form of the word means: > "a bodily part (as a bone or muscle) that is near the temples > or the sides of the > skull behind the orbits > *:* a temporal part " > > Roger > > > On 12/13/2012 11:16 AM, David M. Lloyd wrote: >> Nah. Temporal is a much better name. >> >> On 12/13/2012 10:11 AM, Roger Riggs wrote: >>> Hi, >>> >>> The API is described as the date-time API and as a whole it manipulates >>> dates, times and related values. The DateTime interface ties all of those >>> concepts and objects together. >>> >>> The code snippet below is not representative of how DateTime is >>> likely to be used. We would not promote that form of usage because >>> the concrete class and its immutability and finality are lost. >>> >>> The DateTime interface predominately appears as an argument in the >>> parameter list of methods as a way to pass any of the concrete types. >>> The context of that class and method define the expectations of the >>> parameter. >>> >>> The current name is a good one for the purpose and better than the >>> suggested alternatives. >>> >>> The ripple effects of changing names add a significant risk; >>> any change must bring a real and indisputable benefit. >>> >>> Roger >>> >>> >>> >>> >>> On 12/13/2012 10:42 AM, Stephen Colebourne wrote: >>>> Looking at it again, the DateTime interface is not that well named. >>>> >>>> Each of the following are implementations of DateTime: >>>> >>>> DateTime a = LocalDateTime.now() >>>> DateTime b = ZoneDateTime.now() >>>> DateTime c = LocalDate.now(); >>>> DateTime d = LocalTime.now(); >>>> DateTime e = Instant.now(); >>>> DateTime f = ZoneOffset.UTC; >>>> >>>> While LocalDateTime and Zone[d]DateTime make sense, the others make >>>> far less sense. >>>> >>>> Why does LocalDate implement DateTime when it has no time? >>>> Why does ZoneOffset implement DateTime when it has neither a date nor time? >>>> >>>> The purpose of the interface is to effectively represent common access >>>> to some part of the date/time domain. >>>> >>>> For a long time, the name was Calendrical, but that wasn't much liked. >>>> Some alternatives: >>>> - Calendrical >>>> - Calend >>>> - Moment >>>> - TimeAspect >>>> - Temporal >>>> >>>> Personally, I think "temporal" is pretty good. It means "of or >>>> relating to time". >>>> >>>> Other suggestions welcome, although change is not yet certain. >>>> >>>> Note that there are some other related interfaces: >>>> - DateTimeAccessor >>>> - DateTimeField >>>> - PeriodUnit >>>> >>>> Some or all of these might also make sense to consider. >>>> >>>> Stephen >>>> >>>> ------------------------------------------------------------------------------ >>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>> Remotely access PCs and mobile devices and provide instant support >>>> Improve your efficiency, and focus on delivering more value-add services >>>> Discover what IT Professionals Know. Rescue delivers >>>> http://p.sf.net/sfu/logmein_12329d2d >>>> _______________________________________________ >>>> threeten-develop mailing list >>>> threeten-develop at lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> -- >>> Thanks, Roger >>> >>> Oracle Java Platform Group >>> >>> Green Oracle Oracle is committed to >>> developing practices and products that help protect the environment >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> >>> >>> >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >> > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > -- - DML From yh at kashrus.com Thu Dec 13 09:03:42 2012 From: yh at kashrus.com (Yishai Hornbacher) Date: Thu, 13 Dec 2012 17:03:42 +0000 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: References: Message-ID: How about TimeComponent? -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Thursday, December 13, 2012 10:42 AM To: threeten-develop at lists.sourceforge.net; threeten-dev at openjdk.java.net Subject: [threeten-develop] DateTime interface Looking at it again, the DateTime interface is not that well named. Each of the following are implementations of DateTime: DateTime a = LocalDateTime.now() DateTime b = ZoneDateTime.now() DateTime c = LocalDate.now(); DateTime d = LocalTime.now(); DateTime e = Insant.now(); DateTime f = ZoneOffset.UTC; While LocalDateTime and Zone[d]DateTime make sense, the others make far less sense. Why does LocalDate implement DateTime when it has no time? Why does ZoneOffset implement DateTime when it has neither a date nor time? The purpose of the interface is to effectively represent common access to some part of the date/time domain. For a long time, the name was Calendrical, but that wasn't much liked. Some alternatives: - Calendrical - Calend - Moment - TimeAspect - Temporal Personally, I think "temporal" is pretty good. It means "of or relating to time". Other suggestions welcome, although change is not yet certain. Note that there are some other related interfaces: - DateTimeAccessor - DateTimeField - PeriodUnit Some or all of these might also make sense to consider. Stephen ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ threeten-develop mailing list threeten-develop at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/threeten-develop From xueming.shen at oracle.com Thu Dec 13 10:11:38 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Dec 2012 10:11:38 -0800 Subject: [threeten-dev] [threeten-develop] Design Feedback [was Package structure for Threeten in JDK] In-Reply-To: References: <50CA0BB9.9060306@christopherschultz.net> <50CA1459.3020402@christopherschultz.net> Message-ID: <50CA1A5A.5090702@oracle.com> Well, from OpenJDK point of view, things are simple, if we can start to work/ contribute directly on JDK8-threeten repository:-) we can save those sync/merge burden, given we don't have lots of time left, if we are "seriously" targeting JDK8. The official JDK8-threeten repository is at http://hg.openjdk.java.net/threeten/threeten And it is strongly encouraged to subscribe the jdk8-threeten mailing list, some of the jdk8 integration related messages might only go to that mailing list. http://mail.openjdk.java.net/mailman/listinfo/threeten-dev Sure, if you are not a OpenJDK contributor yet, read http://openjdk.java.net/contribute/ -Sherman On 12/13/2012 09:54 AM, Stephen Colebourne wrote: > On 13 December 2012 17:46, Christopher Schultz > wrote: >>> Agreed. The Javadoc of the overview definitely needs improving in the >>> area of significant method prefixes. >> If I take a stab at something, shall I look at the current Javadoc >> posted or the current Java source, and would you prefer a diff against >> the source or just text samples? Email or issue-tracker? > You would need to agree to this: > https://github.com/ThreeTen/threeten/blob/master/COPYRIGHT-ASSIGN.txt > > And then probably paste Javadoc suggestions in the GitHub issue > tracker (we're on OpenJDK mercurial now, so things are more complex). > I'd start with the package.html files. > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Thu Dec 13 10:31:47 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 13 Dec 2012 18:31:47 +0000 Subject: [threeten-dev] Opinion poll on Zone[d]DateTime In-Reply-To: References: Message-ID: And I can safely conclude the answer of the poll. "Q1 What should the final class be called?" 1) ZonedDateTime 42% 2) ZoneDateTime 49% 3) Other 9% ZonalDateTime, SymbolicZoneDateTime, DateTimeWithZone, TimezoneDateTime, DateTimeTZ, DateTimeInTimeZone, DateTimeZone "Q4 Given this fact (alpha/preview), which name would you choose?" 1) ZonedDateTime 54% 2) ZoneDateTime 45% Q2/3 even spread of answers. Thus, pretty much 50/50. Given where we are, I could argue for either name and ultimately, in a few months time no-one would care. Ultimately, it seems that this name change is not significant enough to win a greater than 2:1 majority that I wanted. So, we should change back to ZonedDateTime. Roger, you volunteered to make this rename? thanks Stephen On 12 December 2012 23:01, Stephen Colebourne wrote: > It seems like a poll is necessary for ZoneDateTime vs ZonedDateTime: > > http://www.rationalsurvey.com/s/6916 > > Please note, that I will not necessarily follow the results of the > poll, but it will be a good data point. > Please distribute this to those you know. > thanks > Stephen From Roger.Riggs at oracle.com Thu Dec 13 11:37:49 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 14:37:49 -0500 Subject: [threeten-dev] Opinion poll on Zone[d]DateTime In-Reply-To: References: Message-ID: <50CA2E8D.20507@oracle.com> Hi Stephen, ok, I'll make the change. To avoid thrash; I'd prefer to do it at the same time as the package renaming, either the end of this week or the beginning of next. Roger On 12/13/2012 1:31 PM, Stephen Colebourne wrote: > And I can safely conclude the answer of the poll. > > "Q1 What should the final class be called?" > 1) ZonedDateTime 42% > 2) ZoneDateTime 49% > 3) Other 9% > ZonalDateTime, SymbolicZoneDateTime, DateTimeWithZone, > TimezoneDateTime, DateTimeTZ, DateTimeInTimeZone, DateTimeZone > > "Q4 Given this fact (alpha/preview), which name would you choose?" > 1) ZonedDateTime 54% > 2) ZoneDateTime 45% > > Q2/3 even spread of answers. > > Thus, pretty much 50/50. Given where we are, I could argue for either > name and ultimately, in a few months time no-one would care. > > Ultimately, it seems that this name change is not significant enough > to win a greater than 2:1 majority that I wanted. So, we should change > back to ZonedDateTime. > > Roger, you volunteered to make this rename? > > thanks > Stephen > > > > > On 12 December 2012 23:01, Stephen Colebourne wrote: >> It seems like a poll is necessary for ZoneDateTime vs ZonedDateTime: >> >> http://www.rationalsurvey.com/s/6916 >> >> Please note, that I will not necessarily follow the results of the >> poll, but it will be a good data point. >> Please distribute this to those you know. >> thanks >> Stephen -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Thu Dec 13 12:56:08 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Dec 2012 12:56:08 -0800 Subject: [threeten-dev] [threeten-develop] Opinion poll on Zone[d]DateTime In-Reply-To: <50CA2E8D.20507@oracle.com> References: <50CA2E8D.20507@oracle.com> Message-ID: <50CA40E8.2060404@oracle.com> Here is the diff for the jdk8_threeten repo. Tests all passed (need to rename that serialization bin data as well. I'm not putting that in diff, as it's a binary data). http://cr.openjdk.java.net/~sherman/jdk8_threeten/zdt/ Stephen, you might want to take a quick scan to see if anything obvious is missing. I will hold the push, if Roger believes it would be better to do it together with the packaging change (if there is one at the week end)' -Sherman On 12/13/2012 11:37 AM, Roger Riggs wrote: > Hi Stephen, > > ok, I'll make the change. > > To avoid thrash; I'd prefer to do it at the same time as the package renaming, > either the end of this week or the beginning of next. > > Roger > > > On 12/13/2012 1:31 PM, Stephen Colebourne wrote: >> And I can safely conclude the answer of the poll. >> >> "Q1 What should the final class be called?" >> 1) ZonedDateTime 42% >> 2) ZoneDateTime 49% >> 3) Other 9% >> ZonalDateTime, SymbolicZoneDateTime, DateTimeWithZone, >> TimezoneDateTime, DateTimeTZ, DateTimeInTimeZone, DateTimeZone >> >> "Q4 Given this fact (alpha/preview), which name would you choose?" >> 1) ZonedDateTime 54% >> 2) ZoneDateTime 45% >> >> Q2/3 even spread of answers. >> >> Thus, pretty much 50/50. Given where we are, I could argue for either >> name and ultimately, in a few months time no-one would care. >> >> Ultimately, it seems that this name change is not significant enough >> to win a greater than 2:1 majority that I wanted. So, we should change >> back to ZonedDateTime. >> >> Roger, you volunteered to make this rename? >> >> thanks >> Stephen >> >> >> >> >> On 12 December 2012 23:01, Stephen Colebourne wrote: >>> It seems like a poll is necessary for ZoneDateTime vs ZonedDateTime: >>> >>> http://www.rationalsurvey.com/s/6916 >>> >>> Please note, that I will not necessarily follow the results of the >>> poll, but it will be a good data point. >>> Please distribute this to those you know. >>> thanks >>> Stephen > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to developing practices and products that help protect the environment > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From Roger.Riggs at oracle.com Thu Dec 13 13:02:31 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2012 16:02:31 -0500 Subject: [threeten-dev] [threeten-develop] Opinion poll on Zone[d]DateTime In-Reply-To: <50CA40E8.2060404@oracle.com> References: <50CA2E8D.20507@oracle.com> <50CA40E8.2060404@oracle.com> Message-ID: <50CA4267.8030106@oracle.com> Since you've done all the work, you might as well push it. On 12/13/2012 3:56 PM, Xueming Shen wrote: > Here is the diff for the jdk8_threeten repo. Tests all passed (need to > rename that > serialization bin data as well. I'm not putting that in diff, as it's > a binary data). > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/zdt/ > > Stephen, you might want to take a quick scan to see if anything > obvious is missing. > > I will hold the push, if Roger believes it would be better to do it > together with the > packaging change (if there is one at the week end)' > > -Sherman > > On 12/13/2012 11:37 AM, Roger Riggs wrote: >> Hi Stephen, >> >> ok, I'll make the change. >> >> To avoid thrash; I'd prefer to do it at the same time as the package >> renaming, >> either the end of this week or the beginning of next. >> >> Roger >> >> >> On 12/13/2012 1:31 PM, Stephen Colebourne wrote: >>> And I can safely conclude the answer of the poll. >>> >>> "Q1 What should the final class be called?" >>> 1) ZonedDateTime 42% >>> 2) ZoneDateTime 49% >>> 3) Other 9% >>> ZonalDateTime, SymbolicZoneDateTime, DateTimeWithZone, >>> TimezoneDateTime, DateTimeTZ, DateTimeInTimeZone, DateTimeZone >>> >>> "Q4 Given this fact (alpha/preview), which name would you choose?" >>> 1) ZonedDateTime 54% >>> 2) ZoneDateTime 45% >>> >>> Q2/3 even spread of answers. >>> >>> Thus, pretty much 50/50. Given where we are, I could argue for either >>> name and ultimately, in a few months time no-one would care. >>> >>> Ultimately, it seems that this name change is not significant enough >>> to win a greater than 2:1 majority that I wanted. So, we should change >>> back to ZonedDateTime. >>> >>> Roger, you volunteered to make this rename? >>> >>> thanks >>> Stephen >>> >>> >>> >>> >>> On 12 December 2012 23:01, Stephen Colebourne >>> wrote: >>>> It seems like a poll is necessary for ZoneDateTime vs ZonedDateTime: >>>> >>>> http://www.rationalsurvey.com/s/6916 >>>> >>>> Please note, that I will not necessarily follow the results of the >>>> poll, but it will be a good data point. >>>> Please distribute this to those you know. >>>> thanks >>>> Stephen >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> >> >> ------------------------------------------------------------------------------ >> >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Thu Dec 13 13:28:52 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Dec 2012 13:28:52 -0800 Subject: [threeten-dev] Fwd: jtreg 4.1 b05 released Message-ID: <50CA4894.1080805@oracle.com> FYI -------- Original Message -------- Received: from acsinet21.oracle.com (/141.146.126.237) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Dec 2012 13:23:42 -0800 Received: from sca-git1.sun.com (sca-git1.sun.com [192.9.168.170]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBDLNe0u016677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 21:23:41 GMT Received: from [127.0.0.1] (mail.openjdk.java.net [192.9.170.174]) by sca-git1.sun.com (8.13.8+Sun/8.13.8) with ESMTP id qBDLKiCv026295; Thu, 13 Dec 2012 13:20:45 -0800 (PST) X-Original-To: jdk8-dev at openjdk.java.net Delivered-To: jdk8-dev at openjdk.java.net Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by mail.openjdk.java.net (Postfix) with ESMTP id 8807E6019 for ; Thu, 13 Dec 2012 13:20:36 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBDLKbWd002582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Dec 2012 21:20:37 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBDLKaH4010737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 21:20:36 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBDLKa4b013949 for ; Thu, 13 Dec 2012 15:20:36 -0600 Received: from [192.168.111.161] (/10.132.189.109) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Dec 2012 13:20:36 -0800 Message-ID: <50CA46A2.3010809 at oracle.com> Date: Thu, 13 Dec 2012 13:20:34 -0800 From: Jonathan Gibbons User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: jdk8-dev Subject: jtreg 4.1 b05 released Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: jdk8-dev at openjdk.java.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Technical discussion related to the JDK 8 Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: jdk8-dev-bounces at openjdk.java.net Errors-To: jdk8-dev-bounces at openjdk.java.net JDK folk, jtreg 4.1 b05 is now available, and includes TestNG support for the new tests appearing in the JDK 8 langtools/ and jdk/ repositories. For more details, see https://blogs.oracle.com/jjg/ -- Jon From Lance.Andersen at oracle.com Thu Dec 13 13:43:34 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 13 Dec 2012 16:43:34 -0500 Subject: [threeten-dev] [threeten-develop] DateTime interface In-Reply-To: <50C9FF75.6040805@redhat.com> References: <50C9FE44.5050306@oracle.com> <50C9FF75.6040805@redhat.com> Message-ID: <2895E722-1FEA-488E-BE87-E471172705CB@oracle.com> Works well as JPA has an Enum called TemporalType http://docs.oracle.com/javaee/6/api/javax/persistence/TemporalType.html and AskMonty would probably agree https://kb.askmonty.org/en/temporal-data-types/ :-) On Dec 13, 2012, at 11:16 AM, David M. Lloyd wrote: > Nah. Temporal is a much better name. > > On 12/13/2012 10:11 AM, Roger Riggs wrote: >> Hi, >> >> The API is described as the date-time API and as a whole it manipulates >> dates, times and related values. The DateTime interface ties all of those >> concepts and objects together. >> >> The code snippet below is not representative of how DateTime is >> likely to be used. We would not promote that form of usage because >> the concrete class and its immutability and finality are lost. >> >> The DateTime interface predominately appears as an argument in the >> parameter list of methods as a way to pass any of the concrete types. >> The context of that class and method define the expectations of the >> parameter. >> >> The current name is a good one for the purpose and better than the >> suggested alternatives. >> >> The ripple effects of changing names add a significant risk; >> any change must bring a real and indisputable benefit. >> >> Roger >> >> >> >> >> On 12/13/2012 10:42 AM, Stephen Colebourne wrote: >>> Looking at it again, the DateTime interface is not that well named. >>> >>> Each of the following are implementations of DateTime: >>> >>> DateTime a = LocalDateTime.now() >>> DateTime b = ZoneDateTime.now() >>> DateTime c = LocalDate.now(); >>> DateTime d = LocalTime.now(); >>> DateTime e = Instant.now(); >>> DateTime f = ZoneOffset.UTC; >>> >>> While LocalDateTime and Zone[d]DateTime make sense, the others make >>> far less sense. >>> >>> Why does LocalDate implement DateTime when it has no time? >>> Why does ZoneOffset implement DateTime when it has neither a date nor time? >>> >>> The purpose of the interface is to effectively represent common access >>> to some part of the date/time domain. >>> >>> For a long time, the name was Calendrical, but that wasn't much liked. >>> Some alternatives: >>> - Calendrical >>> - Calend >>> - Moment >>> - TimeAspect >>> - Temporal >>> >>> Personally, I think "temporal" is pretty good. It means "of or >>> relating to time". >>> >>> Other suggestions welcome, although change is not yet certain. >>> >>> Note that there are some other related interfaces: >>> - DateTimeAccessor >>> - DateTimeField >>> - PeriodUnit >>> >>> Some or all of these might also make sense to consider. >>> >>> Stephen >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed to >> developing practices and products that help protect the environment >> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > > > -- > - DML > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Thu Dec 13 14:19:16 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 13 Dec 2012 22:19:16 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Renamed ZoneDateTime back to ZonedDateTime Message-ID: <20121213221959.78B4C47125@hg.openjdk.java.net> Changeset: 5733ff6d755e Author: sherman Date: 2012-12-13 13:49 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5733ff6d755e Renamed ZoneDateTime back to ZonedDateTime ! src/share/classes/java/util/Formatter.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/Ser.java - src/share/classes/javax/time/ZoneDateTime.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneRegion.java + src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendrical/ChronoUnit.java ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java - src/share/classes/javax/time/chrono/ChronoZoneDateTime.java - src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java + src/share/classes/javax/time/chrono/ChronoZonedDateTime.java + src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/chrono/Ser.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/package.html ! src/share/classes/javax/time/zone/ZoneRulesProvider.java - test/javax/time/resources/ZoneDateTime.bin + test/javax/time/resources/ZonedDateTime.bin ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java - test/javax/time/tck/javax/time/TCKZoneDateTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java + test/javax/time/tck/javax/time/TCKZonedDateTime.java - test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java + test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/test/java/util/TestFormatter.java ! test/javax/time/test/javax/time/TestClock_Tick.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java From dan.chiba at oracle.com Thu Dec 13 15:09:08 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Thu, 13 Dec 2012 15:09:08 -0800 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: <50C8ACE8.2060907@oracle.com> References: <50C8ACE8.2060907@oracle.com> Message-ID: <50CA6014.3080209@oracle.com> Hi Stephen, Yoshito, For the discrepancies between 310 and CLDR, it would be ideal for us to be able to resolve them one way or the other. Personally I look at them as issues because they often cause problems in similar cases. I don't think there is an issue in "I" in CLDR. Printing "I" out of an offset is an attempt to format a nonexistent field. It is the same as attempting a time field when the value is date only or vise versa or anything similar. Another possible difference is punctuations. LDML says "... certain ASCII punctuation characters may become variable in the future (for example, ":" being interpreted as the time separator and '/' as a date separator, and replaced by respective locale-sensitive characters in display)." I think locale sensitive pattern letters for punctuations are desired, or formatting to the local user's expectation could be difficult to achieve. In particular, the fractional seconds would be difficult, as predefined locale sensitive patterns with fractional seconds are hard to find. Yoshito, would you let us know if you would like us to file a formal request for new pattern letters, please? Regards, -Dan On 5 December 2012 14:42,> wrote: > On 5 December 2012 04:36,> wrote: > >/ "The pattern string is also similar, but not identical, to that defined by > />/ the Unicode Common Locale Data Repository (CLDR)." > / > This is the relevent section of comments in the code > > FIELD_MAP.put('G', ChronoField.ERA); // > Java, CLDR (different to both for 1/2 chars) > FIELD_MAP.put('y', ChronoField.YEAR); // CLDR > // FIELD_MAP.put('y', ChronoField.YEAR_OF_ERA); // > Java, CLDR // TODO redefine from above > // FIELD_MAP.put('u', ChronoField.YEAR); // > CLDR // TODO > // FIELD_MAP.put('Y', ISODateTimeField.WEEK_BASED_YEAR); > // Java7, CLDR (needs localized week number) // TODO > // FIELD_MAP.put('Q', QuarterYearField.QUARTER_OF_YEAR); > // CLDR (removed quarter from 310) > // FIELD_MAP.put('q', QuarterYearField.QUARTER_OF_YEAR); > // CLDR (needs standalone data) // TODO > FIELD_MAP.put('M', ChronoField.MONTH_OF_YEAR); // Java, CLDR > // FIELD_MAP.put('L', ChronoField.MONTH_OF_YEAR); // > Java, CLDR (needs standalone data) // TODO > // FIELD_MAP.put('w', > ISODateTimeField.WEEK_OF_WEEK_BASED_YEAR); // Java, CLDR (needs > localized week number) // TODO > FIELD_MAP.put('D', ChronoField.DAY_OF_YEAR); // Java, CLDR > FIELD_MAP.put('d', ChronoField.DAY_OF_MONTH); // Java, CLDR > FIELD_MAP.put('F', ChronoField.ALIGNED_WEEK_OF_MONTH); // Java, CLDR > FIELD_MAP.put('E', ChronoField.DAY_OF_WEEK); // > Java, CLDR (different to both for 1/2 chars) > // FIELD_MAP.put('e', ChronoField.DAY_OF_WEEK); // > CLDR (needs localized week number) // TODO > // FIELD_MAP.put('c', ChronoField.DAY_OF_WEEK); // > CLDR (needs standalone data) // TODO > FIELD_MAP.put('a', ChronoField.AMPM_OF_DAY); // Java, CLDR > FIELD_MAP.put('H', ChronoField.HOUR_OF_DAY); // Java, CLDR > FIELD_MAP.put('k', ChronoField.CLOCK_HOUR_OF_DAY); // Java, CLDR > FIELD_MAP.put('K', ChronoField.HOUR_OF_AMPM); // Java, CLDR > FIELD_MAP.put('h', ChronoField.CLOCK_HOUR_OF_AMPM); // Java, CLDR > FIELD_MAP.put('m', ChronoField.MINUTE_OF_HOUR); // Java, CLDR > FIELD_MAP.put('s', ChronoField.SECOND_OF_MINUTE); // Java, CLDR > FIELD_MAP.put('S', ChronoField.NANO_OF_SECOND); // > CLDR (Java uses milli-of-second number) > FIELD_MAP.put('A', ChronoField.MILLI_OF_DAY); // CLDR > FIELD_MAP.put('n', ChronoField.NANO_OF_SECOND); // 310 > FIELD_MAP.put('N', ChronoField.NANO_OF_DAY); // 310 > // reserved - z,Z,X,I,p > // Java - X - compatible, but extended to 4 and 5 letters > // Java - u - clashes with CLDR, go with CLDR (year-proleptic) here > // CLDR - U - cycle year name, not supported by 310 yet > // CLDR - l - deprecated > // CLDR - W - week-of-month following CLDR rules > // CLDR - j - not relevant > // CLDR - g - modified-julian-day > // CLDR - z - time-zone names // TODO properly > // CLDR - Z - different approach here // TODO bring 310 in > line with CLDR > // CLDR - v,V - extended time-zone names > // 310 - I - time-zone id > // 310 - p - prefix for padding > > If you can decode my comments you'll find a variety of differences. > > >/ With my quick review, following pattern letters are not available in LDML > />/ specification > />/ > />/ n nano-of-second number/fraction 987654321 > />/ N nano-of-day number/fraction 1234000000 > />/ I time-zone ID zoneID America/Los_Angeles > />/ > />/ I think all of these make sense. In longer term, I don't want to see > />/ different pattern definition across similar implementations. If these are > />/ final, I'm happy to work on CLDR side and propose these pattern letters > />/ registered in the LDML specification. > / > It would be good to see these in LDML. As of now, n and N are simple > numbers, not fractions. > (Previously, I used 'f' as a prefix turning the next letter into a fraction) > > However, "I" is interesting. In 310 we now have three underlying > concepts offsets from UTC/Greenwich, regional time-zone IDs and > general time-zone IDs (either an offset ID or a region ID). Most text > formats would want to print both the offset and the time-zone ID, but > they would not want to print the time-zone ID if it is an offset (as > opposed to a region). Thus, "I" should probably be the subset of all > time-zone IDs that represent regions. This works well in 310 where we > have this distinction, but may be tricky in LDML. > > > >/ X zone-offset 'Z' for zero offset-X Z; -0800; -08:00; > />/ > />/ This one is tricky. We recently added ISO 8601 style offset format in the > />/ LDML specification with "ZZZZZ" > />/ LDML "ZZZZZ" formats UTC to "Z" and non-UTC offsets using longer format > />/ such as "-08:00" (with colon). > />/ > />/ Z zone-offset offset-Z +0000; -0800; > />/ -08:00; > />/ > />/ On the other hand, pattern letter "Z" in the LDML specification uses the > />/ following definition- > />/ > />/ Z, ZZ, ZZZ -> RFC822 format > />/ ZZZZ -> Localized GMT format, such as "GMT-08:00" "UTC-08:00"... > />/ > />/ I personally think CLDR may introduce pattern X, supporting both > />/ long/short offset format, and deprecate "ZZZZZ" (or simply leave it as an > />/ alias definition). > />/ > />/ For offset format, CLDR community is now seeking for shorter offset format > />/ support. For example, "GMT-3" instead of "GMT-03:00". > / > We don't have that right now. > > >/ Anyway, I'll consult with CLDR community members to find out if CLDR can > />/ provide compatible definitions for these too. > / > Keep us informed. We may have some ability to tweak these patterns for > the next few months, but it will be increasingly difficult. > > Stephen From yoshito_umaoka at us.ibm.com Thu Dec 13 15:31:53 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Thu, 13 Dec 2012 18:31:53 -0500 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: <50CA6014.3080209@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> Message-ID: Dan Chiba wrote on 12/13/2012 06:09:08 PM: > For the discrepancies between 310 and CLDR, it would be ideal for us > to be able to resolve them one way or the other. Personally I look > at them as issues because they often cause problems in similar cases. > > I don't think there is an issue in "I" in CLDR. Printing "I" out of > an offset is an attempt to format a nonexistent field. It is the > same as attempting a time field when the value is date only or vise > versa or anything similar. > > Another possible difference is punctuations. LDML says "... certain > ASCII punctuation characters may become variable in the future (for > example, ":" being interpreted as the time separator and '/' as a > date separator, and replaced by respective locale-sensitive > characters in display)." I think locale sensitive pattern letters > for punctuations are desired, or formatting to the local user's > expectation could be difficult to achieve. In particular, the > fractional seconds would be difficult, as predefined locale > sensitive patterns with fractional seconds are hard to find. > > Yoshito, would you let us know if you would like us to file a formal > request for new pattern letters, please? > > Regards, > -Dan I've already filed a ticket to CLDR trac system [ http://unicode.org/cldr/trac/ticket/5506]. I'm a CLDR TC member and I've already asked other CLDR TC folks to look into this. I'm going to propose: - Add n/N/I to the LDML specification with the definition used by JDK - Add X for ISO type format, keeping "ZZZZZ" as an alias of XXX (long ISO) We probably ended up to define another letter for what CLDR calls "locaized GMT format". There is another requirement for supporting shortest representation of localized GMT format. For punctuation variable... In my honest opinion, I think there are many issues with introducing punctuation variables. -Yoshito From scolebourne at joda.org Thu Dec 13 17:19:17 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Dec 2012 01:19:17 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Renamed ZoneDateTime back to ZonedDateTime In-Reply-To: <20121213221959.78B4C47125@hg.openjdk.java.net> References: <20121213221959.78B4C47125@hg.openjdk.java.net> Message-ID: You also need to search and replace "zone date-time" to zoned date-time" in comments. thanks Stephen On 13 December 2012 22:19, wrote: > Changeset: 5733ff6d755e > Author: sherman > Date: 2012-12-13 13:49 -0800 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5733ff6d755e > > Renamed ZoneDateTime back to ZonedDateTime > > ! src/share/classes/java/util/Formatter.java > ! src/share/classes/javax/time/Instant.java > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/OffsetDateTime.java > ! src/share/classes/javax/time/Ser.java > - src/share/classes/javax/time/ZoneDateTime.java > ! src/share/classes/javax/time/ZoneId.java > ! src/share/classes/javax/time/ZoneRegion.java > + src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/calendrical/ChronoUnit.java > ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java > ! src/share/classes/javax/time/chrono/Chrono.java > ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java > - src/share/classes/javax/time/chrono/ChronoZoneDateTime.java > - src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java > + src/share/classes/javax/time/chrono/ChronoZonedDateTime.java > + src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java > ! src/share/classes/javax/time/chrono/ISOChrono.java > ! src/share/classes/javax/time/chrono/Ser.java > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > ! src/share/classes/javax/time/format/DateTimeFormatters.java > ! src/share/classes/javax/time/package.html > ! src/share/classes/javax/time/zone/ZoneRulesProvider.java > - test/javax/time/resources/ZoneDateTime.bin > + test/javax/time/resources/ZonedDateTime.bin > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java > ! test/javax/time/tck/javax/time/TCKOffsetTime.java > - test/javax/time/tck/javax/time/TCKZoneDateTime.java > ! test/javax/time/tck/javax/time/TCKZoneOffset.java > + test/javax/time/tck/javax/time/TCKZonedDateTime.java > - test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java > + test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java > ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > ! test/javax/time/test/java/util/TestFormatter.java > ! test/javax/time/test/javax/time/TestClock_Tick.java > ! test/javax/time/test/javax/time/TestZoneId.java > ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java > ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java > ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java > ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java > From xueming.shen at oracle.com Thu Dec 13 18:42:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Dec 2012 18:42:13 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: Renamed ZoneDateTime back to ZonedDateTime In-Reply-To: References: <20121213221959.78B4C47125@hg.openjdk.java.net> Message-ID: <50CA9205.3010606@oracle.com> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zdt2/ On 12/13/12 5:19 PM, Stephen Colebourne wrote: > You also need to search and replace "zone date-time" to zoned > date-time" in comments. > thanks > Stephen > > > On 13 December 2012 22:19, wrote: >> Changeset: 5733ff6d755e >> Author: sherman >> Date: 2012-12-13 13:49 -0800 >> URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5733ff6d755e >> >> Renamed ZoneDateTime back to ZonedDateTime >> >> ! src/share/classes/java/util/Formatter.java >> ! src/share/classes/javax/time/Instant.java >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/OffsetDateTime.java >> ! src/share/classes/javax/time/Ser.java >> - src/share/classes/javax/time/ZoneDateTime.java >> ! src/share/classes/javax/time/ZoneId.java >> ! src/share/classes/javax/time/ZoneRegion.java >> + src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/calendrical/ChronoUnit.java >> ! src/share/classes/javax/time/calendrical/DateTimeAccessor.java >> ! src/share/classes/javax/time/chrono/Chrono.java >> ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java >> - src/share/classes/javax/time/chrono/ChronoZoneDateTime.java >> - src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java >> + src/share/classes/javax/time/chrono/ChronoZonedDateTime.java >> + src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java >> ! src/share/classes/javax/time/chrono/ISOChrono.java >> ! src/share/classes/javax/time/chrono/Ser.java >> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >> ! src/share/classes/javax/time/format/DateTimeFormatters.java >> ! src/share/classes/javax/time/package.html >> ! src/share/classes/javax/time/zone/ZoneRulesProvider.java >> - test/javax/time/resources/ZoneDateTime.bin >> + test/javax/time/resources/ZonedDateTime.bin >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java >> ! test/javax/time/tck/javax/time/TCKOffsetTime.java >> - test/javax/time/tck/javax/time/TCKZoneDateTime.java >> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >> + test/javax/time/tck/javax/time/TCKZonedDateTime.java >> - test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java >> + test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >> ! test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> ! test/javax/time/test/java/util/TestFormatter.java >> ! test/javax/time/test/javax/time/TestClock_Tick.java >> ! test/javax/time/test/javax/time/TestZoneId.java >> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >> ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java >> ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java >> ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java >> From xueming.shen at oracle.com Thu Dec 13 18:48:40 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 14 Dec 2012 02:48:40 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Renamed ZoneDateTime back to ZonedDateTime Message-ID: <20121214024925.670EA4713A@hg.openjdk.java.net> Changeset: 63b14994bed1 Author: sherman Date: 2012-12-13 18:48 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/63b14994bed1 Renamed ZoneDateTime back to ZonedDateTime ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/format/DateTimeFormatters.java From dan.chiba at oracle.com Thu Dec 13 20:00:29 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Thu, 13 Dec 2012 20:00:29 -0800 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> Message-ID: <50CAA45D.6090000@oracle.com> Yoshito, Thank you for filing the CLDR ticket. Your proposal sounds great. May I ask the status of the shortest GMT format? When could it be implemented by vendors? As for punctuations, I think comma and dot are already locale sensitive for number formatting, so it would be easy for people to understand how the locale sensitive punctuations for date time formatting work. Because the predefined formatting patterns for locales have the separators for date and time fields and they are commonly used, it doesn't seem to be an issue that there is no locale sensitive pattern letter for them. So I think I am only interested in the decimal separator for fractional seconds. Alternatively, if CLDR had predefined locale sensitive patterns with fractional seconds, that could also be a solution. For instance, a predefined common pattern to print hour, minute, second and millisecond for the US locale may look like this: HH:mm:ss.SSS Stephen, Would you elaborate what "p" (prefix for padding) does? Does it make sense to have it defined in LDML as well? Also, do you think 310 can suppor the shortest GMT format if its status is ready for implementation? Regards, -Dan On 12/13/2012 3:31 PM, yoshito_umaoka at us.ibm.com wrote: > Dan Chiba wrote on 12/13/2012 06:09:08 PM: > > > For the discrepancies between 310 and CLDR, it would be ideal for us > > to be able to resolve them one way or the other. Personally I look > > at them as issues because they often cause problems in similar cases. > > > > I don't think there is an issue in "I" in CLDR. Printing "I" out of > > an offset is an attempt to format a nonexistent field. It is the > > same as attempting a time field when the value is date only or vise > > versa or anything similar. > > > > Another possible difference is punctuations. LDML says "... certain > > ASCII punctuation characters may become variable in the future (for > > example, ":" being interpreted as the time separator and '/' as a > > date separator, and replaced by respective locale-sensitive > > characters in display)." I think locale sensitive pattern letters > > for punctuations are desired, or formatting to the local user's > > expectation could be difficult to achieve. In particular, the > > fractional seconds would be difficult, as predefined locale > > sensitive patterns with fractional seconds are hard to find. > > > > Yoshito, would you let us know if you would like us to file a formal > > request for new pattern letters, please? > > > > Regards, > > -Dan > > I've already filed a ticket to CLDR trac system [ > http://unicode.org/cldr/trac/ticket/5506]. > I'm a CLDR TC member and I've already asked other CLDR TC folks to > look into this. > > I'm going to propose: > > - Add n/N/I to the LDML specification with the definition used by JDK > - Add X for ISO type format, keeping "ZZZZZ" as an alias of XXX (long > ISO) > > We probably ended up to define another letter for what CLDR calls > "locaized GMT format". There is another requirement for supporting > shortest representation of localized GMT format. > > For punctuation variable... In my honest opinion, I think there are > many issues with introducing punctuation variables. > > > -Yoshito From xueming.shen at oracle.com Thu Dec 13 21:00:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Dec 2012 21:00:47 -0800 Subject: [threeten-dev] Pattern letters In-Reply-To: <50CAA45D.6090000@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> Message-ID: <50CAB27F.90003@oracle.com> The pattern letter system is perfect when the format patterns are those year/month/day/hour/minute/second date/time elements, such as "yyyy" "MM dd" or "hh:mm:ss". But it starts to become somewhat strange when various different date/time elements get added and various "styles" get introduced, especially you have to list 9 letters for the nano world and 5 pattern letters but for "narrow form", sometime you will have to say "what the...". Given my j.u.Formatter background, just wonder if it is considerable to add some new syntax to the system, for example let's reserve the { and } pair for various format flag, widht, precision an/or styles {[flags][width][.precision][narrow|short|full]]| narrow, short and full can be the reserved/accepted style name for text, for example E{short} for EEE, E{full} for EEEE and E{narrow} for EEEEE. Personally I feel H{2.2} looks better than the "ppH", and it's attractive to have "-" as the left-justified flag:-) Understand it's a "culture" difference, and understand it's perfect to count the number of pattern letters to have a real "feeling" how the output might look like in most(?) of the cases, but just wonder it might be convenient/cool to have a mixed culture pattern system. We have reserved [ and ] anyway and it's just an addition. It's compatible with neither jdk's existing pattern, nor CLDR though:-) -Sherman From Roger.Riggs at oracle.com Fri Dec 14 06:39:56 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 14 Dec 2012 09:39:56 -0500 Subject: [threeten-dev] Pattern letters In-Reply-To: <50CAB27F.90003@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> <50CAB27F.90003@oracle.com> Message-ID: <50CB3A3C.6060002@oracle.com> Reserving the characters is a good idea, adding them to the set of characters that have to be explicitly quoted to be in the output string. If the {} construct follows the format letter then it will require a lookahead mechanism. The syntax in java.util.Formatter puts the flags, width, precision,etc *before* the conversion letter; making that consistent would make it easier for developers. $.02, Roger On 12/14/2012 12:00 AM, Xueming Shen wrote: > The pattern letter system is perfect when the format patterns are those > year/month/day/hour/minute/second date/time elements, such as "yyyy" > "MM dd" or "hh:mm:ss". But it starts to become somewhat strange when > various different date/time elements get added and various "styles" get > introduced, especially you have to list 9 letters for the nano world > and 5 > pattern letters but for "narrow form", sometime you will have to say > "what > the...". Given my j.u.Formatter background, just wonder if it is > considerable > to add some new syntax to the system, for example let's reserve the { > and } > pair for various format flag, widht, precision an/or styles > > {[flags][width][.precision][narrow|short|full]]| > > narrow, short and full can be the reserved/accepted style name for text, > for example E{short} for EEE, E{full} for EEEE and E{narrow} for EEEEE. > > Personally I feel H{2.2} looks better than the "ppH", and it's > attractive to have > "-" as the left-justified flag:-) > > Understand it's a "culture" difference, and understand it's perfect to > count the > number of pattern letters to have a real "feeling" how the output > might look > like in most(?) of the cases, but just wonder it might be > convenient/cool to have > a mixed culture pattern system. We have reserved [ and ] anyway and > it's just an > addition. > > It's compatible with neither jdk's existing pattern, nor CLDR though:-) > > -Sherman -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From scolebourne at joda.org Fri Dec 14 10:02:09 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Dec 2012 18:02:09 +0000 Subject: [threeten-dev] Pattern letters In-Reply-To: <50CB3A3C.6060002@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> <50CAB27F.90003@oracle.com> <50CB3A3C.6060002@oracle.com> Message-ID: Reserving the characters for a future JDK is a good idea. Make it so! Stephen On 14 December 2012 14:39, Roger Riggs wrote: > Reserving the characters is a good idea, adding them to the set of > characters that have to be explicitly quoted to be in the output string. > > If the {} construct follows the format letter then it will require a > lookahead > mechanism. The syntax in java.util.Formatter puts the flags, width, > precision,etc > *before* the conversion letter; making that consistent would make > it easier for developers. > > $.02, Roger > > > On 12/14/2012 12:00 AM, Xueming Shen wrote: >> >> The pattern letter system is perfect when the format patterns are those >> year/month/day/hour/minute/second date/time elements, such as "yyyy" >> "MM dd" or "hh:mm:ss". But it starts to become somewhat strange when >> various different date/time elements get added and various "styles" get >> introduced, especially you have to list 9 letters for the nano world and 5 >> pattern letters but for "narrow form", sometime you will have to say "what >> the...". Given my j.u.Formatter background, just wonder if it is >> considerable >> to add some new syntax to the system, for example let's reserve the { and >> } >> pair for various format flag, widht, precision an/or styles >> >> {[flags][width][.precision][narrow|short|full]]| >> >> narrow, short and full can be the reserved/accepted style name for text, >> for example E{short} for EEE, E{full} for EEEE and E{narrow} for EEEEE. >> >> Personally I feel H{2.2} looks better than the "ppH", and it's attractive >> to have >> "-" as the left-justified flag:-) >> >> Understand it's a "culture" difference, and understand it's perfect to >> count the >> number of pattern letters to have a real "feeling" how the output might >> look >> like in most(?) of the cases, but just wonder it might be convenient/cool >> to have >> a mixed culture pattern system. We have reserved [ and ] anyway and it's >> just an >> addition. >> >> It's compatible with neither jdk's existing pattern, nor CLDR though:-) >> >> -Sherman > > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From xueming.shen at oracle.com Fri Dec 14 12:44:03 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 12:44:03 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler Message-ID: <50CB8F93.8020108@oracle.com> This is the first draft to pull the tzdb compiler out of the core javax.time.zone package. "Inevitably" it brings the ZoneRulesBulder with it and then the StandardZoneRules and finally the Ser:-) Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely outsource its serialization to the Ser. Arguably, it should be fine to just leave the serialization stuff of these two classes to the default implementation, or further, not serializable at all (any third-party ZoneRules implementation, if any, can feel free to implement their serialization form for these two, if they are needed in their ZoneRules serialization form...). The implementation will be clearer, if we give up the serialization of these two classes. We still keep those read/write of these two for SZR. There are still 2 issues in ZoneOffsetTransition class. The big one is that it appears we have bunch of "transitions" that have the same before and after offset from the builder/compiler, I have not looked into the details of these "transitions". This was being workaround-ed by a package private constructor in ZoneOffsetTransition, need to figure out the best solution. The small one is that the toEpochSecond() method, which is "frequently" used by the builder and the SZR, is it worth make it public, or I should have it as the utility method somewhere in sun.time.zone. The package name of sun.time.zone is picked, just because I don't have a better one for now. The "compiler" itself actually can be anywhere later, probably will be in a "tool" area of jdk, if we indeed decide to make it public. Opinion? the surgery is too big? http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler From Roger.Riggs at oracle.com Fri Dec 14 13:37:40 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 14 Dec 2012 16:37:40 -0500 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CB8F93.8020108@oracle.com> References: <50CB8F93.8020108@oracle.com> Message-ID: <50CB9C24.60906@oracle.com> Hi Sherman, It seems a bit broken that the serialized form is in a sun.* class; it is part of the spec (even indirectly). Is there precedent in other parts of the JDK? If we give up on the serialization of those two classes how does that impact the size of the TZDB? Roger On 12/14/2012 3:44 PM, Xueming Shen wrote: > This is the first draft to pull the tzdb compiler out of the core > javax.time.zone > package. "Inevitably" it brings the ZoneRulesBulder with it and then the > StandardZoneRules and finally the Ser:-) > > Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely > outsource > its serialization to the Ser. Arguably, it should be fine to just > leave the serialization > stuff of these two classes to the default implementation, or further, > not serializable > at all (any third-party ZoneRules implementation, if any, can feel > free to implement > their serialization form for these two, if they are needed in their > ZoneRules serialization > form...). The implementation will be clearer, if we give up the > serialization of these > two classes. We still keep those read/write of these two for SZR. > > There are still 2 issues in ZoneOffsetTransition class. The big one is > that it appears > we have bunch of "transitions" that have the same before and after > offset from the > builder/compiler, I have not looked into the details of these > "transitions". This was being > workaround-ed by a package private constructor in > ZoneOffsetTransition, need to figure > out the best solution. The small one is that the toEpochSecond() > method, which is > "frequently" used by the builder and the SZR, is it worth make it > public, or I should have > it as the utility method somewhere in sun.time.zone. > > The package name of sun.time.zone is picked, just because I don't have > a better one > for now. The "compiler" itself actually can be anywhere later, > probably will be in a > "tool" area of jdk, if we indeed decide to make it public. > > Opinion? the surgery is too big? > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler > > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Fri Dec 14 14:03:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 14:03:47 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CB9C24.60906@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CB9C24.60906@oracle.com> Message-ID: <50CBA243.80905@oracle.com> On 12/14/12 1:37 PM, Roger Riggs wrote: > Hi Sherman, > > It seems a bit broken that the serialized form is in a sun.* class; > it is part of > the spec (even indirectly). Is there precedent in other parts of the JDK? The Ser goes with the StandardZoneRules, so it's not an issue for SZR. It's a little strange to have the ser delegate of ZoneOffsetTransition and ZoneOffsetTransitionRule. One of the reasons I'm suggesting simply dropping the serialization of these two. I don't see too much value-add to have the "independent" serialization form for these two. While they are supposed to be "part" of the ZoneRules, but it's really not necessary to bind their serialization forms together. StandardZoneRules does not have the obligation to build its serialization form on top of the ZOT and ZOTR. There should be no impact to the size or performance of TZDB, even we give up these two. The binary probably will still be the same. The question is do we really want to specify, implement and maintain the customized serialization form for these two classes, is there any benefit/advantage of doing so, compared to not doing so. One argument to do so probably will be "the impl is there, why not just keep it":-) -Sherman > > If we give up on the serialization of those two classes how does that > impact > the size of the TZDB? > > Roger > > > On 12/14/2012 3:44 PM, Xueming Shen wrote: >> This is the first draft to pull the tzdb compiler out of the core >> javax.time.zone >> package. "Inevitably" it brings the ZoneRulesBulder with it and then the >> StandardZoneRules and finally the Ser:-) >> >> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely >> outsource >> its serialization to the Ser. Arguably, it should be fine to just >> leave the serialization >> stuff of these two classes to the default implementation, or further, >> not serializable >> at all (any third-party ZoneRules implementation, if any, can feel >> free to implement >> their serialization form for these two, if they are needed in their >> ZoneRules serialization >> form...). The implementation will be clearer, if we give up the >> serialization of these >> two classes. We still keep those read/write of these two for SZR. >> >> There are still 2 issues in ZoneOffsetTransition class. The big one >> is that it appears >> we have bunch of "transitions" that have the same before and after >> offset from the >> builder/compiler, I have not looked into the details of these >> "transitions". This was being >> workaround-ed by a package private constructor in >> ZoneOffsetTransition, need to figure >> out the best solution. The small one is that the toEpochSecond() >> method, which is >> "frequently" used by the builder and the SZR, is it worth make it >> public, or I should have >> it as the utility method somewhere in sun.time.zone. >> >> The package name of sun.time.zone is picked, just because I don't >> have a better one >> for now. The "compiler" itself actually can be anywhere later, >> probably will be in a >> "tool" area of jdk, if we indeed decide to make it public. >> >> Opinion? the surgery is too big? >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler >> >> > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From xueming.shen at oracle.com Fri Dec 14 14:21:14 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 14:21:14 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CBA243.80905@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CB9C24.60906@oracle.com> <50CBA243.80905@oracle.com> Message-ID: <50CBA65A.3030302@oracle.com> That said, outsourcing the serialization implementation of ZOT/ZOTR to sun.time.zone, together with SZR is just to consolidate those code together, it's perfectly fine/possible to just leave these two with their Ser in javax.time.zone. There is just a little code redundancy here or there. On 12/14/12 2:03 PM, Xueming Shen wrote: > On 12/14/12 1:37 PM, Roger Riggs wrote: >> Hi Sherman, >> >> It seems a bit broken that the serialized form is in a sun.* class; >> it is part of >> the spec (even indirectly). Is there precedent in other parts of the >> JDK? > > The Ser goes with the StandardZoneRules, so it's not an issue for SZR. > It's a little > strange to have the ser delegate of ZoneOffsetTransition and > ZoneOffsetTransitionRule. > One of the reasons I'm suggesting simply dropping the serialization of > these two. > I don't see too much value-add to have the "independent" serialization > form for > these two. While they are supposed to be "part" of the ZoneRules, but > it's really > not necessary to bind their serialization forms together. > StandardZoneRules does > not have the obligation to build its serialization form on top of the > ZOT and ZOTR. > > There should be no impact to the size or performance of TZDB, even we > give up > these two. The binary probably will still be the same. The question is > do we really > want to specify, implement and maintain the customized serialization > form for > these two classes, is there any benefit/advantage of doing so, > compared to not > doing so. One argument to do so probably will be "the impl is there, > why not just > keep it":-) > > -Sherman > >> >> If we give up on the serialization of those two classes how does that >> impact >> the size of the TZDB? >> >> Roger >> >> >> On 12/14/2012 3:44 PM, Xueming Shen wrote: >>> This is the first draft to pull the tzdb compiler out of the core >>> javax.time.zone >>> package. "Inevitably" it brings the ZoneRulesBulder with it and then >>> the >>> StandardZoneRules and finally the Ser:-) >>> >>> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely >>> outsource >>> its serialization to the Ser. Arguably, it should be fine to just >>> leave the serialization >>> stuff of these two classes to the default implementation, or >>> further, not serializable >>> at all (any third-party ZoneRules implementation, if any, can feel >>> free to implement >>> their serialization form for these two, if they are needed in their >>> ZoneRules serialization >>> form...). The implementation will be clearer, if we give up the >>> serialization of these >>> two classes. We still keep those read/write of these two for SZR. >>> >>> There are still 2 issues in ZoneOffsetTransition class. The big one >>> is that it appears >>> we have bunch of "transitions" that have the same before and after >>> offset from the >>> builder/compiler, I have not looked into the details of these >>> "transitions". This was being >>> workaround-ed by a package private constructor in >>> ZoneOffsetTransition, need to figure >>> out the best solution. The small one is that the toEpochSecond() >>> method, which is >>> "frequently" used by the builder and the SZR, is it worth make it >>> public, or I should have >>> it as the utility method somewhere in sun.time.zone. >>> >>> The package name of sun.time.zone is picked, just because I don't >>> have a better one >>> for now. The "compiler" itself actually can be anywhere later, >>> probably will be in a >>> "tool" area of jdk, if we indeed decide to make it public. >>> >>> Opinion? the surgery is too big? >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler >>> >>> >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> > From scolebourne at joda.org Fri Dec 14 14:56:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Dec 2012 22:56:38 +0000 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CB8F93.8020108@oracle.com> References: <50CB8F93.8020108@oracle.com> Message-ID: On 14 December 2012 20:44, Xueming Shen wrote: > This is the first draft to pull the tzdb compiler out of the core > javax.time.zone > package. "Inevitably" it brings the ZoneRulesBulder with it and then the > StandardZoneRules and finally the Ser:-) I would expect the ZoneRulesBuilder to be separated as well, as it is designed in quite a TZDB way. > Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely outsource > its serialization to the Ser. Arguably, it should be fine to just leave the > serialization > stuff of these two classes to the default implementation, or further, not > serializable > at all (any third-party ZoneRules implementation, if any, can feel free to > implement > their serialization form for these two, if they are needed in their > ZoneRules serialization > form...). The implementation will be clearer, if we give up the > serialization of these > two classes. We still keep those read/write of these two for SZR. There is no need for ZOT and ZOTR to be independently serializable. Only the rules themselves need to be serializable. > There are still 2 issues in ZoneOffsetTransition class. The big one is that > it appears > we have bunch of "transitions" that have the same before and after offset > from the > builder/compiler, I have not looked into the details of these "transitions". They are probably due to locations where the time-zone name changed without changing the offset. > The small one is that the toEpochSecond() method, > which is > "frequently" used by the builder and the SZR, is it worth make it public, or > I should have > it as the utility method somewhere in sun.time.zone. There is a case for ZoneRules to have a getOffset(epochSecond) method as well. If the method has to be public then so be it. > Opinion? the surgery is too big? Taking a step back, I think that ZoneRules probably does not need to be an interface. There are only two sensible implementations - single offset and complex, as per StandardZoneRules. If we made this change, then StandardZoneRules and the rules inside ZoneOffset would merge inside ZoneRules. Then, all the serialization would stay in the core. The tool would simply create the necessary items to pass to the standard public factory on ZoneRules. So, what you've done makes sense given where we are, but I think there is a better option. Stephen From xueming.shen at oracle.com Fri Dec 14 15:12:08 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 15:12:08 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: References: <50CB8F93.8020108@oracle.com> Message-ID: <50CBB248.4090505@oracle.com> With Roger's comment, I took a step back to keep the ZOT and ZOTR un-touched for now. To have the sun.time.zone.Ser for SZR only, it appears we can also save one byte as well:-) It should be easy to simply remove the javax.time.Ser and the methods in ZOT and ZOTR, if we decide to let them go. http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler/ -Sherman On 12/14/12 2:56 PM, Stephen Colebourne wrote: > On 14 December 2012 20:44, Xueming Shen wrote: >> This is the first draft to pull the tzdb compiler out of the core >> javax.time.zone >> package. "Inevitably" it brings the ZoneRulesBulder with it and then the >> StandardZoneRules and finally the Ser:-) > I would expect the ZoneRulesBuilder to be separated as well, as it is > designed in quite a TZDB way. > >> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely outsource >> its serialization to the Ser. Arguably, it should be fine to just leave the >> serialization >> stuff of these two classes to the default implementation, or further, not >> serializable >> at all (any third-party ZoneRules implementation, if any, can feel free to >> implement >> their serialization form for these two, if they are needed in their >> ZoneRules serialization >> form...). The implementation will be clearer, if we give up the >> serialization of these >> two classes. We still keep those read/write of these two for SZR. > There is no need for ZOT and ZOTR to be independently serializable. > Only the rules themselves need to be serializable. > >> There are still 2 issues in ZoneOffsetTransition class. The big one is that >> it appears >> we have bunch of "transitions" that have the same before and after offset >> from the >> builder/compiler, I have not looked into the details of these "transitions". > They are probably due to locations where the time-zone name changed > without changing the offset. > >> The small one is that the toEpochSecond() method, >> which is >> "frequently" used by the builder and the SZR, is it worth make it public, or >> I should have >> it as the utility method somewhere in sun.time.zone. > There is a case for ZoneRules to have a getOffset(epochSecond) method > as well. If the method has to be public then so be it. > >> Opinion? the surgery is too big? > Taking a step back, I think that ZoneRules probably does not need to > be an interface. There are only two sensible implementations - single > offset and complex, as per StandardZoneRules. > > If we made this change, then StandardZoneRules and the rules inside > ZoneOffset would merge inside ZoneRules. Then, all the serialization > would stay in the core. The tool would simply create the necessary > items to pass to the standard public factory on ZoneRules. > > So, what you've done makes sense given where we are, but I think there > is a better option. > > Stephen From xueming.shen at oracle.com Fri Dec 14 15:25:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 15:25:13 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: References: <50CB8F93.8020108@oracle.com> Message-ID: <50CBB559.3090508@oracle.com> On 12/14/12 2:56 PM, Stephen Colebourne wrote: >> Opinion? the surgery is too big? > Taking a step back, I think that ZoneRules probably does not need to > be an interface. There are only two sensible implementations - single > offset and complex, as per StandardZoneRules. One benefit of having ZoneRules to be interface is that other implementation does not have to have their implementation bundled with the existing implementation. I was hoping we can get rid of the ZOTR as well, since it's kinda specific to how the tzdb is defined. But if other implementation will have to deal with ZOT and ZOTR anyway, it might not be too bad that they have to build the rule based on the specified constructor/factory method (I'm sure you want to make sure the class ZoneRules to be final as well). Yes, have a concrete ZoneRules with public create and access methods definitely make the life of the compiler tool easier. -Sherman > > If we made this change, then StandardZoneRules and the rules inside > ZoneOffset would merge inside ZoneRules. Then, all the serialization > would stay in the core. The tool would simply create the necessary > items to pass to the standard public factory on ZoneRules. > > So, what you've done makes sense given where we are, but I think there > is a better option. > > From scolebourne at joda.org Fri Dec 14 15:30:47 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Dec 2012 23:30:47 +0000 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CBB559.3090508@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CBB559.3090508@oracle.com> Message-ID: On 14 December 2012 23:25, Xueming Shen wrote: > On 12/14/12 2:56 PM, Stephen Colebourne wrote: >> Taking a step back, I think that ZoneRules probably does not need to >> be an interface. There are only two sensible implementations - single >> offset and complex, as per StandardZoneRules. > > > One benefit of having ZoneRules to be interface is that other implementation > does > not have to have their implementation bundled with the existing > implementation. > I was hoping we can get rid of the ZOTR as well, since it's kinda specific > to how the > tzdb is defined. But if other implementation will have to deal with ZOT and > ZOTR > anyway, it might not be too bad that they have to build the rule based on > the > specified constructor/factory method (I'm sure you want to make sure the > class > ZoneRules to be final as well). With ZOT and ZOTR public with factory methods,it makes sense to have ZoneRules also final. It certainly means that they more clearly justify their place in the API. It also turns out that the internal implementation of StandardZoneRules is complex, and I don't really want others replicating that. So, I find lots of arguments for a class-based ZoneRules and not many for the interface. Stephen > Yes, have a concrete ZoneRules with public create and access methods > definitely > make the life of the compiler tool easier. > > -Sherman > >> >> If we made this change, then StandardZoneRules and the rules inside >> ZoneOffset would merge inside ZoneRules. Then, all the serialization >> would stay in the core. The tool would simply create the necessary >> items to pass to the standard public factory on ZoneRules. >> >> So, what you've done makes sense given where we are, but I think there >> is a better option. >> >> > > > From xueming.shen at oracle.com Fri Dec 14 15:32:45 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 15:32:45 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CBB248.4090505@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CBB248.4090505@oracle.com> Message-ID: <50CBB71D.9000101@oracle.com> If StandardZoneRules is the only class needed to be serializable in zone package, Isn't Ser delegation no longer necessary? it has a short name for sure. -Sherman On 12/14/12 3:12 PM, Xueming Shen wrote: > With Roger's comment, I took a step back to keep the ZOT and ZOTR > un-touched for > now. To have the sun.time.zone.Ser for SZR only, it appears we can > also save one byte > as well:-) It should be easy to simply remove the javax.time.Ser and > the methods in > ZOT and ZOTR, if we decide to let them go. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler/ > > -Sherman > > On 12/14/12 2:56 PM, Stephen Colebourne wrote: >> On 14 December 2012 20:44, Xueming Shen wrote: >>> This is the first draft to pull the tzdb compiler out of the core >>> javax.time.zone >>> package. "Inevitably" it brings the ZoneRulesBulder with it and then >>> the >>> StandardZoneRules and finally the Ser:-) >> I would expect the ZoneRulesBuilder to be separated as well, as it is >> designed in quite a TZDB way. >> >>> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely >>> outsource >>> its serialization to the Ser. Arguably, it should be fine to just >>> leave the >>> serialization >>> stuff of these two classes to the default implementation, or >>> further, not >>> serializable >>> at all (any third-party ZoneRules implementation, if any, can feel >>> free to >>> implement >>> their serialization form for these two, if they are needed in their >>> ZoneRules serialization >>> form...). The implementation will be clearer, if we give up the >>> serialization of these >>> two classes. We still keep those read/write of these two for SZR. >> There is no need for ZOT and ZOTR to be independently serializable. >> Only the rules themselves need to be serializable. >> >>> There are still 2 issues in ZoneOffsetTransition class. The big one >>> is that >>> it appears >>> we have bunch of "transitions" that have the same before and after >>> offset >>> from the >>> builder/compiler, I have not looked into the details of these >>> "transitions". >> They are probably due to locations where the time-zone name changed >> without changing the offset. >> >>> The small one is that the toEpochSecond() method, >>> which is >>> "frequently" used by the builder and the SZR, is it worth make it >>> public, or >>> I should have >>> it as the utility method somewhere in sun.time.zone. >> There is a case for ZoneRules to have a getOffset(epochSecond) method >> as well. If the method has to be public then so be it. >> >>> Opinion? the surgery is too big? >> Taking a step back, I think that ZoneRules probably does not need to >> be an interface. There are only two sensible implementations - single >> offset and complex, as per StandardZoneRules. >> >> If we made this change, then StandardZoneRules and the rules inside >> ZoneOffset would merge inside ZoneRules. Then, all the serialization >> would stay in the core. The tool would simply create the necessary >> items to pass to the standard public factory on ZoneRules. >> >> So, what you've done makes sense given where we are, but I think there >> is a better option. >> >> Stephen > From xueming.shen at oracle.com Fri Dec 14 15:55:31 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 15:55:31 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: References: <50CB8F93.8020108@oracle.com> <50CBB559.3090508@oracle.com> Message-ID: <50CBBC73.6070803@oracle.com> On 12/14/12 3:30 PM, Stephen Colebourne wrote: > On 14 December 2012 23:25, Xueming Shen wrote: >> On 12/14/12 2:56 PM, Stephen Colebourne wrote: >>> Taking a step back, I think that ZoneRules probably does not need to >>> be an interface. There are only two sensible implementations - single >>> offset and complex, as per StandardZoneRules. >> >> One benefit of having ZoneRules to be interface is that other implementation >> does >> not have to have their implementation bundled with the existing >> implementation. >> I was hoping we can get rid of the ZOTR as well, since it's kinda specific >> to how the >> tzdb is defined. But if other implementation will have to deal with ZOT and >> ZOTR >> anyway, it might not be too bad that they have to build the rule based on >> the >> specified constructor/factory method (I'm sure you want to make sure the >> class >> ZoneRules to be final as well). > With ZOT and ZOTR public with factory methods,it makes sense to have > ZoneRules also final. It certainly means that they more clearly > justify their place in the API. I'm OK with the change. Btw, is TzdbZoneRuleProvider public by purpose? or just an accident. I don't think this one need to be public. -Sherman > > It also turns out that the internal implementation of > StandardZoneRules is complex, and I don't really want others > replicating that. So, I find lots of arguments for a class-based > ZoneRules and not many for the interface. > > Stephen > > >> Yes, have a concrete ZoneRules with public create and access methods >> definitely >> make the life of the compiler tool easier. >> >> -Sherman >> >>> If we made this change, then StandardZoneRules and the rules inside >>> ZoneOffset would merge inside ZoneRules. Then, all the serialization >>> would stay in the core. The tool would simply create the necessary >>> items to pass to the standard public factory on ZoneRules. >>> >>> So, what you've done makes sense given where we are, but I think there >>> is a better option. >>> >>> >> >> From scolebourne at joda.org Fri Dec 14 16:04:44 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 15 Dec 2012 00:04:44 +0000 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CBBC73.6070803@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CBB559.3090508@oracle.com> <50CBBC73.6070803@oracle.com> Message-ID: On 14 December 2012 23:55, Xueming Shen wrote: > Btw, is TzdbZoneRuleProvider public by purpose? or just an accident. I don't > think this one need to be public. It is public for the service loader. If not using service loader, then it should not be public. Stephen From xueming.shen at oracle.com Fri Dec 14 16:44:11 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Dec 2012 16:44:11 -0800 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: References: <50CB8F93.8020108@oracle.com> <50CBB559.3090508@oracle.com> <50CBBC73.6070803@oracle.com> Message-ID: <50CBC7DB.5060200@oracle.com> I don't think we are going to load the default tzdb provider via service loader. It needs to be hardwired for the best performance. On 12/14/12 4:04 PM, Stephen Colebourne wrote: > On 14 December 2012 23:55, Xueming Shen wrote: >> Btw, is TzdbZoneRuleProvider public by purpose? or just an accident. I don't >> think this one need to be public. > It is public for the service loader. If not using service loader, then > it should not be public. > > Stephen From xueming.shen at oracle.com Fri Dec 14 16:55:07 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 15 Dec 2012 00:55:07 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Changed TzdbZoneRulesProvider to be package private. Message-ID: <20121215005547.820F847189@hg.openjdk.java.net> Changeset: 8a591052a42a Author: sherman Date: 2012-12-14 16:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8a591052a42a Changed TzdbZoneRulesProvider to be package private. ! src/share/classes/javax/time/zone/TzdbZoneRulesProvider.java From scolebourne at joda.org Sat Dec 15 00:17:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 15 Dec 2012 08:17:38 +0000 Subject: [threeten-dev] TzdbZoneRulesCompiler In-Reply-To: <50CBC7DB.5060200@oracle.com> References: <50CB8F93.8020108@oracle.com> <50CBB559.3090508@oracle.com> <50CBBC73.6070803@oracle.com> <50CBC7DB.5060200@oracle.com> Message-ID: Sherman, you are fre to make whatever changes are needed to the zone rules provider service loader or TZDB provider to fit best with OpenJDK. Stephen On 15 December 2012 00:44, Xueming Shen wrote: > I don't think we are going to load the default tzdb provider via service > loader. It > needs to be hardwired for the best performance. > > > On 12/14/12 4:04 PM, Stephen Colebourne wrote: >> >> On 14 December 2012 23:55, Xueming Shen wrote: >>> >>> Btw, is TzdbZoneRuleProvider public by purpose? or just an accident. I >>> don't >>> think this one need to be public. >> >> It is public for the service loader. If not using service loader, then >> it should not be public. >> >> Stephen > > From scolebourne at joda.org Sun Dec 16 15:33:33 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sun, 16 Dec 2012 23:33:33 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20121216233447.7AC25471B2@hg.openjdk.java.net> Changeset: 4bd268cd84b0 Author: scolebourne Date: 2012-12-16 12:27 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4bd268cd84b0 Renamed ZoneDateTime back to ZonedDateTime ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java Changeset: 7b0917b2b5d6 Author: scolebourne Date: 2012-12-16 13:50 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7b0917b2b5d6 Javadoc atXxx() methods ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java Changeset: dbf1cb4de3b5 Author: scolebourne Date: 2012-12-16 23:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/dbf1cb4de3b5 Re-integrate Offset* classes See #167 ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java Changeset: e9482b5d0440 Author: scolebourne Date: 2012-12-16 23:26 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e9482b5d0440 Javadoc ! src/share/classes/javax/time/OffsetDateTime.java From Roger.Riggs at Oracle.com Sun Dec 16 20:29:34 2012 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sun, 16 Dec 2012 23:29:34 -0500 Subject: [threeten-dev] Add support for pattern letters 'e', 'w', 'W' that use locale dependent fields Message-ID: <50CE9FAE.504@Oracle.com> Hi, Issue 39 DateTimeFormatterBuilder: doesn't accept pattern with "w" Should be resolved with this change: http://cr.openjdk.java.net/~rriggs/webrev-patterns/ Comments appreciated. From scolebourne at joda.org Mon Dec 17 03:02:57 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 11:02:57 +0000 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: <50CAA45D.6090000@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> Message-ID: On 14 December 2012 04:00, Dan Chiba wrote: > Thank you for filing the CLDR ticket. Your proposal sounds great. May I ask > the status of the shortest GMT format? When could it be implemented by > vendors? > > As for punctuations, I think comma and dot are already locale sensitive for > number formatting, so it would be easy for people to understand how the > locale sensitive punctuations for date time formatting work. Because the > predefined formatting patterns for locales have the separators for date and > time fields and they are commonly used, it doesn't seem to be an issue that > there is no locale sensitive pattern letter for them. So I think I am only > interested in the decimal separator for fractional seconds. Alternatively, > if CLDR had predefined locale sensitive patterns with fractional seconds, > that could also be a solution. For instance, a predefined common pattern to > print hour, minute, second and millisecond for the US locale may look like > this: > > HH:mm:ss.SSS For everyones info, we previously had a letter "f", which meant output a fraction with a localized decimal point HH:mm:ss.SSS - always use dot HH:mm:ssfSSS - use localized decimal point (old JSR-310) HH:mm:ssfff - possible localized decimal point alternative in JSR-310 we used "f" for exact length and "ff" for up to nanos length: HH:mm:ssfSSS - print 3 digit fraction HH:mm:ssfSS - print 2 digit fraction HH:mm:ssffSSS - print at least 3 digits and a maximum of 9 We don't have "f" right now, but there is the germ of a good idea in there. > Would you elaborate what "p" (prefix for padding) does? Does it make sense > to have it defined in LDML as well? Some examples: MMM-dd -> "Dec-07" MMM-d -> "Dec-7" MMM-ppd -> "Dec-*7" MMM-pppd -> "Dec-**7" (using * instead of space for clarity in this email) So, the "p" pattern letter means "pad the next field with spaces on the left to a width determined by the number of p characters". Thus "pp" means "pad the next field to a width of 2. I can't think how a pad width of 1 would be useful however, so it would be clearer to reduce the "p" level by one: MMM-pd -> "Dec-*7" MMM-ppd -> "Dec-**7" That would make "p" mean "pad the next field with spaces on the left to a width determined by the total of the number of p and value characters". So, "p" now means "pad the next field to a width of 2. It would be good to see "p" in LDML. We would need to agree on one of the two definitions above. > Also, do you think 310 can suppor the shortest GMT format if its status is > ready for implementation? If the data is available in Java, we can find a way to support it, time permitting. Stephen From scolebourne at joda.org Mon Dec 17 03:47:06 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 11:47:06 +0000 Subject: [threeten-dev] Add support for pattern letters 'e', 'w', 'W' that use locale dependent fields In-Reply-To: <50CE9FAE.504@Oracle.com> References: <50CE9FAE.504@Oracle.com> Message-ID: I'm not sure why "appendWeekBasedField()" is needed. I think it can be inlined. The instance variables in WeekBasedFieldPrinterParser should be private. FYI, the test in TCKDateTimeFormatterBuilder at line 711 that you updated should not be a TCK test, as it evaluates against the toString() format of the internal printer/parsers, which is not defined in the spec. Is there anything stopping the two new tests from being TCK tests? Otherwsie looks good. I suggest pushing. Stephen On 17 December 2012 04:29, Roger Riggs wrote: > Hi, > > Issue 39 DateTimeFormatterBuilder: doesn't accept pattern with "w" > > > Should be resolved with this change: > > http://cr.openjdk.java.net/~rriggs/webrev-patterns/ > > Comments appreciated. From scolebourne at joda.org Mon Dec 17 08:28:05 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 17 Dec 2012 16:28:05 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121217162909.26DDC471D7@hg.openjdk.java.net> Changeset: 540b331fd299 Author: scolebourne Date: 2012-12-17 12:09 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/540b331fd299 Fixup spelling and checkstyle level nits ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/javax/time/format/DateTimeFormatSymbols.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! src/share/classes/javax/time/format/DateTimeTextProvider.java Changeset: 5b2a3c0da3ca Author: scolebourne Date: 2012-12-17 15:40 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5b2a3c0da3ca Javadoc ! src/share/classes/javax/time/calendrical/DateTime.java Changeset: 748452702d26 Author: scolebourne Date: 2012-12-17 15:56 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/748452702d26 Add firstMonthOfQuarter() Basic support for quarters See #170 ! src/share/classes/javax/time/Month.java ! test/javax/time/tck/javax/time/TCKMonth.java From Roger.Riggs at oracle.com Mon Dec 17 08:46:47 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 17 Dec 2012 11:46:47 -0500 Subject: [threeten-dev] Add support for pattern letters 'e', 'w', 'W' that use locale dependent fields In-Reply-To: References: <50CE9FAE.504@Oracle.com> Message-ID: <50CF4C77.5090001@oracle.com> Hi Stephen, On 12/17/2012 6:47 AM, Stephen Colebourne wrote: > I'm not sure why "appendWeekBasedField()" is needed. I think it can be inlined. ok, the pattern seemed to be to have an append method (public) but that can't be supported because there is no way to identify the localized field in the public API. So locale based pattern support will be private. > > The instance variables in WeekBasedFieldPrinterParser should be private. ok > > FYI, the test in TCKDateTimeFormatterBuilder at line 711 that you > updated should not be a TCK test, as it evaluates against the > toString() format of the internal printer/parsers, which is not > defined in the spec. Will flag it as implementation for how. > > Is there anything stopping the two new tests from being TCK tests? will move them. Many tests that use internals will need to be updated with the move to java.time. > > Otherwise looks good. I suggest pushing. ok, with some updates. Roger > > Stephen > > > On 17 December 2012 04:29, Roger Riggs wrote: >> Hi, >> >> Issue 39 DateTimeFormatterBuilder: doesn't accept pattern with "w" >> >> >> Should be resolved with this change: >> >> http://cr.openjdk.java.net/~rriggs/webrev-patterns/ >> >> Comments appreciated. -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From roger.riggs at oracle.com Mon Dec 17 08:46:13 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 17 Dec 2012 16:46:13 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets Message-ID: <20121217164712.1C204471DD@hg.openjdk.java.net> Changeset: 405c2128ed34 Author: rriggs Date: 2012-12-16 20:50 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/405c2128ed34 Implement pattern letters 'e', 'w', 'W' using locale based fields from WeekDefinition. Resolves issue 39 ! src/share/classes/javax/time/calendrical/WeekDefinition.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java ! test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java + test/javax/time/test/javax/time/format/TestLocalizedFieldParser.java + test/javax/time/test/javax/time/format/TestLocalizedFieldPrinter.java Changeset: 11e6518881e9 Author: rriggs Date: 2012-12-16 20:53 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/11e6518881e9 Merge ! src/share/classes/javax/time/calendrical/WeekDefinition.java Changeset: eafb7073904b Author: rriggs Date: 2012-12-16 23:18 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/eafb7073904b Merge - src/share/classes/javax/time/ZoneDateTime.java - src/share/classes/javax/time/chrono/ChronoZoneDateTime.java - src/share/classes/javax/time/chrono/ChronoZoneDateTimeImpl.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java - test/javax/time/resources/ZoneDateTime.bin - test/javax/time/tck/javax/time/TCKZoneDateTime.java - test/javax/time/tck/javax/time/chrono/TestChronoZoneDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java Changeset: b35837e09b95 Author: rriggs Date: 2012-12-17 11:43 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b35837e09b95 Cleanup of DateTimeFormatterBuilder and moved tests to TCK ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java + test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java + test/javax/time/tck/javax/time/format/TCKLocalizedFieldPrinter.java - test/javax/time/test/javax/time/format/TestLocalizedFieldParser.java - test/javax/time/test/javax/time/format/TestLocalizedFieldPrinter.java Changeset: 350d556a9b44 Author: rriggs Date: 2012-12-17 11:45 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/350d556a9b44 Merge ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java From scolebourne at joda.org Mon Dec 17 09:01:41 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 17:01:41 +0000 Subject: [threeten-dev] Add support for pattern letters 'e', 'w', 'W' that use locale dependent fields In-Reply-To: <50CF4C77.5090001@oracle.com> References: <50CE9FAE.504@Oracle.com> <50CF4C77.5090001@oracle.com> Message-ID: On 17 December 2012 16:46, Roger Riggs wrote: > On 12/17/2012 6:47 AM, Stephen Colebourne wrote: > I'm not sure why "appendWeekBasedField()" is needed. I think it can be > inlined. > > ok, the pattern seemed to be to have an append method (public) but that > can't be supported because there is no way to identify the localized field > in the public API. So locale based pattern support will be private. Developers wanting this can just call appendPattern("e"). So, the feature is available ;-) Stephen From scolebourne at joda.org Mon Dec 17 08:41:30 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 17 Dec 2012 16:41:30 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Better firstMonthOfQuarter() implementation Message-ID: <20121217164143.6AA9F471DA@hg.openjdk.java.net> Changeset: 557036c01aba Author: scolebourne Date: 2012-12-17 16:38 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/557036c01aba Better firstMonthOfQuarter() implementation ! src/share/classes/javax/time/Month.java From scolebourne at joda.org Mon Dec 17 09:06:15 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 17:06:15 +0000 Subject: [threeten-dev] Temporal Message-ID: Javadoc for review of proposed change http://threeten.github.com/threeten/dev/temporal/ I went with DateTimeAccessor -> TemporalAccessor DateTime -> Temporal DateTimeField -> TemporalField PeriodUnit -> TemporalUnit DateTimeValueRange -> TemporalValueRange DateTimeAdjusters -> Adjusters Javadoc talks about "temporal objects" I might be willing to shorten TemporalValueRange to ValueRange. Any last thoughts... Stephen From scolebourne at joda.org Mon Dec 17 10:20:16 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 18:20:16 +0000 Subject: [threeten-dev] Temporal In-Reply-To: References: Message-ID: Note that we are also planning on making package changes at the same time. New package structure javax.time javax.time.temporal <- currently calendrical and chrono javax.time.format javax.time.zone javax.time.calendar <- currently chrono.global (Work on these changes is now starting) Stephen On 17 December 2012 17:06, Stephen Colebourne wrote: > Javadoc for review of proposed change > http://threeten.github.com/threeten/dev/temporal/ > > I went with > DateTimeAccessor -> TemporalAccessor > DateTime -> Temporal > DateTimeField -> TemporalField > PeriodUnit -> TemporalUnit > DateTimeValueRange -> TemporalValueRange > DateTimeAdjusters -> Adjusters > > Javadoc talks about "temporal objects" > > I might be willing to shorten TemporalValueRange to ValueRange. > > Any last thoughts... > Stephen From dan.chiba at oracle.com Mon Dec 17 13:22:10 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Mon, 17 Dec 2012 13:22:10 -0800 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> Message-ID: <50CF8D02.5080605@oracle.com> Yoshito, May I ask if we could file a LDMR enhancement for "f" and "p", is this something you could add to the ticket #5506? Stephen, For the shortest GMT format, there is only a slight possibility for JDK8 to support it, in case the status of CLDR is ready and JSR-310 can afford the engineering cost in time. I just put an Github issue to track this fix as #173 . Please put an RFE or other appropriate tag on it. Regards, -Dan On 12/17/2012 3:02 AM, Stephen Colebourne wrote: > On 14 December 2012 04:00, Dan Chiba wrote: >> Thank you for filing the CLDR ticket. Your proposal sounds great. May I ask >> the status of the shortest GMT format? When could it be implemented by >> vendors? >> >> As for punctuations, I think comma and dot are already locale sensitive for >> number formatting, so it would be easy for people to understand how the >> locale sensitive punctuations for date time formatting work. Because the >> predefined formatting patterns for locales have the separators for date and >> time fields and they are commonly used, it doesn't seem to be an issue that >> there is no locale sensitive pattern letter for them. So I think I am only >> interested in the decimal separator for fractional seconds. Alternatively, >> if CLDR had predefined locale sensitive patterns with fractional seconds, >> that could also be a solution. For instance, a predefined common pattern to >> print hour, minute, second and millisecond for the US locale may look like >> this: >> >> HH:mm:ss.SSS > For everyones info, we previously had a letter "f", which meant output > a fraction with a localized decimal point > > HH:mm:ss.SSS - always use dot > HH:mm:ssfSSS - use localized decimal point (old JSR-310) > HH:mm:ssfff - possible localized decimal point alternative > > in JSR-310 we used "f" for exact length and "ff" for up to nanos length: > HH:mm:ssfSSS - print 3 digit fraction > HH:mm:ssfSS - print 2 digit fraction > HH:mm:ssffSSS - print at least 3 digits and a maximum of 9 > > We don't have "f" right now, but there is the germ of a good idea in there. > >> Would you elaborate what "p" (prefix for padding) does? Does it make sense >> to have it defined in LDML as well? > Some examples: > > MMM-dd -> "Dec-07" > MMM-d -> "Dec-7" > MMM-ppd -> "Dec-*7" > MMM-pppd -> "Dec-**7" > > (using * instead of space for clarity in this email) > > So, the "p" pattern letter means "pad the next field with spaces on > the left to a width determined by the number of p characters". Thus > "pp" means "pad the next field to a width of 2. > > I can't think how a pad width of 1 would be useful however, so it > would be clearer to reduce the "p" level by one: > > MMM-pd -> "Dec-*7" > MMM-ppd -> "Dec-**7" > > That would make "p" mean "pad the next field with spaces on the left > to a width determined by the total of the number of p and value > characters". > > So, "p" now means "pad the next field to a width of 2. > > It would be good to see "p" in LDML. We would need to agree on one of > the two definitions above. > >> Also, do you think 310 can suppor the shortest GMT format if its status is >> ready for implementation? > If the data is available in Java, we can find a way to support it, > time permitting. > > Stephen From dan.chiba at oracle.com Mon Dec 17 14:10:25 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Mon, 17 Dec 2012 14:10:25 -0800 Subject: [threeten-dev] Islamic calendar variants need disambiguation Message-ID: <50CF9851.2060804@oracle.com> Yoshito-san, I would like to get your opinion about identifying Islamic calendar variants in CLDR. It defines "islamic" and "islamicc" in calendar.xml for the astronomical and algorithmic variants respectively, while JSR-310 needs to clearly identify the variants and distinctively identify each of them, in order to identify the dates correctly. For example, the Umm Al-Qura calendar and Microsoft's Islamic calendar implementation with the Kuwaiti algorithm are both algorithmic but they are different, so the date information is not interchangeable under "islamicc" between different variants. A date in one variant may correspond to a different date in another variant. So, in terms of ensuring correct exchange of Islamic date information, not identifying the precise variants in the CLDR name space falls short of the use case expectation. In JSR-310, we anticipate Islamic end users might have their preferred Islamic calendar variant set in their user profile, or an application may be supporting different variants in producing some output with Islamic date information. May I ask if there is a chance to add more Islamic calendar variants or enhance the calendar naming scheme to resolve this issue? Or is this beyond the scope of CLDR? Do you suggest taking this to the CLDR list? Regards, -Dan From scolebourne at joda.org Mon Dec 17 15:02:03 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 17 Dec 2012 23:02:03 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 11 new changesets Message-ID: <20121217230415.ABE6B471F8@hg.openjdk.java.net> Changeset: 8d10ff8fe9fd Author: scolebourne Date: 2012-12-17 18:55 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d10ff8fe9fd Rename global package to calendar + src/share/classes/javax/time/calendar/ChronoDateImpl.java + src/share/classes/javax/time/calendar/HijrahChrono.java + src/share/classes/javax/time/calendar/HijrahDate.java + src/share/classes/javax/time/calendar/HijrahEra.java + src/share/classes/javax/time/calendar/JapaneseChrono.java + src/share/classes/javax/time/calendar/JapaneseDate.java + src/share/classes/javax/time/calendar/JapaneseEra.java + src/share/classes/javax/time/calendar/MinguoChrono.java + src/share/classes/javax/time/calendar/MinguoDate.java + src/share/classes/javax/time/calendar/MinguoEra.java + src/share/classes/javax/time/calendar/Ser.java + src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java + src/share/classes/javax/time/calendar/ThaiBuddhistDate.java + src/share/classes/javax/time/calendar/ThaiBuddhistEra.java + src/share/classes/javax/time/calendar/package.html - src/share/classes/javax/time/chrono/global/ChronoDateImpl.java - src/share/classes/javax/time/chrono/global/HijrahChrono.java - src/share/classes/javax/time/chrono/global/HijrahDate.java - src/share/classes/javax/time/chrono/global/HijrahEra.java - src/share/classes/javax/time/chrono/global/JapaneseChrono.java - src/share/classes/javax/time/chrono/global/JapaneseDate.java - src/share/classes/javax/time/chrono/global/JapaneseEra.java - src/share/classes/javax/time/chrono/global/MinguoChrono.java - src/share/classes/javax/time/chrono/global/MinguoDate.java - src/share/classes/javax/time/chrono/global/MinguoEra.java - src/share/classes/javax/time/chrono/global/Ser.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java - src/share/classes/javax/time/chrono/global/package.html ! src/share/classes/javax/time/overview.html + test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java + test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java + test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java + test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java + test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java + test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java ! test/javax/time/tck/javax/time/chrono/TestChrono.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java - test/javax/time/tck/javax/time/chrono/global/TestHijrahChrono.java - test/javax/time/tck/javax/time/chrono/global/TestJapaneseChrono.java - test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java - test/javax/time/tck/javax/time/chrono/global/TestThaiBuddhistChrono.java ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java Changeset: b735c715d573 Author: scolebourne Date: 2012-12-17 19:11 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b735c715d573 Rename calendrical package to temporal ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDate.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/JapaneseDate.java ! src/share/classes/javax/time/calendar/JapaneseEra.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/MinguoDate.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java - src/share/classes/javax/time/calendrical/ChronoField.java - src/share/classes/javax/time/calendrical/ChronoUnit.java - src/share/classes/javax/time/calendrical/DateTime.java - src/share/classes/javax/time/calendrical/DateTimeAccessor.java - src/share/classes/javax/time/calendrical/DateTimeAdjusters.java - src/share/classes/javax/time/calendrical/DateTimeBuilder.java - src/share/classes/javax/time/calendrical/DateTimeField.java - src/share/classes/javax/time/calendrical/DateTimeValueRange.java - src/share/classes/javax/time/calendrical/ISOWeeks.java - src/share/classes/javax/time/calendrical/JulianDayField.java - src/share/classes/javax/time/calendrical/PeriodUnit.java - src/share/classes/javax/time/calendrical/WeekDefinition.java - src/share/classes/javax/time/calendrical/package.html ! src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/chrono/Era.java ! src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/chrono/ISOEra.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! src/share/classes/javax/time/format/DateTimeTextProvider.java ! src/share/classes/javax/time/overview.html ! src/share/classes/javax/time/package.html + src/share/classes/javax/time/temporal/ChronoField.java + src/share/classes/javax/time/temporal/ChronoUnit.java + src/share/classes/javax/time/temporal/DateTime.java + src/share/classes/javax/time/temporal/DateTimeAccessor.java + src/share/classes/javax/time/temporal/DateTimeAdjusters.java + src/share/classes/javax/time/temporal/DateTimeBuilder.java + src/share/classes/javax/time/temporal/DateTimeField.java + src/share/classes/javax/time/temporal/DateTimeValueRange.java + src/share/classes/javax/time/temporal/ISOWeeks.java + src/share/classes/javax/time/temporal/JulianDayField.java + src/share/classes/javax/time/temporal/PeriodUnit.java + src/share/classes/javax/time/temporal/WeekDefinition.java + src/share/classes/javax/time/temporal/package.html ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKDuration.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java - test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java - test/javax/time/tck/javax/time/calendrical/TCKISOWeeks.java - test/javax/time/tck/javax/time/calendrical/TCKJulianDayField.java - test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java - test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java - test/javax/time/tck/javax/time/calendrical/TCKYear.java - test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java ! test/javax/time/tck/javax/time/chrono/TestChrono.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldPrinter.java + test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java + test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java + test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java + test/javax/time/tck/javax/time/temporal/TCKMonthDay.java + test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java + test/javax/time/tck/javax/time/temporal/TCKYear.java + test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java ! test/javax/time/test/java/util/TestFormatter.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java ! test/javax/time/test/javax/time/MockSimplePeriod.java ! test/javax/time/test/javax/time/TestDayOfWeek.java ! test/javax/time/test/javax/time/TestInstant.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestMonth.java ! test/javax/time/test/javax/time/TestOffsetDateTime.java ! test/javax/time/test/javax/time/TestPeriod.java ! test/javax/time/test/javax/time/TestPeriodParser.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/TestZoneOffset.java - test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java - test/javax/time/test/javax/time/calendrical/MockFieldValue.java - test/javax/time/test/javax/time/calendrical/TestChronoUnit.java - test/javax/time/test/javax/time/calendrical/TestDateTimeAdjusters.java - test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java - test/javax/time/test/javax/time/calendrical/TestDateTimeValueRange.java - test/javax/time/test/javax/time/calendrical/TestMonthDay.java - test/javax/time/test/javax/time/calendrical/TestYear.java - test/javax/time/test/javax/time/calendrical/TestYearMonth.java ! test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestCharLiteralParser.java ! test/javax/time/test/javax/time/format/TestDateTimeFormatter.java ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java ! test/javax/time/test/javax/time/format/TestNumberParser.java ! test/javax/time/test/javax/time/format/TestNumberPrinter.java ! test/javax/time/test/javax/time/format/TestPadParserDecorator.java ! test/javax/time/test/javax/time/format/TestReducedParser.java ! test/javax/time/test/javax/time/format/TestReducedPrinter.java ! test/javax/time/test/javax/time/format/TestStringLiteralParser.java ! test/javax/time/test/javax/time/format/TestTextParser.java ! test/javax/time/test/javax/time/format/TestTextPrinter.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java + test/javax/time/test/javax/time/temporal/MockFieldNoValue.java + test/javax/time/test/javax/time/temporal/MockFieldValue.java + test/javax/time/test/javax/time/temporal/TestChronoUnit.java + test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java + test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java + test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java + test/javax/time/test/javax/time/temporal/TestMonthDay.java + test/javax/time/test/javax/time/temporal/TestYear.java + test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: 29c29abd5588 Author: scolebourne Date: 2012-12-17 19:36 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/29c29abd5588 Rename chrono package to temporal ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDate.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/JapaneseDate.java ! src/share/classes/javax/time/calendar/JapaneseEra.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/MinguoDate.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/calendar/package.html - src/share/classes/javax/time/chrono/Ser.java - src/share/classes/javax/time/chrono/package.html ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/overview.html ! src/share/classes/javax/time/temporal/Chrono.java < src/share/classes/javax/time/chrono/Chrono.java ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java < src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java ! src/share/classes/javax/time/temporal/ChronoField.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java < src/share/classes/javax/time/chrono/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java < src/share/classes/javax/time/chrono/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java < src/share/classes/javax/time/chrono/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java < src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/temporal/DateTimeAccessor.java ! src/share/classes/javax/time/temporal/DateTimeBuilder.java ! src/share/classes/javax/time/temporal/Era.java < src/share/classes/javax/time/chrono/Era.java ! src/share/classes/javax/time/temporal/ISOChrono.java < src/share/classes/javax/time/chrono/ISOChrono.java ! src/share/classes/javax/time/temporal/ISOEra.java < src/share/classes/javax/time/chrono/ISOEra.java + src/share/classes/javax/time/temporal/Ser.java ! src/share/classes/javax/time/temporal/WeekDefinition.java ! src/share/classes/javax/time/temporal/package.html ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java ! test/javax/time/tck/javax/time/temporal/TestChrono.java < test/javax/time/tck/javax/time/chrono/TestChrono.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java < test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java < test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java < test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java < test/javax/time/tck/javax/time/chrono/TestISOChrono.java ! test/javax/time/test/javax/time/temporal/TestISOChronoImpl.java < test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java < test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java ! test/javax/time/test/javax/time/temporal/TestThaiBuddhistChronoImpl.java < test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java Changeset: c9f5a3859101 Author: scolebourne Date: 2012-12-17 20:05 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9f5a3859101 Move base classes to temporal ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java - src/share/classes/javax/time/OffsetDateTime.java - src/share/classes/javax/time/OffsetTime.java ! src/share/classes/javax/time/Ser.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java ! src/share/classes/javax/time/temporal/DateTimeAccessor.java ! src/share/classes/javax/time/temporal/MonthDay.java < src/share/classes/javax/time/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java < src/share/classes/javax/time/OffsetDate.java + src/share/classes/javax/time/temporal/OffsetDateTime.java + src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Ser.java ! src/share/classes/javax/time/temporal/Year.java < src/share/classes/javax/time/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java < src/share/classes/javax/time/YearMonth.java ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! test/javax/time/resources/MonthDay.bin ! test/javax/time/resources/OffsetDate.bin ! test/javax/time/resources/OffsetDateTime.bin ! test/javax/time/resources/OffsetTime.bin ! test/javax/time/resources/Year.bin ! test/javax/time/resources/YearMonth.bin ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java - test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java < test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java < test/javax/time/tck/javax/time/TCKOffsetDateTime.java + test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java ! test/javax/time/test/java/util/TestFormatter.java ! test/javax/time/test/javax/time/AbstractTest.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java - test/javax/time/test/javax/time/TestOffsetDateTime.java - test/javax/time/test/javax/time/TestOffsetDateTime_instants.java ! test/javax/time/test/javax/time/TestPeriod.java ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java + test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java + test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java Changeset: 5127fd3d37f8 Author: scolebourne Date: 2012-12-17 20:22 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5127fd3d37f8 Rename DateTime and accessor to Temporal ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java ! src/share/classes/javax/time/temporal/ChronoField.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/javax/time/temporal/DateTime.java ! src/share/classes/javax/time/temporal/DateTimeAdjusters.java ! src/share/classes/javax/time/temporal/DateTimeBuilder.java ! src/share/classes/javax/time/temporal/DateTimeField.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOChrono.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/ISOWeeks.java ! src/share/classes/javax/time/temporal/JulianDayField.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/PeriodUnit.java + src/share/classes/javax/time/temporal/Temporal.java = src/share/classes/javax/time/temporal/TemporalAccessor.java < src/share/classes/javax/time/temporal/DateTimeAccessor.java ! src/share/classes/javax/time/temporal/WeekDefinition.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java ! test/javax/time/test/javax/time/MockSimplePeriod.java ! test/javax/time/test/javax/time/TestDayOfWeek.java ! test/javax/time/test/javax/time/TestInstant.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestMonth.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/TestZoneOffset.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java ! test/javax/time/test/javax/time/temporal/MockFieldValue.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: ea8791e95adb Author: scolebourne Date: 2012-12-17 20:34 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea8791e95adb Rename Field, Unit, Adjusters and ValueRange ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDate.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/JapaneseDate.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/MinguoDate.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! src/share/classes/javax/time/format/DateTimeTextProvider.java ! src/share/classes/javax/time/temporal/Adjusters.java < src/share/classes/javax/time/temporal/DateTimeAdjusters.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java ! src/share/classes/javax/time/temporal/ChronoField.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/temporal/DateTimeBuilder.java - src/share/classes/javax/time/temporal/DateTimeValueRange.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOChrono.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/ISOWeeks.java ! src/share/classes/javax/time/temporal/JulianDayField.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java ! src/share/classes/javax/time/temporal/TemporalField.java < src/share/classes/javax/time/temporal/DateTimeField.java ! src/share/classes/javax/time/temporal/TemporalUnit.java < src/share/classes/javax/time/temporal/PeriodUnit.java + src/share/classes/javax/time/temporal/ValueRange.java ! src/share/classes/javax/time/temporal/WeekDefinition.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! src/share/classes/javax/time/temporal/package.html ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKDuration.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java ! test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java ! test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java ! test/javax/time/test/javax/time/MockSimplePeriod.java ! test/javax/time/test/javax/time/TestDayOfWeek.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestMonth.java ! test/javax/time/test/javax/time/TestZoneId.java ! test/javax/time/test/javax/time/TestZoneOffset.java ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java ! test/javax/time/test/javax/time/format/TestNumberParser.java ! test/javax/time/test/javax/time/format/TestReducedParser.java ! test/javax/time/test/javax/time/format/TestReducedPrinter.java ! test/javax/time/test/javax/time/format/TestTextParser.java ! test/javax/time/test/javax/time/format/TestTextPrinter.java ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java ! test/javax/time/test/javax/time/temporal/MockFieldValue.java ! test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java ! test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: ab1cb3b2e469 Author: scolebourne Date: 2012-12-17 21:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ab1cb3b2e469 Fixup Javadoc ! make/netbeans/threeten/build.xml ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! src/share/classes/javax/time/overview.html ! src/share/classes/javax/time/package.html ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java ! src/share/classes/javax/time/temporal/TemporalField.java ! src/share/classes/javax/time/temporal/TemporalUnit.java ! src/share/classes/javax/time/temporal/WeekDefinition.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java Changeset: 8d631ba2097d Author: scolebourne Date: 2012-12-17 21:50 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d631ba2097d Rename ChronoDateTimeImpl to ChronoLocalDateTimeImpl ! src/share/classes/javax/time/temporal/Chrono.java - src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java + src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Ser.java Changeset: 8ea3ee2ea41b Author: scolebourne Date: 2012-12-17 22:02 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8ea3ee2ea41b Rename ISOWeeks to ISOFields ! src/share/classes/javax/time/format/DateTimeFormatters.java + src/share/classes/javax/time/temporal/ISOFields.java - src/share/classes/javax/time/temporal/ISOWeeks.java ! src/share/classes/javax/time/temporal/package.html ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java + test/javax/time/tck/javax/time/temporal/TCKISOFields.java - test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java Changeset: 3fe752bb8753 Author: scolebourne Date: 2012-12-17 22:05 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3fe752bb8753 Remove duplicated inner period class ! src/share/classes/javax/time/temporal/ISOFields.java Changeset: b050690beaa4 Author: scolebourne Date: 2012-12-17 22:52 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b050690beaa4 Add quarter-of-year and day-of-quarter to ISOFields See #170 ! src/share/classes/javax/time/temporal/ISOFields.java ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java From scolebourne at joda.org Mon Dec 17 17:21:07 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Tue, 18 Dec 2012 01:21:07 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121218012141.2919C471FF@hg.openjdk.java.net> Changeset: 2940273ee72c Author: scolebourne Date: 2012-12-18 01:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2940273ee72c Reinstate quarter-of-year format pattern letter Q Do we have text data for this? ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java Changeset: 2604cc73262d Author: scolebourne Date: 2012-12-18 01:20 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2604cc73262d Validate quarter-of-year is ISO ! src/share/classes/javax/time/temporal/ISOFields.java From masayoshi.okutsu at oracle.com Mon Dec 17 23:27:10 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 18 Dec 2012 16:27:10 +0900 Subject: [threeten-dev] hg: threeten/threeten/jdk: 11 new changesets In-Reply-To: <20121217230415.ABE6B471F8@hg.openjdk.java.net> References: <20121217230415.ABE6B471F8@hg.openjdk.java.net> Message-ID: <50D01ACE.9080804@oracle.com> When you make changes to the repo, could you please keep binaries and documents buildable? Thanks, Masayoshi On 12/18/2012 8:02 AM, scolebourne at joda.org wrote: > Changeset: 8d10ff8fe9fd > Author: scolebourne > Date: 2012-12-17 18:55 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d10ff8fe9fd > > Rename global package to calendar > > + src/share/classes/javax/time/calendar/ChronoDateImpl.java > + src/share/classes/javax/time/calendar/HijrahChrono.java > + src/share/classes/javax/time/calendar/HijrahDate.java > + src/share/classes/javax/time/calendar/HijrahEra.java > + src/share/classes/javax/time/calendar/JapaneseChrono.java > + src/share/classes/javax/time/calendar/JapaneseDate.java > + src/share/classes/javax/time/calendar/JapaneseEra.java > + src/share/classes/javax/time/calendar/MinguoChrono.java > + src/share/classes/javax/time/calendar/MinguoDate.java > + src/share/classes/javax/time/calendar/MinguoEra.java > + src/share/classes/javax/time/calendar/Ser.java > + src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java > + src/share/classes/javax/time/calendar/ThaiBuddhistDate.java > + src/share/classes/javax/time/calendar/ThaiBuddhistEra.java > + src/share/classes/javax/time/calendar/package.html > - src/share/classes/javax/time/chrono/global/ChronoDateImpl.java > - src/share/classes/javax/time/chrono/global/HijrahChrono.java > - src/share/classes/javax/time/chrono/global/HijrahDate.java > - src/share/classes/javax/time/chrono/global/HijrahEra.java > - src/share/classes/javax/time/chrono/global/JapaneseChrono.java > - src/share/classes/javax/time/chrono/global/JapaneseDate.java > - src/share/classes/javax/time/chrono/global/JapaneseEra.java > - src/share/classes/javax/time/chrono/global/MinguoChrono.java > - src/share/classes/javax/time/chrono/global/MinguoDate.java > - src/share/classes/javax/time/chrono/global/MinguoEra.java > - src/share/classes/javax/time/chrono/global/Ser.java > - src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java > - src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java > - src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java > - src/share/classes/javax/time/chrono/global/package.html > ! src/share/classes/javax/time/overview.html > + test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java > + test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java > + test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java > + test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java > + test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java > + test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java > ! test/javax/time/tck/javax/time/chrono/TestChrono.java > ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java > ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java > - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java > - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java > - test/javax/time/tck/javax/time/chrono/global/TestHijrahChrono.java > - test/javax/time/tck/javax/time/chrono/global/TestJapaneseChrono.java > - test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java > - test/javax/time/tck/javax/time/chrono/global/TestThaiBuddhistChrono.java > ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java > ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java > > Changeset: b735c715d573 > Author: scolebourne > Date: 2012-12-17 19:11 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b735c715d573 > > Rename calendrical package to temporal > > ! src/share/classes/javax/time/DayOfWeek.java > ! src/share/classes/javax/time/Duration.java > ! src/share/classes/javax/time/Instant.java > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/Month.java > ! src/share/classes/javax/time/MonthDay.java > ! src/share/classes/javax/time/OffsetDate.java > ! src/share/classes/javax/time/OffsetDateTime.java > ! src/share/classes/javax/time/OffsetTime.java > ! src/share/classes/javax/time/Period.java > ! src/share/classes/javax/time/Year.java > ! src/share/classes/javax/time/YearMonth.java > ! src/share/classes/javax/time/ZoneId.java > ! src/share/classes/javax/time/ZoneOffset.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/calendar/ChronoDateImpl.java > ! src/share/classes/javax/time/calendar/HijrahChrono.java > ! src/share/classes/javax/time/calendar/HijrahDate.java > ! src/share/classes/javax/time/calendar/HijrahEra.java > ! src/share/classes/javax/time/calendar/JapaneseChrono.java > ! src/share/classes/javax/time/calendar/JapaneseDate.java > ! src/share/classes/javax/time/calendar/JapaneseEra.java > ! src/share/classes/javax/time/calendar/MinguoChrono.java > ! src/share/classes/javax/time/calendar/MinguoDate.java > ! src/share/classes/javax/time/calendar/MinguoEra.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java > - src/share/classes/javax/time/calendrical/ChronoField.java > - src/share/classes/javax/time/calendrical/ChronoUnit.java > - src/share/classes/javax/time/calendrical/DateTime.java > - src/share/classes/javax/time/calendrical/DateTimeAccessor.java > - src/share/classes/javax/time/calendrical/DateTimeAdjusters.java > - src/share/classes/javax/time/calendrical/DateTimeBuilder.java > - src/share/classes/javax/time/calendrical/DateTimeField.java > - src/share/classes/javax/time/calendrical/DateTimeValueRange.java > - src/share/classes/javax/time/calendrical/ISOWeeks.java > - src/share/classes/javax/time/calendrical/JulianDayField.java > - src/share/classes/javax/time/calendrical/PeriodUnit.java > - src/share/classes/javax/time/calendrical/WeekDefinition.java > - src/share/classes/javax/time/calendrical/package.html > ! src/share/classes/javax/time/chrono/Chrono.java > ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/chrono/ChronoLocalDate.java > ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java > ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java > ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java > ! src/share/classes/javax/time/chrono/Era.java > ! src/share/classes/javax/time/chrono/ISOChrono.java > ! src/share/classes/javax/time/chrono/ISOEra.java > ! src/share/classes/javax/time/format/DateTimeFormatter.java > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > ! src/share/classes/javax/time/format/DateTimeFormatters.java > ! src/share/classes/javax/time/format/DateTimeParseContext.java > ! src/share/classes/javax/time/format/DateTimePrintContext.java > ! src/share/classes/javax/time/format/DateTimeTextProvider.java > ! src/share/classes/javax/time/overview.html > ! src/share/classes/javax/time/package.html > + src/share/classes/javax/time/temporal/ChronoField.java > + src/share/classes/javax/time/temporal/ChronoUnit.java > + src/share/classes/javax/time/temporal/DateTime.java > + src/share/classes/javax/time/temporal/DateTimeAccessor.java > + src/share/classes/javax/time/temporal/DateTimeAdjusters.java > + src/share/classes/javax/time/temporal/DateTimeBuilder.java > + src/share/classes/javax/time/temporal/DateTimeField.java > + src/share/classes/javax/time/temporal/DateTimeValueRange.java > + src/share/classes/javax/time/temporal/ISOWeeks.java > + src/share/classes/javax/time/temporal/JulianDayField.java > + src/share/classes/javax/time/temporal/PeriodUnit.java > + src/share/classes/javax/time/temporal/WeekDefinition.java > + src/share/classes/javax/time/temporal/package.html > ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java > ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java > ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java > ! test/javax/time/tck/javax/time/TCKDayOfWeek.java > ! test/javax/time/tck/javax/time/TCKDuration.java > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKLocalTime.java > ! test/javax/time/tck/javax/time/TCKMonth.java > ! test/javax/time/tck/javax/time/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java > ! test/javax/time/tck/javax/time/TCKOffsetTime.java > ! test/javax/time/tck/javax/time/TCKZoneOffset.java > ! test/javax/time/tck/javax/time/TCKZonedDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java > ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java > ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java > ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java > - test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java > - test/javax/time/tck/javax/time/calendrical/TCKISOWeeks.java > - test/javax/time/tck/javax/time/calendrical/TCKJulianDayField.java > - test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java > - test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java > - test/javax/time/tck/javax/time/calendrical/TCKYear.java > - test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java > ! test/javax/time/tck/javax/time/chrono/TestChrono.java > ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java > ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java > ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java > ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldPrinter.java > + test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java > + test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java > + test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java > + test/javax/time/tck/javax/time/temporal/TCKMonthDay.java > + test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java > + test/javax/time/tck/javax/time/temporal/TCKYear.java > + test/javax/time/tck/javax/time/temporal/TCKYearMonth.java > ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java > ! test/javax/time/test/java/util/TestFormatter.java > ! test/javax/time/test/javax/time/AbstractDateTimeTest.java > ! test/javax/time/test/javax/time/MockSimplePeriod.java > ! test/javax/time/test/javax/time/TestDayOfWeek.java > ! test/javax/time/test/javax/time/TestInstant.java > ! test/javax/time/test/javax/time/TestLocalDate.java > ! test/javax/time/test/javax/time/TestLocalDateTime.java > ! test/javax/time/test/javax/time/TestMonth.java > ! test/javax/time/test/javax/time/TestOffsetDateTime.java > ! test/javax/time/test/javax/time/TestPeriod.java > ! test/javax/time/test/javax/time/TestPeriodParser.java > ! test/javax/time/test/javax/time/TestZoneId.java > ! test/javax/time/test/javax/time/TestZoneOffset.java > - test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java > - test/javax/time/test/javax/time/calendrical/MockFieldValue.java > - test/javax/time/test/javax/time/calendrical/TestChronoUnit.java > - test/javax/time/test/javax/time/calendrical/TestDateTimeAdjusters.java > - test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java > - test/javax/time/test/javax/time/calendrical/TestDateTimeValueRange.java > - test/javax/time/test/javax/time/calendrical/TestMonthDay.java > - test/javax/time/test/javax/time/calendrical/TestYear.java > - test/javax/time/test/javax/time/calendrical/TestYearMonth.java > ! test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java > ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java > ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java > ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java > ! test/javax/time/test/javax/time/format/TestCharLiteralParser.java > ! test/javax/time/test/javax/time/format/TestDateTimeFormatter.java > ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java > ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java > ! test/javax/time/test/javax/time/format/TestNumberParser.java > ! test/javax/time/test/javax/time/format/TestNumberPrinter.java > ! test/javax/time/test/javax/time/format/TestPadParserDecorator.java > ! test/javax/time/test/javax/time/format/TestReducedParser.java > ! test/javax/time/test/javax/time/format/TestReducedPrinter.java > ! test/javax/time/test/javax/time/format/TestStringLiteralParser.java > ! test/javax/time/test/javax/time/format/TestTextParser.java > ! test/javax/time/test/javax/time/format/TestTextPrinter.java > ! test/javax/time/test/javax/time/format/TestZoneIdParser.java > ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java > ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java > ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java > + test/javax/time/test/javax/time/temporal/MockFieldNoValue.java > + test/javax/time/test/javax/time/temporal/MockFieldValue.java > + test/javax/time/test/javax/time/temporal/TestChronoUnit.java > + test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java > + test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java > + test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java > + test/javax/time/test/javax/time/temporal/TestMonthDay.java > + test/javax/time/test/javax/time/temporal/TestYear.java > + test/javax/time/test/javax/time/temporal/TestYearMonth.java > > Changeset: 29c29abd5588 > Author: scolebourne > Date: 2012-12-17 19:36 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/29c29abd5588 > > Rename chrono package to temporal > > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/Month.java > ! src/share/classes/javax/time/MonthDay.java > ! src/share/classes/javax/time/OffsetDate.java > ! src/share/classes/javax/time/Period.java > ! src/share/classes/javax/time/Year.java > ! src/share/classes/javax/time/YearMonth.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/calendar/ChronoDateImpl.java > ! src/share/classes/javax/time/calendar/HijrahChrono.java > ! src/share/classes/javax/time/calendar/HijrahDate.java > ! src/share/classes/javax/time/calendar/HijrahEra.java > ! src/share/classes/javax/time/calendar/JapaneseChrono.java > ! src/share/classes/javax/time/calendar/JapaneseDate.java > ! src/share/classes/javax/time/calendar/JapaneseEra.java > ! src/share/classes/javax/time/calendar/MinguoChrono.java > ! src/share/classes/javax/time/calendar/MinguoDate.java > ! src/share/classes/javax/time/calendar/MinguoEra.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java > ! src/share/classes/javax/time/calendar/package.html > - src/share/classes/javax/time/chrono/Ser.java > - src/share/classes/javax/time/chrono/package.html > ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > ! src/share/classes/javax/time/overview.html > ! src/share/classes/javax/time/temporal/Chrono.java < src/share/classes/javax/time/chrono/Chrono.java > ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java < src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/temporal/ChronoField.java > ! src/share/classes/javax/time/temporal/ChronoLocalDate.java < src/share/classes/javax/time/chrono/ChronoLocalDate.java > ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java < src/share/classes/javax/time/chrono/ChronoLocalDateTime.java > ! src/share/classes/javax/time/temporal/ChronoUnit.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java < src/share/classes/javax/time/chrono/ChronoZonedDateTime.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java < src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java > ! src/share/classes/javax/time/temporal/DateTimeAccessor.java > ! src/share/classes/javax/time/temporal/DateTimeBuilder.java > ! src/share/classes/javax/time/temporal/Era.java < src/share/classes/javax/time/chrono/Era.java > ! src/share/classes/javax/time/temporal/ISOChrono.java < src/share/classes/javax/time/chrono/ISOChrono.java > ! src/share/classes/javax/time/temporal/ISOEra.java < src/share/classes/javax/time/chrono/ISOEra.java > + src/share/classes/javax/time/temporal/Ser.java > ! src/share/classes/javax/time/temporal/WeekDefinition.java > ! src/share/classes/javax/time/temporal/package.html > ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java > ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKMonth.java > ! test/javax/time/tck/javax/time/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java > ! test/javax/time/tck/javax/time/TCKZonedDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java > ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java > ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java > ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java > ! test/javax/time/tck/javax/time/temporal/TestChrono.java < test/javax/time/tck/javax/time/chrono/TestChrono.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java < test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java < test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java < test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java > ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java < test/javax/time/tck/javax/time/chrono/TestISOChrono.java > ! test/javax/time/test/javax/time/temporal/TestISOChronoImpl.java < test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java > ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java < test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java > ! test/javax/time/test/javax/time/temporal/TestThaiBuddhistChronoImpl.java < test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java > > Changeset: c9f5a3859101 > Author: scolebourne > Date: 2012-12-17 20:05 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9f5a3859101 > > Move base classes to temporal > > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > - src/share/classes/javax/time/OffsetDateTime.java > - src/share/classes/javax/time/OffsetTime.java > ! src/share/classes/javax/time/Ser.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/temporal/DateTimeAccessor.java > ! src/share/classes/javax/time/temporal/MonthDay.java < src/share/classes/javax/time/MonthDay.java > ! src/share/classes/javax/time/temporal/OffsetDate.java < src/share/classes/javax/time/OffsetDate.java > + src/share/classes/javax/time/temporal/OffsetDateTime.java > + src/share/classes/javax/time/temporal/OffsetTime.java > ! src/share/classes/javax/time/temporal/Ser.java > ! src/share/classes/javax/time/temporal/Year.java < src/share/classes/javax/time/Year.java > ! src/share/classes/javax/time/temporal/YearMonth.java < src/share/classes/javax/time/YearMonth.java > ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java > ! test/javax/time/resources/MonthDay.bin > ! test/javax/time/resources/OffsetDate.bin > ! test/javax/time/resources/OffsetDateTime.bin > ! test/javax/time/resources/OffsetTime.bin > ! test/javax/time/resources/Year.bin > ! test/javax/time/resources/YearMonth.bin > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKLocalTime.java > - test/javax/time/tck/javax/time/TCKOffsetTime.java > ! test/javax/time/tck/javax/time/TCKZoneOffset.java > ! test/javax/time/tck/javax/time/TCKZonedDateTime.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java < test/javax/time/tck/javax/time/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java < test/javax/time/tck/javax/time/TCKOffsetDateTime.java > + test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java > ! test/javax/time/tck/javax/time/temporal/TCKYear.java > ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java > ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java > ! test/javax/time/test/java/util/TestFormatter.java > ! test/javax/time/test/javax/time/AbstractTest.java > ! test/javax/time/test/javax/time/TestLocalDate.java > ! test/javax/time/test/javax/time/TestLocalDateTime.java > - test/javax/time/test/javax/time/TestOffsetDateTime.java > - test/javax/time/test/javax/time/TestOffsetDateTime_instants.java > ! test/javax/time/test/javax/time/TestPeriod.java > ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java > ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java > ! test/javax/time/test/javax/time/temporal/TestMonthDay.java > + test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java > + test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java > ! test/javax/time/test/javax/time/temporal/TestYear.java > ! test/javax/time/test/javax/time/temporal/TestYearMonth.java > ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java > > Changeset: 5127fd3d37f8 > Author: scolebourne > Date: 2012-12-17 20:22 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5127fd3d37f8 > > Rename DateTime and accessor to Temporal > > ! src/share/classes/javax/time/DayOfWeek.java > ! src/share/classes/javax/time/Duration.java > ! src/share/classes/javax/time/Instant.java > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/Month.java > ! src/share/classes/javax/time/Period.java > ! src/share/classes/javax/time/ZoneId.java > ! src/share/classes/javax/time/ZoneOffset.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/calendar/ChronoDateImpl.java > ! src/share/classes/javax/time/calendar/HijrahChrono.java > ! src/share/classes/javax/time/calendar/HijrahEra.java > ! src/share/classes/javax/time/calendar/JapaneseChrono.java > ! src/share/classes/javax/time/calendar/MinguoChrono.java > ! src/share/classes/javax/time/calendar/MinguoEra.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java > ! src/share/classes/javax/time/format/DateTimeFormatter.java > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > ! src/share/classes/javax/time/format/DateTimePrintContext.java > ! src/share/classes/javax/time/temporal/Chrono.java > ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/temporal/ChronoField.java > ! src/share/classes/javax/time/temporal/ChronoLocalDate.java > ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java > ! src/share/classes/javax/time/temporal/ChronoUnit.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java > - src/share/classes/javax/time/temporal/DateTime.java > ! src/share/classes/javax/time/temporal/DateTimeAdjusters.java > ! src/share/classes/javax/time/temporal/DateTimeBuilder.java > ! src/share/classes/javax/time/temporal/DateTimeField.java > ! src/share/classes/javax/time/temporal/Era.java > ! src/share/classes/javax/time/temporal/ISOChrono.java > ! src/share/classes/javax/time/temporal/ISOEra.java > ! src/share/classes/javax/time/temporal/ISOWeeks.java > ! src/share/classes/javax/time/temporal/JulianDayField.java > ! src/share/classes/javax/time/temporal/MonthDay.java > ! src/share/classes/javax/time/temporal/OffsetDate.java > ! src/share/classes/javax/time/temporal/OffsetDateTime.java > ! src/share/classes/javax/time/temporal/OffsetTime.java > ! src/share/classes/javax/time/temporal/PeriodUnit.java > + src/share/classes/javax/time/temporal/Temporal.java > = src/share/classes/javax/time/temporal/TemporalAccessor.java < src/share/classes/javax/time/temporal/DateTimeAccessor.java > ! src/share/classes/javax/time/temporal/WeekDefinition.java > ! src/share/classes/javax/time/temporal/Year.java > ! src/share/classes/javax/time/temporal/YearMonth.java > ! test/javax/time/tck/javax/time/TCKDayOfWeek.java > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKLocalTime.java > ! test/javax/time/tck/javax/time/TCKMonth.java > ! test/javax/time/tck/javax/time/TCKZoneOffset.java > ! test/javax/time/tck/javax/time/TCKZonedDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java > ! test/javax/time/tck/javax/time/temporal/TCKYear.java > ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java > ! test/javax/time/test/javax/time/AbstractDateTimeTest.java > ! test/javax/time/test/javax/time/MockSimplePeriod.java > ! test/javax/time/test/javax/time/TestDayOfWeek.java > ! test/javax/time/test/javax/time/TestInstant.java > ! test/javax/time/test/javax/time/TestLocalDate.java > ! test/javax/time/test/javax/time/TestLocalDateTime.java > ! test/javax/time/test/javax/time/TestMonth.java > ! test/javax/time/test/javax/time/TestZoneId.java > ! test/javax/time/test/javax/time/TestZoneOffset.java > ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java > ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java > ! test/javax/time/test/javax/time/temporal/MockFieldValue.java > ! test/javax/time/test/javax/time/temporal/TestMonthDay.java > ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java > ! test/javax/time/test/javax/time/temporal/TestYear.java > ! test/javax/time/test/javax/time/temporal/TestYearMonth.java > > Changeset: ea8791e95adb > Author: scolebourne > Date: 2012-12-17 20:34 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea8791e95adb > > Rename Field, Unit, Adjusters and ValueRange > > ! src/share/classes/javax/time/DayOfWeek.java > ! src/share/classes/javax/time/Duration.java > ! src/share/classes/javax/time/Instant.java > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/Month.java > ! src/share/classes/javax/time/Period.java > ! src/share/classes/javax/time/ZoneId.java > ! src/share/classes/javax/time/ZoneOffset.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/calendar/ChronoDateImpl.java > ! src/share/classes/javax/time/calendar/HijrahChrono.java > ! src/share/classes/javax/time/calendar/HijrahDate.java > ! src/share/classes/javax/time/calendar/HijrahEra.java > ! src/share/classes/javax/time/calendar/JapaneseChrono.java > ! src/share/classes/javax/time/calendar/JapaneseDate.java > ! src/share/classes/javax/time/calendar/MinguoChrono.java > ! src/share/classes/javax/time/calendar/MinguoDate.java > ! src/share/classes/javax/time/calendar/MinguoEra.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java > ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java > ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java > ! src/share/classes/javax/time/format/DateTimeFormatters.java > ! src/share/classes/javax/time/format/DateTimeParseContext.java > ! src/share/classes/javax/time/format/DateTimePrintContext.java > ! src/share/classes/javax/time/format/DateTimeTextProvider.java > ! src/share/classes/javax/time/temporal/Adjusters.java < src/share/classes/javax/time/temporal/DateTimeAdjusters.java > ! src/share/classes/javax/time/temporal/Chrono.java > ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java > ! src/share/classes/javax/time/temporal/ChronoField.java > ! src/share/classes/javax/time/temporal/ChronoLocalDate.java > ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java > ! src/share/classes/javax/time/temporal/ChronoUnit.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java > ! src/share/classes/javax/time/temporal/DateTimeBuilder.java > - src/share/classes/javax/time/temporal/DateTimeValueRange.java > ! src/share/classes/javax/time/temporal/Era.java > ! src/share/classes/javax/time/temporal/ISOChrono.java > ! src/share/classes/javax/time/temporal/ISOEra.java > ! src/share/classes/javax/time/temporal/ISOWeeks.java > ! src/share/classes/javax/time/temporal/JulianDayField.java > ! src/share/classes/javax/time/temporal/MonthDay.java > ! src/share/classes/javax/time/temporal/OffsetDate.java > ! src/share/classes/javax/time/temporal/OffsetDateTime.java > ! src/share/classes/javax/time/temporal/OffsetTime.java > ! src/share/classes/javax/time/temporal/Temporal.java > ! src/share/classes/javax/time/temporal/TemporalAccessor.java > ! src/share/classes/javax/time/temporal/TemporalField.java < src/share/classes/javax/time/temporal/DateTimeField.java > ! src/share/classes/javax/time/temporal/TemporalUnit.java < src/share/classes/javax/time/temporal/PeriodUnit.java > + src/share/classes/javax/time/temporal/ValueRange.java > ! src/share/classes/javax/time/temporal/WeekDefinition.java > ! src/share/classes/javax/time/temporal/Year.java > ! src/share/classes/javax/time/temporal/YearMonth.java > ! src/share/classes/javax/time/temporal/package.html > ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java > ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java > ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java > ! test/javax/time/tck/javax/time/TCKDayOfWeek.java > ! test/javax/time/tck/javax/time/TCKDuration.java > ! test/javax/time/tck/javax/time/TCKLocalDate.java > ! test/javax/time/tck/javax/time/TCKLocalDateTime.java > ! test/javax/time/tck/javax/time/TCKLocalTime.java > ! test/javax/time/tck/javax/time/TCKMonth.java > ! test/javax/time/tck/javax/time/TCKZoneOffset.java > ! test/javax/time/tck/javax/time/TCKZonedDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java > ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java > ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java > ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java > ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java > ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java > ! test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java > ! test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java > ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java > ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java > ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java > ! test/javax/time/tck/javax/time/temporal/TCKYear.java > ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java > ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java > ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java > ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java > ! test/javax/time/test/javax/time/AbstractDateTimeTest.java > ! test/javax/time/test/javax/time/MockSimplePeriod.java > ! test/javax/time/test/javax/time/TestDayOfWeek.java > ! test/javax/time/test/javax/time/TestLocalDate.java > ! test/javax/time/test/javax/time/TestLocalDateTime.java > ! test/javax/time/test/javax/time/TestMonth.java > ! test/javax/time/test/javax/time/TestZoneId.java > ! test/javax/time/test/javax/time/TestZoneOffset.java > ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java > ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java > ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java > ! test/javax/time/test/javax/time/format/TestNumberParser.java > ! test/javax/time/test/javax/time/format/TestReducedParser.java > ! test/javax/time/test/javax/time/format/TestReducedPrinter.java > ! test/javax/time/test/javax/time/format/TestTextParser.java > ! test/javax/time/test/javax/time/format/TestTextPrinter.java > ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java > ! test/javax/time/test/javax/time/temporal/MockFieldValue.java > ! test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java > ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java > ! test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java > ! test/javax/time/test/javax/time/temporal/TestMonthDay.java > ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java > ! test/javax/time/test/javax/time/temporal/TestYear.java > ! test/javax/time/test/javax/time/temporal/TestYearMonth.java > > Changeset: ab1cb3b2e469 > Author: scolebourne > Date: 2012-12-17 21:39 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ab1cb3b2e469 > > Fixup Javadoc > > ! make/netbeans/threeten/build.xml > ! src/share/classes/javax/time/DayOfWeek.java > ! src/share/classes/javax/time/Duration.java > ! src/share/classes/javax/time/Instant.java > ! src/share/classes/javax/time/LocalDate.java > ! src/share/classes/javax/time/LocalDateTime.java > ! src/share/classes/javax/time/LocalTime.java > ! src/share/classes/javax/time/Month.java > ! src/share/classes/javax/time/Period.java > ! src/share/classes/javax/time/ZoneId.java > ! src/share/classes/javax/time/ZoneOffset.java > ! src/share/classes/javax/time/ZonedDateTime.java > ! src/share/classes/javax/time/format/DateTimeFormatter.java > ! src/share/classes/javax/time/format/DateTimeParseContext.java > ! src/share/classes/javax/time/format/DateTimePrintContext.java > ! src/share/classes/javax/time/overview.html > ! src/share/classes/javax/time/package.html > ! src/share/classes/javax/time/temporal/Chrono.java > ! src/share/classes/javax/time/temporal/MonthDay.java > ! src/share/classes/javax/time/temporal/OffsetDate.java > ! src/share/classes/javax/time/temporal/OffsetDateTime.java > ! src/share/classes/javax/time/temporal/OffsetTime.java > ! src/share/classes/javax/time/temporal/Temporal.java > ! src/share/classes/javax/time/temporal/TemporalAccessor.java > ! src/share/classes/javax/time/temporal/TemporalField.java > ! src/share/classes/javax/time/temporal/TemporalUnit.java > ! src/share/classes/javax/time/temporal/WeekDefinition.java > ! src/share/classes/javax/time/temporal/Year.java > ! src/share/classes/javax/time/temporal/YearMonth.java > > Changeset: 8d631ba2097d > Author: scolebourne > Date: 2012-12-17 21:50 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d631ba2097d > > Rename ChronoDateTimeImpl to ChronoLocalDateTimeImpl > > ! src/share/classes/javax/time/temporal/Chrono.java > - src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java > + src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java > ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java > ! src/share/classes/javax/time/temporal/OffsetDate.java > ! src/share/classes/javax/time/temporal/OffsetTime.java > ! src/share/classes/javax/time/temporal/Ser.java > > Changeset: 8ea3ee2ea41b > Author: scolebourne > Date: 2012-12-17 22:02 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8ea3ee2ea41b > > Rename ISOWeeks to ISOFields > > ! src/share/classes/javax/time/format/DateTimeFormatters.java > + src/share/classes/javax/time/temporal/ISOFields.java > - src/share/classes/javax/time/temporal/ISOWeeks.java > ! src/share/classes/javax/time/temporal/package.html > ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java > + test/javax/time/tck/javax/time/temporal/TCKISOFields.java > - test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java > > Changeset: 3fe752bb8753 > Author: scolebourne > Date: 2012-12-17 22:05 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3fe752bb8753 > > Remove duplicated inner period class > > ! src/share/classes/javax/time/temporal/ISOFields.java > > Changeset: b050690beaa4 > Author: scolebourne > Date: 2012-12-17 22:52 +0000 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b050690beaa4 > > Add quarter-of-year and day-of-quarter to ISOFields > > See #170 > > ! src/share/classes/javax/time/temporal/ISOFields.java > ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java > From xueming.shen at oracle.com Mon Dec 17 23:52:14 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 17 Dec 2012 23:52:14 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: 11 new changesets In-Reply-To: <50D01ACE.9080804@oracle.com> References: <20121217230415.ABE6B471F8@hg.openjdk.java.net> <50D01ACE.9080804@oracle.com> Message-ID: <50D020AE.40903@oracle.com> Hi Okutsu-san, Stephen still can't build the whole JDK repo yet. I will push the updated j.u.Formatter in minutes, if no failure from the jtreg. -Sherman On 12/17/2012 11:27 PM, Masayoshi Okutsu wrote: > When you make changes to the repo, could you please keep binaries and > documents buildable? > > Thanks, > Masayoshi > > On 12/18/2012 8:02 AM, scolebourne at joda.org wrote: >> Changeset: 8d10ff8fe9fd >> Author: scolebourne >> Date: 2012-12-17 18:55 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d10ff8fe9fd >> >> Rename global package to calendar >> >> + src/share/classes/javax/time/calendar/ChronoDateImpl.java >> + src/share/classes/javax/time/calendar/HijrahChrono.java >> + src/share/classes/javax/time/calendar/HijrahDate.java >> + src/share/classes/javax/time/calendar/HijrahEra.java >> + src/share/classes/javax/time/calendar/JapaneseChrono.java >> + src/share/classes/javax/time/calendar/JapaneseDate.java >> + src/share/classes/javax/time/calendar/JapaneseEra.java >> + src/share/classes/javax/time/calendar/MinguoChrono.java >> + src/share/classes/javax/time/calendar/MinguoDate.java >> + src/share/classes/javax/time/calendar/MinguoEra.java >> + src/share/classes/javax/time/calendar/Ser.java >> + src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >> + src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >> + src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >> + src/share/classes/javax/time/calendar/package.html >> - src/share/classes/javax/time/chrono/global/ChronoDateImpl.java >> - src/share/classes/javax/time/chrono/global/HijrahChrono.java >> - src/share/classes/javax/time/chrono/global/HijrahDate.java >> - src/share/classes/javax/time/chrono/global/HijrahEra.java >> - src/share/classes/javax/time/chrono/global/JapaneseChrono.java >> - src/share/classes/javax/time/chrono/global/JapaneseDate.java >> - src/share/classes/javax/time/chrono/global/JapaneseEra.java >> - src/share/classes/javax/time/chrono/global/MinguoChrono.java >> - src/share/classes/javax/time/chrono/global/MinguoDate.java >> - src/share/classes/javax/time/chrono/global/MinguoEra.java >> - src/share/classes/javax/time/chrono/global/Ser.java >> - src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java >> - src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java >> - src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java >> - src/share/classes/javax/time/chrono/global/package.html >> ! src/share/classes/javax/time/overview.html >> + test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >> + test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >> + test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >> + test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >> + test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >> + test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >> ! test/javax/time/tck/javax/time/chrono/TestChrono.java >> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >> ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java >> - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java >> - >> test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java >> - test/javax/time/tck/javax/time/chrono/global/TestHijrahChrono.java >> - test/javax/time/tck/javax/time/chrono/global/TestJapaneseChrono.java >> - test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java >> - >> test/javax/time/tck/javax/time/chrono/global/TestThaiBuddhistChrono.java >> ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >> ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >> >> Changeset: b735c715d573 >> Author: scolebourne >> Date: 2012-12-17 19:11 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b735c715d573 >> >> Rename calendrical package to temporal >> >> ! src/share/classes/javax/time/DayOfWeek.java >> ! src/share/classes/javax/time/Duration.java >> ! src/share/classes/javax/time/Instant.java >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/Month.java >> ! src/share/classes/javax/time/MonthDay.java >> ! src/share/classes/javax/time/OffsetDate.java >> ! src/share/classes/javax/time/OffsetDateTime.java >> ! src/share/classes/javax/time/OffsetTime.java >> ! src/share/classes/javax/time/Period.java >> ! src/share/classes/javax/time/Year.java >> ! src/share/classes/javax/time/YearMonth.java >> ! src/share/classes/javax/time/ZoneId.java >> ! src/share/classes/javax/time/ZoneOffset.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >> ! src/share/classes/javax/time/calendar/HijrahChrono.java >> ! src/share/classes/javax/time/calendar/HijrahDate.java >> ! src/share/classes/javax/time/calendar/HijrahEra.java >> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >> ! src/share/classes/javax/time/calendar/JapaneseDate.java >> ! src/share/classes/javax/time/calendar/JapaneseEra.java >> ! src/share/classes/javax/time/calendar/MinguoChrono.java >> ! src/share/classes/javax/time/calendar/MinguoDate.java >> ! src/share/classes/javax/time/calendar/MinguoEra.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >> - src/share/classes/javax/time/calendrical/ChronoField.java >> - src/share/classes/javax/time/calendrical/ChronoUnit.java >> - src/share/classes/javax/time/calendrical/DateTime.java >> - src/share/classes/javax/time/calendrical/DateTimeAccessor.java >> - src/share/classes/javax/time/calendrical/DateTimeAdjusters.java >> - src/share/classes/javax/time/calendrical/DateTimeBuilder.java >> - src/share/classes/javax/time/calendrical/DateTimeField.java >> - src/share/classes/javax/time/calendrical/DateTimeValueRange.java >> - src/share/classes/javax/time/calendrical/ISOWeeks.java >> - src/share/classes/javax/time/calendrical/JulianDayField.java >> - src/share/classes/javax/time/calendrical/PeriodUnit.java >> - src/share/classes/javax/time/calendrical/WeekDefinition.java >> - src/share/classes/javax/time/calendrical/package.html >> ! src/share/classes/javax/time/chrono/Chrono.java >> ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/chrono/ChronoLocalDate.java >> ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java >> ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java >> ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java >> ! src/share/classes/javax/time/chrono/Era.java >> ! src/share/classes/javax/time/chrono/ISOChrono.java >> ! src/share/classes/javax/time/chrono/ISOEra.java >> ! src/share/classes/javax/time/format/DateTimeFormatter.java >> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >> ! src/share/classes/javax/time/format/DateTimeFormatters.java >> ! src/share/classes/javax/time/format/DateTimeParseContext.java >> ! src/share/classes/javax/time/format/DateTimePrintContext.java >> ! src/share/classes/javax/time/format/DateTimeTextProvider.java >> ! src/share/classes/javax/time/overview.html >> ! src/share/classes/javax/time/package.html >> + src/share/classes/javax/time/temporal/ChronoField.java >> + src/share/classes/javax/time/temporal/ChronoUnit.java >> + src/share/classes/javax/time/temporal/DateTime.java >> + src/share/classes/javax/time/temporal/DateTimeAccessor.java >> + src/share/classes/javax/time/temporal/DateTimeAdjusters.java >> + src/share/classes/javax/time/temporal/DateTimeBuilder.java >> + src/share/classes/javax/time/temporal/DateTimeField.java >> + src/share/classes/javax/time/temporal/DateTimeValueRange.java >> + src/share/classes/javax/time/temporal/ISOWeeks.java >> + src/share/classes/javax/time/temporal/JulianDayField.java >> + src/share/classes/javax/time/temporal/PeriodUnit.java >> + src/share/classes/javax/time/temporal/WeekDefinition.java >> + src/share/classes/javax/time/temporal/package.html >> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >> ! test/javax/time/tck/javax/time/TCKDuration.java >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKLocalTime.java >> ! test/javax/time/tck/javax/time/TCKMonth.java >> ! test/javax/time/tck/javax/time/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java >> ! test/javax/time/tck/javax/time/TCKOffsetTime.java >> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >> - test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java >> - test/javax/time/tck/javax/time/calendrical/TCKISOWeeks.java >> - test/javax/time/tck/javax/time/calendrical/TCKJulianDayField.java >> - test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java >> - test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java >> - test/javax/time/tck/javax/time/calendrical/TCKYear.java >> - test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java >> ! test/javax/time/tck/javax/time/chrono/TestChrono.java >> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >> ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java >> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java >> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldPrinter.java >> + test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java >> + test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >> + test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java >> + test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >> + test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java >> + test/javax/time/tck/javax/time/temporal/TCKYear.java >> + test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >> ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java >> ! test/javax/time/test/java/util/TestFormatter.java >> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >> ! test/javax/time/test/javax/time/MockSimplePeriod.java >> ! test/javax/time/test/javax/time/TestDayOfWeek.java >> ! test/javax/time/test/javax/time/TestInstant.java >> ! test/javax/time/test/javax/time/TestLocalDate.java >> ! test/javax/time/test/javax/time/TestLocalDateTime.java >> ! test/javax/time/test/javax/time/TestMonth.java >> ! test/javax/time/test/javax/time/TestOffsetDateTime.java >> ! test/javax/time/test/javax/time/TestPeriod.java >> ! test/javax/time/test/javax/time/TestPeriodParser.java >> ! test/javax/time/test/javax/time/TestZoneId.java >> ! test/javax/time/test/javax/time/TestZoneOffset.java >> - test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java >> - test/javax/time/test/javax/time/calendrical/MockFieldValue.java >> - test/javax/time/test/javax/time/calendrical/TestChronoUnit.java >> - test/javax/time/test/javax/time/calendrical/TestDateTimeAdjusters.java >> - >> test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java >> - >> test/javax/time/test/javax/time/calendrical/TestDateTimeValueRange.java >> - test/javax/time/test/javax/time/calendrical/TestMonthDay.java >> - test/javax/time/test/javax/time/calendrical/TestYear.java >> - test/javax/time/test/javax/time/calendrical/TestYearMonth.java >> ! test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java >> ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >> ! test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >> ! test/javax/time/test/javax/time/format/TestCharLiteralParser.java >> ! test/javax/time/test/javax/time/format/TestDateTimeFormatter.java >> ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java >> ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java >> ! test/javax/time/test/javax/time/format/TestNumberParser.java >> ! test/javax/time/test/javax/time/format/TestNumberPrinter.java >> ! test/javax/time/test/javax/time/format/TestPadParserDecorator.java >> ! test/javax/time/test/javax/time/format/TestReducedParser.java >> ! test/javax/time/test/javax/time/format/TestReducedPrinter.java >> ! test/javax/time/test/javax/time/format/TestStringLiteralParser.java >> ! test/javax/time/test/javax/time/format/TestTextParser.java >> ! test/javax/time/test/javax/time/format/TestTextPrinter.java >> ! test/javax/time/test/javax/time/format/TestZoneIdParser.java >> ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java >> ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java >> ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java >> + test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >> + test/javax/time/test/javax/time/temporal/MockFieldValue.java >> + test/javax/time/test/javax/time/temporal/TestChronoUnit.java >> + test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java >> + >> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >> + test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java >> + test/javax/time/test/javax/time/temporal/TestMonthDay.java >> + test/javax/time/test/javax/time/temporal/TestYear.java >> + test/javax/time/test/javax/time/temporal/TestYearMonth.java >> >> Changeset: 29c29abd5588 >> Author: scolebourne >> Date: 2012-12-17 19:36 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/29c29abd5588 >> >> Rename chrono package to temporal >> >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/Month.java >> ! src/share/classes/javax/time/MonthDay.java >> ! src/share/classes/javax/time/OffsetDate.java >> ! src/share/classes/javax/time/Period.java >> ! src/share/classes/javax/time/Year.java >> ! src/share/classes/javax/time/YearMonth.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >> ! src/share/classes/javax/time/calendar/HijrahChrono.java >> ! src/share/classes/javax/time/calendar/HijrahDate.java >> ! src/share/classes/javax/time/calendar/HijrahEra.java >> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >> ! src/share/classes/javax/time/calendar/JapaneseDate.java >> ! src/share/classes/javax/time/calendar/JapaneseEra.java >> ! src/share/classes/javax/time/calendar/MinguoChrono.java >> ! src/share/classes/javax/time/calendar/MinguoDate.java >> ! src/share/classes/javax/time/calendar/MinguoEra.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >> ! src/share/classes/javax/time/calendar/package.html >> - src/share/classes/javax/time/chrono/Ser.java >> - src/share/classes/javax/time/chrono/package.html >> ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java >> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >> ! src/share/classes/javax/time/overview.html >> ! src/share/classes/javax/time/temporal/Chrono.java < >> src/share/classes/javax/time/chrono/Chrono.java >> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java < >> src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/ChronoField.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java < >> src/share/classes/javax/time/chrono/ChronoLocalDate.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java < >> src/share/classes/javax/time/chrono/ChronoLocalDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoUnit.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java < >> src/share/classes/javax/time/chrono/ChronoZonedDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >> < src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/DateTimeAccessor.java >> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >> ! src/share/classes/javax/time/temporal/Era.java < >> src/share/classes/javax/time/chrono/Era.java >> ! src/share/classes/javax/time/temporal/ISOChrono.java < >> src/share/classes/javax/time/chrono/ISOChrono.java >> ! src/share/classes/javax/time/temporal/ISOEra.java < >> src/share/classes/javax/time/chrono/ISOEra.java >> + src/share/classes/javax/time/temporal/Ser.java >> ! src/share/classes/javax/time/temporal/WeekDefinition.java >> ! src/share/classes/javax/time/temporal/package.html >> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKMonth.java >> ! test/javax/time/tck/javax/time/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java >> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >> ! test/javax/time/tck/javax/time/temporal/TestChrono.java < >> test/javax/time/tck/javax/time/chrono/TestChrono.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java < >> test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java >> ! >> test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >> < test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >> ! >> test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >> < test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java < >> test/javax/time/tck/javax/time/chrono/TestISOChrono.java >> ! test/javax/time/test/javax/time/temporal/TestISOChronoImpl.java < >> test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java >> ! >> test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java >> < test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >> ! >> test/javax/time/test/javax/time/temporal/TestThaiBuddhistChronoImpl.java >> < test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >> >> Changeset: c9f5a3859101 >> Author: scolebourne >> Date: 2012-12-17 20:05 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9f5a3859101 >> >> Move base classes to temporal >> >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> - src/share/classes/javax/time/OffsetDateTime.java >> - src/share/classes/javax/time/OffsetTime.java >> ! src/share/classes/javax/time/Ser.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/DateTimeAccessor.java >> ! src/share/classes/javax/time/temporal/MonthDay.java < >> src/share/classes/javax/time/MonthDay.java >> ! src/share/classes/javax/time/temporal/OffsetDate.java < >> src/share/classes/javax/time/OffsetDate.java >> + src/share/classes/javax/time/temporal/OffsetDateTime.java >> + src/share/classes/javax/time/temporal/OffsetTime.java >> ! src/share/classes/javax/time/temporal/Ser.java >> ! src/share/classes/javax/time/temporal/Year.java < >> src/share/classes/javax/time/Year.java >> ! src/share/classes/javax/time/temporal/YearMonth.java < >> src/share/classes/javax/time/YearMonth.java >> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >> ! test/javax/time/resources/MonthDay.bin >> ! test/javax/time/resources/OffsetDate.bin >> ! test/javax/time/resources/OffsetDateTime.bin >> ! test/javax/time/resources/OffsetTime.bin >> ! test/javax/time/resources/Year.bin >> ! test/javax/time/resources/YearMonth.bin >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKLocalTime.java >> - test/javax/time/tck/javax/time/TCKOffsetTime.java >> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java < >> test/javax/time/tck/javax/time/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java < >> test/javax/time/tck/javax/time/TCKOffsetDateTime.java >> + test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >> ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java >> ! test/javax/time/test/java/util/TestFormatter.java >> ! test/javax/time/test/javax/time/AbstractTest.java >> ! test/javax/time/test/javax/time/TestLocalDate.java >> ! test/javax/time/test/javax/time/TestLocalDateTime.java >> - test/javax/time/test/javax/time/TestOffsetDateTime.java >> - test/javax/time/test/javax/time/TestOffsetDateTime_instants.java >> ! test/javax/time/test/javax/time/TestPeriod.java >> ! >> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >> ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java >> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >> + test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >> + >> test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java >> ! test/javax/time/test/javax/time/temporal/TestYear.java >> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >> ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java >> >> Changeset: 5127fd3d37f8 >> Author: scolebourne >> Date: 2012-12-17 20:22 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5127fd3d37f8 >> >> Rename DateTime and accessor to Temporal >> >> ! src/share/classes/javax/time/DayOfWeek.java >> ! src/share/classes/javax/time/Duration.java >> ! src/share/classes/javax/time/Instant.java >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/Month.java >> ! src/share/classes/javax/time/Period.java >> ! src/share/classes/javax/time/ZoneId.java >> ! src/share/classes/javax/time/ZoneOffset.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >> ! src/share/classes/javax/time/calendar/HijrahChrono.java >> ! src/share/classes/javax/time/calendar/HijrahEra.java >> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >> ! src/share/classes/javax/time/calendar/MinguoChrono.java >> ! src/share/classes/javax/time/calendar/MinguoEra.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >> ! src/share/classes/javax/time/format/DateTimeFormatter.java >> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >> ! src/share/classes/javax/time/format/DateTimePrintContext.java >> ! src/share/classes/javax/time/temporal/Chrono.java >> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/ChronoField.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoUnit.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >> - src/share/classes/javax/time/temporal/DateTime.java >> ! src/share/classes/javax/time/temporal/DateTimeAdjusters.java >> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >> ! src/share/classes/javax/time/temporal/DateTimeField.java >> ! src/share/classes/javax/time/temporal/Era.java >> ! src/share/classes/javax/time/temporal/ISOChrono.java >> ! src/share/classes/javax/time/temporal/ISOEra.java >> ! src/share/classes/javax/time/temporal/ISOWeeks.java >> ! src/share/classes/javax/time/temporal/JulianDayField.java >> ! src/share/classes/javax/time/temporal/MonthDay.java >> ! src/share/classes/javax/time/temporal/OffsetDate.java >> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >> ! src/share/classes/javax/time/temporal/OffsetTime.java >> ! src/share/classes/javax/time/temporal/PeriodUnit.java >> + src/share/classes/javax/time/temporal/Temporal.java >> = src/share/classes/javax/time/temporal/TemporalAccessor.java < >> src/share/classes/javax/time/temporal/DateTimeAccessor.java >> ! src/share/classes/javax/time/temporal/WeekDefinition.java >> ! src/share/classes/javax/time/temporal/Year.java >> ! src/share/classes/javax/time/temporal/YearMonth.java >> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKLocalTime.java >> ! test/javax/time/tck/javax/time/TCKMonth.java >> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >> ! test/javax/time/test/javax/time/MockSimplePeriod.java >> ! test/javax/time/test/javax/time/TestDayOfWeek.java >> ! test/javax/time/test/javax/time/TestInstant.java >> ! test/javax/time/test/javax/time/TestLocalDate.java >> ! test/javax/time/test/javax/time/TestLocalDateTime.java >> ! test/javax/time/test/javax/time/TestMonth.java >> ! test/javax/time/test/javax/time/TestZoneId.java >> ! test/javax/time/test/javax/time/TestZoneOffset.java >> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >> ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >> ! test/javax/time/test/javax/time/temporal/MockFieldValue.java >> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >> ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >> ! test/javax/time/test/javax/time/temporal/TestYear.java >> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >> >> Changeset: ea8791e95adb >> Author: scolebourne >> Date: 2012-12-17 20:34 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea8791e95adb >> >> Rename Field, Unit, Adjusters and ValueRange >> >> ! src/share/classes/javax/time/DayOfWeek.java >> ! src/share/classes/javax/time/Duration.java >> ! src/share/classes/javax/time/Instant.java >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/Month.java >> ! src/share/classes/javax/time/Period.java >> ! src/share/classes/javax/time/ZoneId.java >> ! src/share/classes/javax/time/ZoneOffset.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >> ! src/share/classes/javax/time/calendar/HijrahChrono.java >> ! src/share/classes/javax/time/calendar/HijrahDate.java >> ! src/share/classes/javax/time/calendar/HijrahEra.java >> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >> ! src/share/classes/javax/time/calendar/JapaneseDate.java >> ! src/share/classes/javax/time/calendar/MinguoChrono.java >> ! src/share/classes/javax/time/calendar/MinguoDate.java >> ! src/share/classes/javax/time/calendar/MinguoEra.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >> ! src/share/classes/javax/time/format/DateTimeFormatters.java >> ! src/share/classes/javax/time/format/DateTimeParseContext.java >> ! src/share/classes/javax/time/format/DateTimePrintContext.java >> ! src/share/classes/javax/time/format/DateTimeTextProvider.java >> ! src/share/classes/javax/time/temporal/Adjusters.java < >> src/share/classes/javax/time/temporal/DateTimeAdjusters.java >> ! src/share/classes/javax/time/temporal/Chrono.java >> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/ChronoField.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java >> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoUnit.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >> - src/share/classes/javax/time/temporal/DateTimeValueRange.java >> ! src/share/classes/javax/time/temporal/Era.java >> ! src/share/classes/javax/time/temporal/ISOChrono.java >> ! src/share/classes/javax/time/temporal/ISOEra.java >> ! src/share/classes/javax/time/temporal/ISOWeeks.java >> ! src/share/classes/javax/time/temporal/JulianDayField.java >> ! src/share/classes/javax/time/temporal/MonthDay.java >> ! src/share/classes/javax/time/temporal/OffsetDate.java >> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >> ! src/share/classes/javax/time/temporal/OffsetTime.java >> ! src/share/classes/javax/time/temporal/Temporal.java >> ! src/share/classes/javax/time/temporal/TemporalAccessor.java >> ! src/share/classes/javax/time/temporal/TemporalField.java < >> src/share/classes/javax/time/temporal/DateTimeField.java >> ! src/share/classes/javax/time/temporal/TemporalUnit.java < >> src/share/classes/javax/time/temporal/PeriodUnit.java >> + src/share/classes/javax/time/temporal/ValueRange.java >> ! src/share/classes/javax/time/temporal/WeekDefinition.java >> ! src/share/classes/javax/time/temporal/Year.java >> ! src/share/classes/javax/time/temporal/YearMonth.java >> ! src/share/classes/javax/time/temporal/package.html >> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >> ! test/javax/time/tck/javax/time/TCKDuration.java >> ! test/javax/time/tck/javax/time/TCKLocalDate.java >> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >> ! test/javax/time/tck/javax/time/TCKLocalTime.java >> ! test/javax/time/tck/javax/time/TCKMonth.java >> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java >> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java >> ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java >> ! test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >> ! test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java >> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >> ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java >> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >> ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java >> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >> ! test/javax/time/test/javax/time/MockSimplePeriod.java >> ! test/javax/time/test/javax/time/TestDayOfWeek.java >> ! test/javax/time/test/javax/time/TestLocalDate.java >> ! test/javax/time/test/javax/time/TestLocalDateTime.java >> ! test/javax/time/test/javax/time/TestMonth.java >> ! test/javax/time/test/javax/time/TestZoneId.java >> ! test/javax/time/test/javax/time/TestZoneOffset.java >> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >> ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java >> ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java >> ! test/javax/time/test/javax/time/format/TestNumberParser.java >> ! test/javax/time/test/javax/time/format/TestReducedParser.java >> ! test/javax/time/test/javax/time/format/TestReducedPrinter.java >> ! test/javax/time/test/javax/time/format/TestTextParser.java >> ! test/javax/time/test/javax/time/format/TestTextPrinter.java >> ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >> ! test/javax/time/test/javax/time/temporal/MockFieldValue.java >> ! test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java >> ! >> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >> ! test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java >> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >> ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >> ! test/javax/time/test/javax/time/temporal/TestYear.java >> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >> >> Changeset: ab1cb3b2e469 >> Author: scolebourne >> Date: 2012-12-17 21:39 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ab1cb3b2e469 >> >> Fixup Javadoc >> >> ! make/netbeans/threeten/build.xml >> ! src/share/classes/javax/time/DayOfWeek.java >> ! src/share/classes/javax/time/Duration.java >> ! src/share/classes/javax/time/Instant.java >> ! src/share/classes/javax/time/LocalDate.java >> ! src/share/classes/javax/time/LocalDateTime.java >> ! src/share/classes/javax/time/LocalTime.java >> ! src/share/classes/javax/time/Month.java >> ! src/share/classes/javax/time/Period.java >> ! src/share/classes/javax/time/ZoneId.java >> ! src/share/classes/javax/time/ZoneOffset.java >> ! src/share/classes/javax/time/ZonedDateTime.java >> ! src/share/classes/javax/time/format/DateTimeFormatter.java >> ! src/share/classes/javax/time/format/DateTimeParseContext.java >> ! src/share/classes/javax/time/format/DateTimePrintContext.java >> ! src/share/classes/javax/time/overview.html >> ! src/share/classes/javax/time/package.html >> ! src/share/classes/javax/time/temporal/Chrono.java >> ! src/share/classes/javax/time/temporal/MonthDay.java >> ! src/share/classes/javax/time/temporal/OffsetDate.java >> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >> ! src/share/classes/javax/time/temporal/OffsetTime.java >> ! src/share/classes/javax/time/temporal/Temporal.java >> ! src/share/classes/javax/time/temporal/TemporalAccessor.java >> ! src/share/classes/javax/time/temporal/TemporalField.java >> ! src/share/classes/javax/time/temporal/TemporalUnit.java >> ! src/share/classes/javax/time/temporal/WeekDefinition.java >> ! src/share/classes/javax/time/temporal/Year.java >> ! src/share/classes/javax/time/temporal/YearMonth.java >> >> Changeset: 8d631ba2097d >> Author: scolebourne >> Date: 2012-12-17 21:50 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d631ba2097d >> >> Rename ChronoDateTimeImpl to ChronoLocalDateTimeImpl >> >> ! src/share/classes/javax/time/temporal/Chrono.java >> - src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >> + src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >> ! src/share/classes/javax/time/temporal/OffsetDate.java >> ! src/share/classes/javax/time/temporal/OffsetTime.java >> ! src/share/classes/javax/time/temporal/Ser.java >> >> Changeset: 8ea3ee2ea41b >> Author: scolebourne >> Date: 2012-12-17 22:02 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8ea3ee2ea41b >> >> Rename ISOWeeks to ISOFields >> >> ! src/share/classes/javax/time/format/DateTimeFormatters.java >> + src/share/classes/javax/time/temporal/ISOFields.java >> - src/share/classes/javax/time/temporal/ISOWeeks.java >> ! src/share/classes/javax/time/temporal/package.html >> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >> + test/javax/time/tck/javax/time/temporal/TCKISOFields.java >> - test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >> >> Changeset: 3fe752bb8753 >> Author: scolebourne >> Date: 2012-12-17 22:05 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3fe752bb8753 >> >> Remove duplicated inner period class >> >> ! src/share/classes/javax/time/temporal/ISOFields.java >> >> Changeset: b050690beaa4 >> Author: scolebourne >> Date: 2012-12-17 22:52 +0000 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b050690beaa4 >> >> Add quarter-of-year and day-of-quarter to ISOFields >> >> See #170 >> >> ! src/share/classes/javax/time/temporal/ISOFields.java >> ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java >> > From xueming.shen at oracle.com Tue Dec 18 00:00:56 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 18 Dec 2012 08:00:56 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated the j.u.Formatter to use the updated package/class names Message-ID: <20121218080118.2E86547208@hg.openjdk.java.net> Changeset: f2d602792e0b Author: sherman Date: 2012-12-18 00:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f2d602792e0b Updated the j.u.Formatter to use the updated package/class names ! src/share/classes/java/util/Formatter.java From xueming.shen at oracle.com Tue Dec 18 00:02:55 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 00:02:55 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: 11 new changesets In-Reply-To: <50D020AE.40903@oracle.com> References: <20121217230415.ABE6B471F8@hg.openjdk.java.net> <50D01ACE.9080804@oracle.com> <50D020AE.40903@oracle.com> Message-ID: <50D0232F.1030905@oracle.com> Just pushed the j.u.Formatter change. The binaries and doc should build now, though it appears the tests are failing... On 12/17/2012 11:52 PM, Xueming Shen wrote: > Hi Okutsu-san, > > Stephen still can't build the whole JDK repo yet. I will push the > updated j.u.Formatter in minutes, if > no failure from the jtreg. > > -Sherman > > On 12/17/2012 11:27 PM, Masayoshi Okutsu wrote: >> When you make changes to the repo, could you please keep binaries and >> documents buildable? >> >> Thanks, >> Masayoshi >> >> On 12/18/2012 8:02 AM, scolebourne at joda.org wrote: >>> Changeset: 8d10ff8fe9fd >>> Author: scolebourne >>> Date: 2012-12-17 18:55 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d10ff8fe9fd >>> >>> Rename global package to calendar >>> >>> + src/share/classes/javax/time/calendar/ChronoDateImpl.java >>> + src/share/classes/javax/time/calendar/HijrahChrono.java >>> + src/share/classes/javax/time/calendar/HijrahDate.java >>> + src/share/classes/javax/time/calendar/HijrahEra.java >>> + src/share/classes/javax/time/calendar/JapaneseChrono.java >>> + src/share/classes/javax/time/calendar/JapaneseDate.java >>> + src/share/classes/javax/time/calendar/JapaneseEra.java >>> + src/share/classes/javax/time/calendar/MinguoChrono.java >>> + src/share/classes/javax/time/calendar/MinguoDate.java >>> + src/share/classes/javax/time/calendar/MinguoEra.java >>> + src/share/classes/javax/time/calendar/Ser.java >>> + src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >>> + src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >>> + src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >>> + src/share/classes/javax/time/calendar/package.html >>> - src/share/classes/javax/time/chrono/global/ChronoDateImpl.java >>> - src/share/classes/javax/time/chrono/global/HijrahChrono.java >>> - src/share/classes/javax/time/chrono/global/HijrahDate.java >>> - src/share/classes/javax/time/chrono/global/HijrahEra.java >>> - src/share/classes/javax/time/chrono/global/JapaneseChrono.java >>> - src/share/classes/javax/time/chrono/global/JapaneseDate.java >>> - src/share/classes/javax/time/chrono/global/JapaneseEra.java >>> - src/share/classes/javax/time/chrono/global/MinguoChrono.java >>> - src/share/classes/javax/time/chrono/global/MinguoDate.java >>> - src/share/classes/javax/time/chrono/global/MinguoEra.java >>> - src/share/classes/javax/time/chrono/global/Ser.java >>> - src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java >>> - src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java >>> - src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java >>> - src/share/classes/javax/time/chrono/global/package.html >>> ! src/share/classes/javax/time/overview.html >>> + test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >>> + test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >>> + test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >>> + test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >>> + test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >>> + test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >>> ! test/javax/time/tck/javax/time/chrono/TestChrono.java >>> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >>> ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java >>> - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java >>> - >>> test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java >>> - test/javax/time/tck/javax/time/chrono/global/TestHijrahChrono.java >>> - test/javax/time/tck/javax/time/chrono/global/TestJapaneseChrono.java >>> - test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java >>> - >>> test/javax/time/tck/javax/time/chrono/global/TestThaiBuddhistChrono.java >>> >>> ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >>> ! >>> test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >>> >>> Changeset: b735c715d573 >>> Author: scolebourne >>> Date: 2012-12-17 19:11 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b735c715d573 >>> >>> Rename calendrical package to temporal >>> >>> ! src/share/classes/javax/time/DayOfWeek.java >>> ! src/share/classes/javax/time/Duration.java >>> ! src/share/classes/javax/time/Instant.java >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> ! src/share/classes/javax/time/Month.java >>> ! src/share/classes/javax/time/MonthDay.java >>> ! src/share/classes/javax/time/OffsetDate.java >>> ! src/share/classes/javax/time/OffsetDateTime.java >>> ! src/share/classes/javax/time/OffsetTime.java >>> ! src/share/classes/javax/time/Period.java >>> ! src/share/classes/javax/time/Year.java >>> ! src/share/classes/javax/time/YearMonth.java >>> ! src/share/classes/javax/time/ZoneId.java >>> ! src/share/classes/javax/time/ZoneOffset.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >>> ! src/share/classes/javax/time/calendar/HijrahChrono.java >>> ! src/share/classes/javax/time/calendar/HijrahDate.java >>> ! src/share/classes/javax/time/calendar/HijrahEra.java >>> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >>> ! src/share/classes/javax/time/calendar/JapaneseDate.java >>> ! src/share/classes/javax/time/calendar/JapaneseEra.java >>> ! src/share/classes/javax/time/calendar/MinguoChrono.java >>> ! src/share/classes/javax/time/calendar/MinguoDate.java >>> ! src/share/classes/javax/time/calendar/MinguoEra.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >>> - src/share/classes/javax/time/calendrical/ChronoField.java >>> - src/share/classes/javax/time/calendrical/ChronoUnit.java >>> - src/share/classes/javax/time/calendrical/DateTime.java >>> - src/share/classes/javax/time/calendrical/DateTimeAccessor.java >>> - src/share/classes/javax/time/calendrical/DateTimeAdjusters.java >>> - src/share/classes/javax/time/calendrical/DateTimeBuilder.java >>> - src/share/classes/javax/time/calendrical/DateTimeField.java >>> - src/share/classes/javax/time/calendrical/DateTimeValueRange.java >>> - src/share/classes/javax/time/calendrical/ISOWeeks.java >>> - src/share/classes/javax/time/calendrical/JulianDayField.java >>> - src/share/classes/javax/time/calendrical/PeriodUnit.java >>> - src/share/classes/javax/time/calendrical/WeekDefinition.java >>> - src/share/classes/javax/time/calendrical/package.html >>> ! src/share/classes/javax/time/chrono/Chrono.java >>> ! src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java >>> ! src/share/classes/javax/time/chrono/ChronoLocalDate.java >>> ! src/share/classes/javax/time/chrono/ChronoLocalDateTime.java >>> ! src/share/classes/javax/time/chrono/ChronoZonedDateTime.java >>> ! src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java >>> ! src/share/classes/javax/time/chrono/Era.java >>> ! src/share/classes/javax/time/chrono/ISOChrono.java >>> ! src/share/classes/javax/time/chrono/ISOEra.java >>> ! src/share/classes/javax/time/format/DateTimeFormatter.java >>> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >>> ! src/share/classes/javax/time/format/DateTimeFormatters.java >>> ! src/share/classes/javax/time/format/DateTimeParseContext.java >>> ! src/share/classes/javax/time/format/DateTimePrintContext.java >>> ! src/share/classes/javax/time/format/DateTimeTextProvider.java >>> ! src/share/classes/javax/time/overview.html >>> ! src/share/classes/javax/time/package.html >>> + src/share/classes/javax/time/temporal/ChronoField.java >>> + src/share/classes/javax/time/temporal/ChronoUnit.java >>> + src/share/classes/javax/time/temporal/DateTime.java >>> + src/share/classes/javax/time/temporal/DateTimeAccessor.java >>> + src/share/classes/javax/time/temporal/DateTimeAdjusters.java >>> + src/share/classes/javax/time/temporal/DateTimeBuilder.java >>> + src/share/classes/javax/time/temporal/DateTimeField.java >>> + src/share/classes/javax/time/temporal/DateTimeValueRange.java >>> + src/share/classes/javax/time/temporal/ISOWeeks.java >>> + src/share/classes/javax/time/temporal/JulianDayField.java >>> + src/share/classes/javax/time/temporal/PeriodUnit.java >>> + src/share/classes/javax/time/temporal/WeekDefinition.java >>> + src/share/classes/javax/time/temporal/package.html >>> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >>> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >>> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >>> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >>> ! test/javax/time/tck/javax/time/TCKDuration.java >>> ! test/javax/time/tck/javax/time/TCKLocalDate.java >>> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >>> ! test/javax/time/tck/javax/time/TCKLocalTime.java >>> ! test/javax/time/tck/javax/time/TCKMonth.java >>> ! test/javax/time/tck/javax/time/TCKOffsetDate.java >>> ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java >>> ! test/javax/time/tck/javax/time/TCKOffsetTime.java >>> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >>> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >>> - test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java >>> - test/javax/time/tck/javax/time/calendrical/TCKISOWeeks.java >>> - test/javax/time/tck/javax/time/calendrical/TCKJulianDayField.java >>> - test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java >>> - test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java >>> - test/javax/time/tck/javax/time/calendrical/TCKYear.java >>> - test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java >>> ! test/javax/time/tck/javax/time/chrono/TestChrono.java >>> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >>> ! test/javax/time/tck/javax/time/chrono/TestISOChrono.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >>> ! >>> test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java >>> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java >>> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldPrinter.java >>> + test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java >>> + test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >>> + test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java >>> + test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >>> + test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java >>> + test/javax/time/tck/javax/time/temporal/TCKYear.java >>> + test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >>> ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java >>> ! test/javax/time/test/java/util/TestFormatter.java >>> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >>> ! test/javax/time/test/javax/time/MockSimplePeriod.java >>> ! test/javax/time/test/javax/time/TestDayOfWeek.java >>> ! test/javax/time/test/javax/time/TestInstant.java >>> ! test/javax/time/test/javax/time/TestLocalDate.java >>> ! test/javax/time/test/javax/time/TestLocalDateTime.java >>> ! test/javax/time/test/javax/time/TestMonth.java >>> ! test/javax/time/test/javax/time/TestOffsetDateTime.java >>> ! test/javax/time/test/javax/time/TestPeriod.java >>> ! test/javax/time/test/javax/time/TestPeriodParser.java >>> ! test/javax/time/test/javax/time/TestZoneId.java >>> ! test/javax/time/test/javax/time/TestZoneOffset.java >>> - test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java >>> - test/javax/time/test/javax/time/calendrical/MockFieldValue.java >>> - test/javax/time/test/javax/time/calendrical/TestChronoUnit.java >>> - >>> test/javax/time/test/javax/time/calendrical/TestDateTimeAdjusters.java >>> - >>> test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java >>> - >>> test/javax/time/test/javax/time/calendrical/TestDateTimeValueRange.java >>> - test/javax/time/test/javax/time/calendrical/TestMonthDay.java >>> - test/javax/time/test/javax/time/calendrical/TestYear.java >>> - test/javax/time/test/javax/time/calendrical/TestYearMonth.java >>> ! test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java >>> ! test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >>> ! >>> test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >>> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >>> ! test/javax/time/test/javax/time/format/TestCharLiteralParser.java >>> ! test/javax/time/test/javax/time/format/TestDateTimeFormatter.java >>> ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java >>> ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java >>> ! test/javax/time/test/javax/time/format/TestNumberParser.java >>> ! test/javax/time/test/javax/time/format/TestNumberPrinter.java >>> ! test/javax/time/test/javax/time/format/TestPadParserDecorator.java >>> ! test/javax/time/test/javax/time/format/TestReducedParser.java >>> ! test/javax/time/test/javax/time/format/TestReducedPrinter.java >>> ! test/javax/time/test/javax/time/format/TestStringLiteralParser.java >>> ! test/javax/time/test/javax/time/format/TestTextParser.java >>> ! test/javax/time/test/javax/time/format/TestTextPrinter.java >>> ! test/javax/time/test/javax/time/format/TestZoneIdParser.java >>> ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java >>> ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java >>> ! test/javax/time/test/javax/time/format/TestZoneTextPrinterParser.java >>> + test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >>> + test/javax/time/test/javax/time/temporal/MockFieldValue.java >>> + test/javax/time/test/javax/time/temporal/TestChronoUnit.java >>> + test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java >>> + >>> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >>> + test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java >>> + test/javax/time/test/javax/time/temporal/TestMonthDay.java >>> + test/javax/time/test/javax/time/temporal/TestYear.java >>> + test/javax/time/test/javax/time/temporal/TestYearMonth.java >>> >>> Changeset: 29c29abd5588 >>> Author: scolebourne >>> Date: 2012-12-17 19:36 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/29c29abd5588 >>> >>> Rename chrono package to temporal >>> >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> ! src/share/classes/javax/time/Month.java >>> ! src/share/classes/javax/time/MonthDay.java >>> ! src/share/classes/javax/time/OffsetDate.java >>> ! src/share/classes/javax/time/Period.java >>> ! src/share/classes/javax/time/Year.java >>> ! src/share/classes/javax/time/YearMonth.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >>> ! src/share/classes/javax/time/calendar/HijrahChrono.java >>> ! src/share/classes/javax/time/calendar/HijrahDate.java >>> ! src/share/classes/javax/time/calendar/HijrahEra.java >>> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >>> ! src/share/classes/javax/time/calendar/JapaneseDate.java >>> ! src/share/classes/javax/time/calendar/JapaneseEra.java >>> ! src/share/classes/javax/time/calendar/MinguoChrono.java >>> ! src/share/classes/javax/time/calendar/MinguoDate.java >>> ! src/share/classes/javax/time/calendar/MinguoEra.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >>> ! src/share/classes/javax/time/calendar/package.html >>> - src/share/classes/javax/time/chrono/Ser.java >>> - src/share/classes/javax/time/chrono/package.html >>> ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java >>> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >>> ! src/share/classes/javax/time/overview.html >>> ! src/share/classes/javax/time/temporal/Chrono.java < >>> src/share/classes/javax/time/chrono/Chrono.java >>> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java < >>> src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/ChronoField.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java < >>> src/share/classes/javax/time/chrono/ChronoLocalDate.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java < >>> src/share/classes/javax/time/chrono/ChronoLocalDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoUnit.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java < >>> src/share/classes/javax/time/chrono/ChronoZonedDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >>> < src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/DateTimeAccessor.java >>> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >>> ! src/share/classes/javax/time/temporal/Era.java < >>> src/share/classes/javax/time/chrono/Era.java >>> ! src/share/classes/javax/time/temporal/ISOChrono.java < >>> src/share/classes/javax/time/chrono/ISOChrono.java >>> ! src/share/classes/javax/time/temporal/ISOEra.java < >>> src/share/classes/javax/time/chrono/ISOEra.java >>> + src/share/classes/javax/time/temporal/Ser.java >>> ! src/share/classes/javax/time/temporal/WeekDefinition.java >>> ! src/share/classes/javax/time/temporal/package.html >>> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >>> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >>> ! test/javax/time/tck/javax/time/TCKLocalDate.java >>> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >>> ! test/javax/time/tck/javax/time/TCKMonth.java >>> ! test/javax/time/tck/javax/time/TCKOffsetDate.java >>> ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java >>> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >>> ! test/javax/time/tck/javax/time/temporal/TestChrono.java < >>> test/javax/time/tck/javax/time/chrono/TestChrono.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java < >>> test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java >>> ! >>> test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >>> < test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java >>> ! >>> test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >>> < test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java < >>> test/javax/time/tck/javax/time/chrono/TestISOChrono.java >>> ! test/javax/time/test/javax/time/temporal/TestISOChronoImpl.java < >>> test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java >>> ! >>> test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java >>> < test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java >>> ! >>> test/javax/time/test/javax/time/temporal/TestThaiBuddhistChronoImpl.java >>> < >>> test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java >>> >>> Changeset: c9f5a3859101 >>> Author: scolebourne >>> Date: 2012-12-17 20:05 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9f5a3859101 >>> >>> Move base classes to temporal >>> >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> - src/share/classes/javax/time/OffsetDateTime.java >>> - src/share/classes/javax/time/OffsetTime.java >>> ! src/share/classes/javax/time/Ser.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/DateTimeAccessor.java >>> ! src/share/classes/javax/time/temporal/MonthDay.java < >>> src/share/classes/javax/time/MonthDay.java >>> ! src/share/classes/javax/time/temporal/OffsetDate.java < >>> src/share/classes/javax/time/OffsetDate.java >>> + src/share/classes/javax/time/temporal/OffsetDateTime.java >>> + src/share/classes/javax/time/temporal/OffsetTime.java >>> ! src/share/classes/javax/time/temporal/Ser.java >>> ! src/share/classes/javax/time/temporal/Year.java < >>> src/share/classes/javax/time/Year.java >>> ! src/share/classes/javax/time/temporal/YearMonth.java < >>> src/share/classes/javax/time/YearMonth.java >>> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >>> ! test/javax/time/resources/MonthDay.bin >>> ! test/javax/time/resources/OffsetDate.bin >>> ! test/javax/time/resources/OffsetDateTime.bin >>> ! test/javax/time/resources/OffsetTime.bin >>> ! test/javax/time/resources/Year.bin >>> ! test/javax/time/resources/YearMonth.bin >>> ! test/javax/time/tck/javax/time/TCKLocalDate.java >>> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >>> ! test/javax/time/tck/javax/time/TCKLocalTime.java >>> - test/javax/time/tck/javax/time/TCKOffsetTime.java >>> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >>> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >>> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java < >>> test/javax/time/tck/javax/time/TCKOffsetDate.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java < >>> test/javax/time/tck/javax/time/TCKOffsetDateTime.java >>> + test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >>> ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java >>> ! test/javax/time/test/java/util/TestFormatter.java >>> ! test/javax/time/test/javax/time/AbstractTest.java >>> ! test/javax/time/test/javax/time/TestLocalDate.java >>> ! test/javax/time/test/javax/time/TestLocalDateTime.java >>> - test/javax/time/test/javax/time/TestOffsetDateTime.java >>> - test/javax/time/test/javax/time/TestOffsetDateTime_instants.java >>> ! test/javax/time/test/javax/time/TestPeriod.java >>> ! >>> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >>> ! test/javax/time/test/javax/time/temporal/TestJapaneseChronoImpl.java >>> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >>> + test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >>> + >>> test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java >>> ! test/javax/time/test/javax/time/temporal/TestYear.java >>> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >>> ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java >>> >>> Changeset: 5127fd3d37f8 >>> Author: scolebourne >>> Date: 2012-12-17 20:22 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5127fd3d37f8 >>> >>> Rename DateTime and accessor to Temporal >>> >>> ! src/share/classes/javax/time/DayOfWeek.java >>> ! src/share/classes/javax/time/Duration.java >>> ! src/share/classes/javax/time/Instant.java >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> ! src/share/classes/javax/time/Month.java >>> ! src/share/classes/javax/time/Period.java >>> ! src/share/classes/javax/time/ZoneId.java >>> ! src/share/classes/javax/time/ZoneOffset.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >>> ! src/share/classes/javax/time/calendar/HijrahChrono.java >>> ! src/share/classes/javax/time/calendar/HijrahEra.java >>> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >>> ! src/share/classes/javax/time/calendar/MinguoChrono.java >>> ! src/share/classes/javax/time/calendar/MinguoEra.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >>> ! src/share/classes/javax/time/format/DateTimeFormatter.java >>> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >>> ! src/share/classes/javax/time/format/DateTimePrintContext.java >>> ! src/share/classes/javax/time/temporal/Chrono.java >>> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/ChronoField.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoUnit.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >>> - src/share/classes/javax/time/temporal/DateTime.java >>> ! src/share/classes/javax/time/temporal/DateTimeAdjusters.java >>> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >>> ! src/share/classes/javax/time/temporal/DateTimeField.java >>> ! src/share/classes/javax/time/temporal/Era.java >>> ! src/share/classes/javax/time/temporal/ISOChrono.java >>> ! src/share/classes/javax/time/temporal/ISOEra.java >>> ! src/share/classes/javax/time/temporal/ISOWeeks.java >>> ! src/share/classes/javax/time/temporal/JulianDayField.java >>> ! src/share/classes/javax/time/temporal/MonthDay.java >>> ! src/share/classes/javax/time/temporal/OffsetDate.java >>> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >>> ! src/share/classes/javax/time/temporal/OffsetTime.java >>> ! src/share/classes/javax/time/temporal/PeriodUnit.java >>> + src/share/classes/javax/time/temporal/Temporal.java >>> = src/share/classes/javax/time/temporal/TemporalAccessor.java < >>> src/share/classes/javax/time/temporal/DateTimeAccessor.java >>> ! src/share/classes/javax/time/temporal/WeekDefinition.java >>> ! src/share/classes/javax/time/temporal/Year.java >>> ! src/share/classes/javax/time/temporal/YearMonth.java >>> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >>> ! test/javax/time/tck/javax/time/TCKLocalDate.java >>> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >>> ! test/javax/time/tck/javax/time/TCKLocalTime.java >>> ! test/javax/time/tck/javax/time/TCKMonth.java >>> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >>> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >>> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >>> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >>> ! test/javax/time/test/javax/time/MockSimplePeriod.java >>> ! test/javax/time/test/javax/time/TestDayOfWeek.java >>> ! test/javax/time/test/javax/time/TestInstant.java >>> ! test/javax/time/test/javax/time/TestLocalDate.java >>> ! test/javax/time/test/javax/time/TestLocalDateTime.java >>> ! test/javax/time/test/javax/time/TestMonth.java >>> ! test/javax/time/test/javax/time/TestZoneId.java >>> ! test/javax/time/test/javax/time/TestZoneOffset.java >>> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >>> ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >>> ! test/javax/time/test/javax/time/temporal/MockFieldValue.java >>> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >>> ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >>> ! test/javax/time/test/javax/time/temporal/TestYear.java >>> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >>> >>> Changeset: ea8791e95adb >>> Author: scolebourne >>> Date: 2012-12-17 20:34 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea8791e95adb >>> >>> Rename Field, Unit, Adjusters and ValueRange >>> >>> ! src/share/classes/javax/time/DayOfWeek.java >>> ! src/share/classes/javax/time/Duration.java >>> ! src/share/classes/javax/time/Instant.java >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> ! src/share/classes/javax/time/Month.java >>> ! src/share/classes/javax/time/Period.java >>> ! src/share/classes/javax/time/ZoneId.java >>> ! src/share/classes/javax/time/ZoneOffset.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/calendar/ChronoDateImpl.java >>> ! src/share/classes/javax/time/calendar/HijrahChrono.java >>> ! src/share/classes/javax/time/calendar/HijrahDate.java >>> ! src/share/classes/javax/time/calendar/HijrahEra.java >>> ! src/share/classes/javax/time/calendar/JapaneseChrono.java >>> ! src/share/classes/javax/time/calendar/JapaneseDate.java >>> ! src/share/classes/javax/time/calendar/MinguoChrono.java >>> ! src/share/classes/javax/time/calendar/MinguoDate.java >>> ! src/share/classes/javax/time/calendar/MinguoEra.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java >>> ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java >>> ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java >>> ! src/share/classes/javax/time/format/DateTimeFormatters.java >>> ! src/share/classes/javax/time/format/DateTimeParseContext.java >>> ! src/share/classes/javax/time/format/DateTimePrintContext.java >>> ! src/share/classes/javax/time/format/DateTimeTextProvider.java >>> ! src/share/classes/javax/time/temporal/Adjusters.java < >>> src/share/classes/javax/time/temporal/DateTimeAdjusters.java >>> ! src/share/classes/javax/time/temporal/Chrono.java >>> ! src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/ChronoField.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDate.java >>> ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoUnit.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/DateTimeBuilder.java >>> - src/share/classes/javax/time/temporal/DateTimeValueRange.java >>> ! src/share/classes/javax/time/temporal/Era.java >>> ! src/share/classes/javax/time/temporal/ISOChrono.java >>> ! src/share/classes/javax/time/temporal/ISOEra.java >>> ! src/share/classes/javax/time/temporal/ISOWeeks.java >>> ! src/share/classes/javax/time/temporal/JulianDayField.java >>> ! src/share/classes/javax/time/temporal/MonthDay.java >>> ! src/share/classes/javax/time/temporal/OffsetDate.java >>> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >>> ! src/share/classes/javax/time/temporal/OffsetTime.java >>> ! src/share/classes/javax/time/temporal/Temporal.java >>> ! src/share/classes/javax/time/temporal/TemporalAccessor.java >>> ! src/share/classes/javax/time/temporal/TemporalField.java < >>> src/share/classes/javax/time/temporal/DateTimeField.java >>> ! src/share/classes/javax/time/temporal/TemporalUnit.java < >>> src/share/classes/javax/time/temporal/PeriodUnit.java >>> + src/share/classes/javax/time/temporal/ValueRange.java >>> ! src/share/classes/javax/time/temporal/WeekDefinition.java >>> ! src/share/classes/javax/time/temporal/Year.java >>> ! src/share/classes/javax/time/temporal/YearMonth.java >>> ! src/share/classes/javax/time/temporal/package.html >>> ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java >>> ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java >>> ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java >>> ! test/javax/time/tck/javax/time/TCKDayOfWeek.java >>> ! test/javax/time/tck/javax/time/TCKDuration.java >>> ! test/javax/time/tck/javax/time/TCKLocalDate.java >>> ! test/javax/time/tck/javax/time/TCKLocalDateTime.java >>> ! test/javax/time/tck/javax/time/TCKLocalTime.java >>> ! test/javax/time/tck/javax/time/TCKMonth.java >>> ! test/javax/time/tck/javax/time/TCKZoneOffset.java >>> ! test/javax/time/tck/javax/time/TCKZonedDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/calendar/TestHijrahChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestJapaneseChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestMinguoChrono.java >>> ! test/javax/time/tck/javax/time/calendar/TestThaiBuddhistChrono.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeTextPrinting.java >>> ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java >>> ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java >>> ! test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >>> ! test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java >>> ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java >>> ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYear.java >>> ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java >>> ! test/javax/time/tck/javax/time/temporal/TestISOChrono.java >>> ! test/javax/time/test/javax/time/AbstractDateTimeTest.java >>> ! test/javax/time/test/javax/time/MockSimplePeriod.java >>> ! test/javax/time/test/javax/time/TestDayOfWeek.java >>> ! test/javax/time/test/javax/time/TestLocalDate.java >>> ! test/javax/time/test/javax/time/TestLocalDateTime.java >>> ! test/javax/time/test/javax/time/TestMonth.java >>> ! test/javax/time/test/javax/time/TestZoneId.java >>> ! test/javax/time/test/javax/time/TestZoneOffset.java >>> ! test/javax/time/test/javax/time/format/AbstractTestPrinterParser.java >>> ! test/javax/time/test/javax/time/format/TestDateTimeTextProvider.java >>> ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java >>> ! test/javax/time/test/javax/time/format/TestNumberParser.java >>> ! test/javax/time/test/javax/time/format/TestReducedParser.java >>> ! test/javax/time/test/javax/time/format/TestReducedPrinter.java >>> ! test/javax/time/test/javax/time/format/TestTextParser.java >>> ! test/javax/time/test/javax/time/format/TestTextPrinter.java >>> ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java >>> ! test/javax/time/test/javax/time/temporal/MockFieldValue.java >>> ! test/javax/time/test/javax/time/temporal/TestDateTimeAdjusters.java >>> ! >>> test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java >>> ! test/javax/time/test/javax/time/temporal/TestDateTimeValueRange.java >>> ! test/javax/time/test/javax/time/temporal/TestMonthDay.java >>> ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java >>> ! test/javax/time/test/javax/time/temporal/TestYear.java >>> ! test/javax/time/test/javax/time/temporal/TestYearMonth.java >>> >>> Changeset: ab1cb3b2e469 >>> Author: scolebourne >>> Date: 2012-12-17 21:39 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ab1cb3b2e469 >>> >>> Fixup Javadoc >>> >>> ! make/netbeans/threeten/build.xml >>> ! src/share/classes/javax/time/DayOfWeek.java >>> ! src/share/classes/javax/time/Duration.java >>> ! src/share/classes/javax/time/Instant.java >>> ! src/share/classes/javax/time/LocalDate.java >>> ! src/share/classes/javax/time/LocalDateTime.java >>> ! src/share/classes/javax/time/LocalTime.java >>> ! src/share/classes/javax/time/Month.java >>> ! src/share/classes/javax/time/Period.java >>> ! src/share/classes/javax/time/ZoneId.java >>> ! src/share/classes/javax/time/ZoneOffset.java >>> ! src/share/classes/javax/time/ZonedDateTime.java >>> ! src/share/classes/javax/time/format/DateTimeFormatter.java >>> ! src/share/classes/javax/time/format/DateTimeParseContext.java >>> ! src/share/classes/javax/time/format/DateTimePrintContext.java >>> ! src/share/classes/javax/time/overview.html >>> ! src/share/classes/javax/time/package.html >>> ! src/share/classes/javax/time/temporal/Chrono.java >>> ! src/share/classes/javax/time/temporal/MonthDay.java >>> ! src/share/classes/javax/time/temporal/OffsetDate.java >>> ! src/share/classes/javax/time/temporal/OffsetDateTime.java >>> ! src/share/classes/javax/time/temporal/OffsetTime.java >>> ! src/share/classes/javax/time/temporal/Temporal.java >>> ! src/share/classes/javax/time/temporal/TemporalAccessor.java >>> ! src/share/classes/javax/time/temporal/TemporalField.java >>> ! src/share/classes/javax/time/temporal/TemporalUnit.java >>> ! src/share/classes/javax/time/temporal/WeekDefinition.java >>> ! src/share/classes/javax/time/temporal/Year.java >>> ! src/share/classes/javax/time/temporal/YearMonth.java >>> >>> Changeset: 8d631ba2097d >>> Author: scolebourne >>> Date: 2012-12-17 21:50 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d631ba2097d >>> >>> Rename ChronoDateTimeImpl to ChronoLocalDateTimeImpl >>> >>> ! src/share/classes/javax/time/temporal/Chrono.java >>> - src/share/classes/javax/time/temporal/ChronoDateTimeImpl.java >>> + src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java >>> ! src/share/classes/javax/time/temporal/OffsetDate.java >>> ! src/share/classes/javax/time/temporal/OffsetTime.java >>> ! src/share/classes/javax/time/temporal/Ser.java >>> >>> Changeset: 8ea3ee2ea41b >>> Author: scolebourne >>> Date: 2012-12-17 22:02 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8ea3ee2ea41b >>> >>> Rename ISOWeeks to ISOFields >>> >>> ! src/share/classes/javax/time/format/DateTimeFormatters.java >>> + src/share/classes/javax/time/temporal/ISOFields.java >>> - src/share/classes/javax/time/temporal/ISOWeeks.java >>> ! src/share/classes/javax/time/temporal/package.html >>> ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java >>> + test/javax/time/tck/javax/time/temporal/TCKISOFields.java >>> - test/javax/time/tck/javax/time/temporal/TCKISOWeeks.java >>> >>> Changeset: 3fe752bb8753 >>> Author: scolebourne >>> Date: 2012-12-17 22:05 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3fe752bb8753 >>> >>> Remove duplicated inner period class >>> >>> ! src/share/classes/javax/time/temporal/ISOFields.java >>> >>> Changeset: b050690beaa4 >>> Author: scolebourne >>> Date: 2012-12-17 22:52 +0000 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b050690beaa4 >>> >>> Add quarter-of-year and day-of-quarter to ISOFields >>> >>> See #170 >>> >>> ! src/share/classes/javax/time/temporal/ISOFields.java >>> ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java >>> >> From masayoshi.okutsu at oracle.com Tue Dec 18 00:37:35 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 18 Dec 2012 17:37:35 +0900 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated the j.u.Formatter to use the updated package/class names In-Reply-To: <20121218080118.2E86547208@hg.openjdk.java.net> References: <20121218080118.2E86547208@hg.openjdk.java.net> Message-ID: <50D02B4F.2020905@oracle.com> @@ -270,7 +270,7 @@ import sun.util.locale.provider.TimeZone * *
  • Date/Time - may be applied to Java types which are capable of * encoding a date or time: {@code long}, {@link Long}, {@link Calendar}, - * {@link Date} and {@link javax.time.calendrical.DateTimeAccessor DateTimeAccessor} + * {@link Date} and {@link javax.time.calendrical.TemporalAccessor TemporalAccessor} * *
  • Percent - produces a literal {@code '%'} * ('\u0025') @@ -1504,7 +1504,7 @@ import sun.util.locale.provider.TimeZone * *

    This conversion may be applied to {@code long}, {@link Long}, {@link * Calendar}, {@link Date} and - * {@link javax.time.calendrical.DateTimeAccessor DateTimeAccessor} + * {@link javax.time.calendrical.TemporalAccessor TemporalAccessor} * * * javax.time.calendrical.TemporalAccessor -> javax.time.temporal.TemporalAccessor I made the same mistake for my own fix. :-) Other doc related files require refactoring as well. I've fixed only make/docs/CORE_PKGS.gmk. diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk --- a/make/docs/CORE_PKGS.gmk +++ b/make/docs/CORE_PKGS.gmk @@ -218,10 +218,9 @@ javax.swing.plaf.nimbus \ javax.swing.plaf.synth \ javax.time \ - javax.time.calendrical \ - javax.time.chrono \ - javax.time.chrono.global \ + javax.time.calendar \ javax.time.format \ + javax.time.temporal \ javax.time.zone \ javax.tools \ javax.tools.annotation \ My repo is synced with the TL repo and probably I can't push my changes... Masayoshi On 12/18/2012 5:00 PM, xueming.shen at oracle.com wrote: > Changeset: f2d602792e0b > Author: sherman > Date: 2012-12-18 00:04 -0800 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f2d602792e0b > > Updated the j.u.Formatter to use the updated package/class names > > ! src/share/classes/java/util/Formatter.java > From xueming.shen at oracle.com Tue Dec 18 00:44:14 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 18 Dec 2012 08:44:14 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated the CORE_PKGS.gmk to use the updated package names Message-ID: <20121218084426.E31184720C@hg.openjdk.java.net> Changeset: 0bfd8b18093e Author: sherman Date: 2012-12-18 00:48 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0bfd8b18093e Updated the CORE_PKGS.gmk to use the updated package names ! make/docs/CORE_PKGS.gmk From xueming.shen at oracle.com Tue Dec 18 00:51:01 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 18 Dec 2012 08:51:01 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: updated the doc link in j.u.Formatter Message-ID: <20121218085113.179C24720D@hg.openjdk.java.net> Changeset: 80f06317bb4b Author: sherman Date: 2012-12-18 00:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/80f06317bb4b updated the doc link in j.u.Formatter ! src/share/classes/java/util/Formatter.java From xueming.shen at oracle.com Tue Dec 18 00:51:57 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 00:51:57 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated the j.u.Formatter to use the updated package/class names In-Reply-To: <50D02B4F.2020905@oracle.com> References: <20121218080118.2E86547208@hg.openjdk.java.net> <50D02B4F.2020905@oracle.com> Message-ID: <50D02EAD.2090303@oracle.com> Updated. That's replace-regex, not me:-) Thanks! -Sherman On 12/18/2012 12:37 AM, Masayoshi Okutsu wrote: > @@ -270,7 +270,7 @@ import sun.util.locale.provider.TimeZone > * > *
  • Date/Time - may be applied to Java types which are > capable of > * encoding a date or time: {@code long}, {@link Long}, {@link > Calendar}, > - * {@link Date} and {@link javax.time.calendrical.DateTimeAccessor > DateTimeAccessor} > + * {@link Date} and {@link javax.time.calendrical.TemporalAccessor > TemporalAccessor} > * > *
  • Percent - produces a literal {@code '%'} > * ('\u0025') > @@ -1504,7 +1504,7 @@ import sun.util.locale.provider.TimeZone > * > *

    This conversion may be applied to {@code long}, {@link Long}, > {@link > * Calendar}, {@link Date} and > - * {@link javax.time.calendrical.DateTimeAccessor DateTimeAccessor} > + * {@link javax.time.calendrical.TemporalAccessor TemporalAccessor} > * > *

    • > * > > javax.time.calendrical.TemporalAccessor > -> javax.time.temporal.TemporalAccessor > > I made the same mistake for my own fix. :-) > > Other doc related files require refactoring as well. I've fixed only > make/docs/CORE_PKGS.gmk. > > diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk > --- a/make/docs/CORE_PKGS.gmk > +++ b/make/docs/CORE_PKGS.gmk > @@ -218,10 +218,9 @@ > javax.swing.plaf.nimbus \ > javax.swing.plaf.synth \ > javax.time \ > - javax.time.calendrical \ > - javax.time.chrono \ > - javax.time.chrono.global \ > + javax.time.calendar \ > javax.time.format \ > + javax.time.temporal \ > javax.time.zone \ > javax.tools \ > javax.tools.annotation \ > > My repo is synced with the TL repo and probably I can't push my > changes... > > Masayoshi > > On 12/18/2012 5:00 PM, xueming.shen at oracle.com wrote: >> Changeset: f2d602792e0b >> Author: sherman >> Date: 2012-12-18 00:04 -0800 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f2d602792e0b >> >> Updated the j.u.Formatter to use the updated package/class names >> >> ! src/share/classes/java/util/Formatter.java >> > From Roger.Riggs at oracle.com Tue Dec 18 06:36:14 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 09:36:14 -0500 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated the j.u.Formatter to use the updated package/class names In-Reply-To: <50D02EAD.2090303@oracle.com> References: <20121218080118.2E86547208@hg.openjdk.java.net> <50D02B4F.2020905@oracle.com> <50D02EAD.2090303@oracle.com> Message-ID: <50D07F5E.1040005@oracle.com> Thanks Sherman and Masayoshi for fixing the build. The threeten workspace is easy and fairly quick to build from the command line using the new build system. % # from the top of the forest % configure % make -f NewMakefile.gmk But knowing what to fix (and where to fix it) seems to require some skill/knowledge that takes time to acquire. Thanks, Roger On 12/18/2012 3:51 AM, Xueming Shen wrote: > Updated. That's replace-regex, not me:-) > > Thanks! > -Sherman > > On 12/18/2012 12:37 AM, Masayoshi Okutsu wrote: >> @@ -270,7 +270,7 @@ import sun.util.locale.provider.TimeZone >> * >> *
  • Date/Time - may be applied to Java types which are >> capable of >> * encoding a date or time: {@code long}, {@link Long}, {@link >> Calendar}, >> - * {@link Date} and {@link javax.time.calendrical.DateTimeAccessor >> DateTimeAccessor} >> + * {@link Date} and {@link javax.time.calendrical.TemporalAccessor >> TemporalAccessor} >> * >> *
  • Percent - produces a literal {@code '%'} >> * ('\u0025') >> @@ -1504,7 +1504,7 @@ import sun.util.locale.provider.TimeZone >> * >> *

    This conversion may be applied to {@code long}, {@link Long}, >> {@link >> * Calendar}, {@link Date} and >> - * {@link javax.time.calendrical.DateTimeAccessor DateTimeAccessor} >> + * {@link javax.time.calendrical.TemporalAccessor TemporalAccessor} >> * >> *

    • >> * >> >> javax.time.calendrical.TemporalAccessor >> -> javax.time.temporal.TemporalAccessor >> >> I made the same mistake for my own fix. :-) >> >> Other doc related files require refactoring as well. I've fixed only >> make/docs/CORE_PKGS.gmk. >> >> diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk >> --- a/make/docs/CORE_PKGS.gmk >> +++ b/make/docs/CORE_PKGS.gmk >> @@ -218,10 +218,9 @@ >> javax.swing.plaf.nimbus \ >> javax.swing.plaf.synth \ >> javax.time \ >> - javax.time.calendrical \ >> - javax.time.chrono \ >> - javax.time.chrono.global \ >> + javax.time.calendar \ >> javax.time.format \ >> + javax.time.temporal \ >> javax.time.zone \ >> javax.tools \ >> javax.tools.annotation \ >> >> My repo is synced with the TL repo and probably I can't push my >> changes... >> >> Masayoshi >> >> On 12/18/2012 5:00 PM, xueming.shen at oracle.com wrote: >>> Changeset: f2d602792e0b >>> Author: sherman >>> Date: 2012-12-18 00:04 -0800 >>> URL: >>> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f2d602792e0b >>> >>> Updated the j.u.Formatter to use the updated package/class names >>> >>> ! src/share/classes/java/util/Formatter.java >>> >> -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at oracle.com Tue Dec 18 07:00:04 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 10:00:04 -0500 Subject: [threeten-dev] Webrev to fix #175 Remove Offset* classes int-based factory methods Message-ID: <50D084F4.9090702@oracle.com> Hi, #175 Remove Offset* classes int-based factory methods See: http://cr.openjdk.java.net/~rriggs/webrev-factory/ Comments? Roger From scolebourne at joda.org Tue Dec 18 07:18:05 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 18 Dec 2012 15:18:05 +0000 Subject: [threeten-dev] [threeten-develop] Webrev to fix #175 Remove Offset* classes int-based factory methods In-Reply-To: <50D084F4.9090702@oracle.com> References: <50D084F4.9090702@oracle.com> Message-ID: Looks good to me. Stephen On 18 December 2012 15:00, Roger Riggs wrote: > Hi, > > #175 Remove Offset* classes int-based factory methods > > See: http://cr.openjdk.java.net/~rriggs/webrev-factory/ > > Comments? > > Roger > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From roger.riggs at oracle.com Tue Dec 18 07:54:41 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 18 Dec 2012 15:54:41 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121218155522.0805F47220@hg.openjdk.java.net> Changeset: 68c2e1b1dd17 Author: rriggs Date: 2012-12-18 09:56 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/68c2e1b1dd17 Fix 175 Remove Offset* classes int-based factory methods ! src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/OffsetTime.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/calendrical/TCKYear.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/test/javax/time/TestOffsetDateTime.java ! test/javax/time/test/javax/time/TestOffsetDateTime_instants.java ! test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java Changeset: 70000605d4c2 Author: rriggs Date: 2012-12-18 10:51 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/70000605d4c2 Merge - src/share/classes/javax/time/MonthDay.java - src/share/classes/javax/time/Year.java - src/share/classes/javax/time/YearMonth.java - src/share/classes/javax/time/calendrical/ChronoField.java - src/share/classes/javax/time/calendrical/ChronoUnit.java - src/share/classes/javax/time/calendrical/DateTime.java - src/share/classes/javax/time/calendrical/DateTimeAccessor.java - src/share/classes/javax/time/calendrical/DateTimeAdjusters.java - src/share/classes/javax/time/calendrical/DateTimeBuilder.java - src/share/classes/javax/time/calendrical/DateTimeField.java - src/share/classes/javax/time/calendrical/DateTimeValueRange.java - src/share/classes/javax/time/calendrical/ISOWeeks.java - src/share/classes/javax/time/calendrical/JulianDayField.java - src/share/classes/javax/time/calendrical/PeriodUnit.java - src/share/classes/javax/time/calendrical/WeekDefinition.java - src/share/classes/javax/time/calendrical/package.html - src/share/classes/javax/time/chrono/Chrono.java - src/share/classes/javax/time/chrono/ChronoDateTimeImpl.java - src/share/classes/javax/time/chrono/ChronoLocalDate.java - src/share/classes/javax/time/chrono/ChronoLocalDateTime.java - src/share/classes/javax/time/chrono/ChronoZonedDateTime.java - src/share/classes/javax/time/chrono/ChronoZonedDateTimeImpl.java - src/share/classes/javax/time/chrono/Era.java - src/share/classes/javax/time/chrono/ISOChrono.java - src/share/classes/javax/time/chrono/ISOEra.java - src/share/classes/javax/time/chrono/Ser.java - src/share/classes/javax/time/chrono/global/ChronoDateImpl.java - src/share/classes/javax/time/chrono/global/HijrahChrono.java - src/share/classes/javax/time/chrono/global/HijrahDate.java - src/share/classes/javax/time/chrono/global/HijrahEra.java - src/share/classes/javax/time/chrono/global/JapaneseChrono.java - src/share/classes/javax/time/chrono/global/JapaneseDate.java - src/share/classes/javax/time/chrono/global/JapaneseEra.java - src/share/classes/javax/time/chrono/global/MinguoChrono.java - src/share/classes/javax/time/chrono/global/MinguoDate.java - src/share/classes/javax/time/chrono/global/MinguoEra.java - src/share/classes/javax/time/chrono/global/Ser.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistChrono.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java - src/share/classes/javax/time/chrono/global/ThaiBuddhistEra.java - src/share/classes/javax/time/chrono/global/package.html - src/share/classes/javax/time/chrono/package.html ! src/share/classes/javax/time/temporal/OffsetDate.java < src/share/classes/javax/time/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java < src/share/classes/javax/time/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java < src/share/classes/javax/time/OffsetTime.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java - test/javax/time/tck/javax/time/calendrical/TCKDateTimeAdjusters.java - test/javax/time/tck/javax/time/calendrical/TCKISOWeeks.java - test/javax/time/tck/javax/time/calendrical/TCKJulianDayField.java - test/javax/time/tck/javax/time/calendrical/TCKMonthDay.java - test/javax/time/tck/javax/time/calendrical/TCKWeekDefinition.java - test/javax/time/tck/javax/time/calendrical/TCKYearMonth.java - test/javax/time/tck/javax/time/chrono/TestChrono.java - test/javax/time/tck/javax/time/chrono/TestChronoLocalDate.java - test/javax/time/tck/javax/time/chrono/TestChronoLocalDateTime.java - test/javax/time/tck/javax/time/chrono/TestChronoZonedDateTime.java - test/javax/time/tck/javax/time/chrono/TestISOChrono.java - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDate.java - test/javax/time/tck/javax/time/chrono/global/TestChronoLocalDateTime.java - test/javax/time/tck/javax/time/chrono/global/TestHijrahChrono.java - test/javax/time/tck/javax/time/chrono/global/TestJapaneseChrono.java - test/javax/time/tck/javax/time/chrono/global/TestMinguoChrono.java - test/javax/time/tck/javax/time/chrono/global/TestThaiBuddhistChrono.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java < test/javax/time/tck/javax/time/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java < test/javax/time/tck/javax/time/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java < test/javax/time/tck/javax/time/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java < test/javax/time/tck/javax/time/calendrical/TCKYear.java - test/javax/time/test/javax/time/calendrical/MockFieldNoValue.java - test/javax/time/test/javax/time/calendrical/MockFieldValue.java - test/javax/time/test/javax/time/calendrical/TestChronoUnit.java - test/javax/time/test/javax/time/calendrical/TestDateTimeAdjusters.java - test/javax/time/test/javax/time/calendrical/TestDateTimeValueRange.java - test/javax/time/test/javax/time/calendrical/TestMonthDay.java - test/javax/time/test/javax/time/calendrical/TestYear.java - test/javax/time/test/javax/time/calendrical/TestYearMonth.java - test/javax/time/test/javax/time/chrono/TestISOChronoImpl.java - test/javax/time/test/javax/time/chrono/TestJapaneseChronoImpl.java - test/javax/time/test/javax/time/chrono/TestThaiBuddhistChronoImpl.java ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java < test/javax/time/test/javax/time/calendrical/TestDateTimeBuilderCombinations.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java < test/javax/time/test/javax/time/TestOffsetDateTime.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java < test/javax/time/test/javax/time/TestOffsetDateTime_instants.java From douglas.surber at oracle.com Tue Dec 18 08:32:49 2012 From: douglas.surber at oracle.com (Douglas Surber) Date: Tue, 18 Dec 2012 08:32:49 -0800 Subject: [threeten-dev] [threeten-develop] Webrev to fix #175 Remove Offset* classes int-based factory methods In-Reply-To: <50D084F4.9090702@oracle.com> References: <50D084F4.9090702@oracle.com> Message-ID: <6.2.5.6.2.20121218082717.04c9bea8@oracle.com> Main disadvantage is that it requires a JDBC programmer to import LocalDate/Time and ZoneOffset in order to use OffsetDate/Time. With the int factory methods one can write OffsetDateTime odt = OffsetDateTime.of(year, month, day, hour, minute, second, nano, offsetHhours, offsetMinutes); But without those methods one has to import and think about LocalDateTime and ZoneOffset. LocalDateTime ldt = LocalDateTime.of(year, month, day, hour, minute, second, nano); ZoneOffset zq = ZoneOffset(offsetHour, offsetMinute); OffsetDateTime odt = OffsetDateTime(ldt, zo); I'm not a fan of the long arg list but nor am I a fan of having to introduce two additional types in order to construct the thing I actually care about. I would vote to leave them in. Douglas At 07:00 AM 12/18/2012, Roger Riggs wrote: >Hi, > >#175 Remove Offset* classes int-based factory methods > >See: http://cr.openjdk.java.net/~rriggs/webrev-factory/ > >Comments? > >Roger > > >------------------------------------------------------------------------------ >LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >Remotely access PCs and mobile devices and provide instant support >Improve your efficiency, and focus on delivering more value-add >services >Discover what IT Professionals Know. Rescue delivers >http://p.sf.net/sfu/logmein_12329d2d >_______________________________________________ >threeten-develop mailing list >threeten-develop at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/threeten-develop From yoshito_umaoka at us.ibm.com Tue Dec 18 09:23:02 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 18 Dec 2012 12:23:02 -0500 Subject: [threeten-dev] Islamic calendar variants need disambiguation In-Reply-To: <50CF9851.2060804@oracle.com> References: <50CF9851.2060804@oracle.com> Message-ID: > Yoshito-san, > > I would like to get your opinion about identifying Islamic calendar > variants in CLDR. It defines "islamic" and "islamicc" in calendar.xml > for the astronomical and algorithmic variants respectively, while > JSR-310 needs to clearly identify the variants and distinctively > identify each of them, in order to identify the dates correctly. > > For example, the Umm Al-Qura calendar and Microsoft's Islamic calendar > implementation with the Kuwaiti algorithm are both algorithmic but they > are different, so the date information is not interchangeable under > "islamicc" between different variants. A date in one variant may > correspond to a different date in another variant. So, in terms of > ensuring correct exchange of Islamic date information, not identifying > the precise variants in the CLDR name space falls short of the use case > expectation. In JSR-310, we anticipate Islamic end users might have > their preferred Islamic calendar variant set in their user profile, or > an application may be supporting different variants in producing some > output with Islamic date information. > > May I ask if there is a chance to add more Islamic calendar variants or > enhance the calendar naming scheme to resolve this issue? Or is this > beyond the scope of CLDR? Do you suggest taking this to the CLDR list? I understand the issue. I don't think it's beyond the scope of CLDR. I think the major question is - how many variants are enough. Historically, CLDR project was spawned from ICU project. ICU calendar implementation is derived from a book - Caledrical Calculations (Nachum Deshowitz, Edward M. Reingold - ISBN 0-521-56413-1). In this book, "civil" calendar (arithmetic or tabular) is explained along with "religious" calendar which is based on astronomical observation. The "civil" algorithm explained in this book uses leap year [2,5,7,10,13,16,18,21,24,26,29] that is different from Microsoft's "Kawait algorithm". I was looking at some web pages. This page [http://www.staff.science.uu.nl/~gent0113/islam/islam_tabcal.htm] illustrates at least four different arithmetical variations. It also mentions that there are two possible variations for each intercalary scheme based on epochs. Also, by the nature of "religious" calendar, which may vary depending on astronomical observation of regional authorities, it is obviously not suited for identify the dates across different regions. Here is what I think - - CLDR type "islamic" is used for religious calendar now. Although actual date may vary, it is probably not worth adding variations. - CLDR type "islamicc" is used for arithmetical calendar now. This type could be separated into multiple different variations. I'm wondering if you can create a CLDR ticket with proposed types? I can add my comment and bring this to a CLDR meeting. Thanks, Yoshito From xueming.shen at oracle.com Tue Dec 18 09:49:36 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 09:49:36 -0800 Subject: [threeten-dev] Interface hierarchy Message-ID: <50D0ACB0.9010802@oracle.com> Given their interface hierarchy, it appears there is no reason why LD, LDT and ZDT still need to declare Temporal, WithAdjuster and Accessor explicitly? http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant -Sherman From scolebourne at joda.org Tue Dec 18 10:15:14 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 18 Dec 2012 18:15:14 +0000 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0ACB0.9010802@oracle.com> References: <50D0ACB0.9010802@oracle.com> Message-ID: I guess not. It does mean more developers will look at the Chrono interface though to see the inheritence, which isn't a good thing. Stephen On 18 December 2012 17:49, Xueming Shen wrote: > Given their interface hierarchy, it appears there is no reason why > LD, LDT and ZDT still need to declare Temporal, WithAdjuster and > Accessor explicitly? > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant > > -Sherman > > From Roger.Riggs at oracle.com Tue Dec 18 10:17:34 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 13:17:34 -0500 Subject: [threeten-dev] Interface hierarchy In-Reply-To: References: <50D0ACB0.9010802@oracle.com> Message-ID: <50D0B33E.4020301@oracle.com> Hi, I would retain "Temporal" since it is the type that appears in many signatures as representing the essential flexible type. I would also put "Temporal" first in the source code. Roger On 12/18/2012 1:15 PM, Stephen Colebourne wrote: > I guess not. It does mean more developers will look at the Chrono > interface though to see the inheritence, which isn't a good thing. > > Stephen > > > On 18 December 2012 17:49, Xueming Shen wrote: >> Given their interface hierarchy, it appears there is no reason why >> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >> Accessor explicitly? >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >> >> -Sherman >> >> -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Dec 18 10:28:11 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 10:28:11 -0800 Subject: [threeten-dev] Interface hierarchy In-Reply-To: References: <50D0ACB0.9010802@oracle.com> Message-ID: <50D0B5BB.8020604@oracle.com> What did you guys mean here? I believe removing the explicit/redundant declaration from the code will not change the javadoc output...you still get all the interfaces listed, the same way. Or guy meant those "developers" that who peek into the source code? -Sherman On 12/18/2012 10:15 AM, Stephen Colebourne wrote: > I guess not. It does mean more developers will look at the Chrono > interface though to see the inheritence, which isn't a good thing. > > Stephen > > > On 18 December 2012 17:49, Xueming Shen wrote: >> Given their interface hierarchy, it appears there is no reason why >> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >> Accessor explicitly? >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >> >> -Sherman >> >> From xueming.shen at oracle.com Tue Dec 18 10:30:23 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 10:30:23 -0800 Subject: [threeten-dev] missed ref in .html files Message-ID: <50D0B63F.4060804@oracle.com> http://cr.openjdk.java.net/~sherman/jdk8_threeten/packageInfo/ From scolebourne at joda.org Tue Dec 18 10:28:00 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 18 Dec 2012 18:28:00 +0000 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0B5BB.8020604@oracle.com> References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> Message-ID: It changes both. The Javadoc and the source code readers. I agree with Roger - Temporal first. Stephen On 18 December 2012 18:28, Xueming Shen wrote: > What did you guys mean here? I believe removing the explicit/redundant > declaration from the code will not change the javadoc output...you still get > all the interfaces listed, the same way. Or guy meant those "developers" > that who peek into the source code? > > -Sherman > > > On 12/18/2012 10:15 AM, Stephen Colebourne wrote: >> >> I guess not. It does mean more developers will look at the Chrono >> interface though to see the inheritence, which isn't a good thing. >> >> Stephen >> >> >> On 18 December 2012 17:49, Xueming Shen wrote: >>> >>> Given their interface hierarchy, it appears there is no reason why >>> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >>> Accessor explicitly? >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >>> >>> -Sherman >>> >>> > From scolebourne at joda.org Tue Dec 18 10:28:57 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 18 Dec 2012 18:28:57 +0000 Subject: [threeten-dev] missed ref in .html files In-Reply-To: <50D0B63F.4060804@oracle.com> References: <50D0B63F.4060804@oracle.com> Message-ID: Looks good Stephen On 18 December 2012 18:30, Xueming Shen wrote: > http://cr.openjdk.java.net/~sherman/jdk8_threeten/packageInfo/ From xueming.shen at oracle.com Tue Dec 18 10:46:08 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 10:46:08 -0800 Subject: [threeten-dev] Interface hierarchy In-Reply-To: References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> Message-ID: <50D0B9F0.3030909@oracle.com> On 12/18/2012 10:28 AM, Stephen Colebourne wrote: > It changes both. The Javadoc and the source code readers. The Temporal and their relatives will still be listed as they declares now in the current version. http://cr.openjdk.java.net/~sherman/jdk8_threeten/javadoc/ But if you want to list the Temporal explicitly as the first, you will have probably to explicitly put it first. ZDT now only has Temporal, the rest two have Temporal and WithAdjuster, kinda inconsistent. You want Temporal only or two? While make LD/LT/LDT/ZDT as adjuster is kinda of cool and sometime might be convenient, but personally I guess they might cause more confusion for the beginner, than the benefit they might bring in. -Sherman > I agree with Roger - Temporal first. > > Stephen > > > On 18 December 2012 18:28, Xueming Shen wrote: >> What did you guys mean here? I believe removing the explicit/redundant >> declaration from the code will not change the javadoc output...you still get >> all the interfaces listed, the same way. Or guy meant those "developers" >> that who peek into the source code? >> >> -Sherman >> >> >> On 12/18/2012 10:15 AM, Stephen Colebourne wrote: >>> I guess not. It does mean more developers will look at the Chrono >>> interface though to see the inheritence, which isn't a good thing. >>> >>> Stephen >>> >>> >>> On 18 December 2012 17:49, Xueming Shen wrote: >>>> Given their interface hierarchy, it appears there is no reason why >>>> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >>>> Accessor explicitly? >>>> >>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >>>> >>>> -Sherman >>>> >>>> From Roger.Riggs at oracle.com Tue Dec 18 10:53:59 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 13:53:59 -0500 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0B9F0.3030909@oracle.com> References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> <50D0B9F0.3030909@oracle.com> Message-ID: <50D0BBC7.7020202@oracle.com> Hi Sherman, The javadoc lists the interfaces twice, once in the "All Implemented interfaces" section (alphabetically) and again below the
    line; the one below the line is in declaration order. Consistently I would put Temporal first and include the others as needed. Roger On 12/18/2012 1:46 PM, Xueming Shen wrote: > On 12/18/2012 10:28 AM, Stephen Colebourne wrote: >> It changes both. The Javadoc and the source code readers. > > The Temporal and their relatives will still be listed as they declares > now in the current version. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/javadoc/ > > But if you want to list the Temporal explicitly as the first, you will > have > probably to explicitly put it first. > > ZDT now only has Temporal, the rest two have Temporal and WithAdjuster, > kinda inconsistent. You want Temporal only or two? > > While make LD/LT/LDT/ZDT as adjuster is kinda of cool and sometime might > be convenient, but personally I guess they might cause more confusion for > the beginner, than the benefit they might bring in. > > -Sherman > >> I agree with Roger - Temporal first. >> >> Stephen >> >> >> On 18 December 2012 18:28, Xueming Shen wrote: >>> What did you guys mean here? I believe removing the explicit/redundant >>> declaration from the code will not change the javadoc output...you >>> still get >>> all the interfaces listed, the same way. Or guy meant those >>> "developers" >>> that who peek into the source code? >>> >>> -Sherman >>> >>> >>> On 12/18/2012 10:15 AM, Stephen Colebourne wrote: >>>> I guess not. It does mean more developers will look at the Chrono >>>> interface though to see the inheritence, which isn't a good thing. >>>> >>>> Stephen >>>> >>>> >>>> On 18 December 2012 17:49, Xueming Shen >>>> wrote: >>>>> Given their interface hierarchy, it appears there is no reason why >>>>> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >>>>> Accessor explicitly? >>>>> >>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >>>>> >>>>> -Sherman >>>>> >>>>> > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Dec 18 11:12:33 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 11:12:33 -0800 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0BBC7.7020202@oracle.com> References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> <50D0B9F0.3030909@oracle.com> <50D0BBC7.7020202@oracle.com> Message-ID: <50D0C021.3080701@oracle.com> I guess I always "pay attention" to the "all implemented interfaces" section. Anyway, what are the "as needed" now for these 3 classes? TAccessor as well? and WithAdjuster for LDT and LD? ZDT implements Temporal, TemporalAccessor, ChronoZDT, Serialiable LDT implements Temporal, WithAdjuster, TemporalAccessor, ChronoLDT, Serialiable LD implements Temporal, WithAdjuster, TemporalAccessor, ChronoLD, Serialiable -Sherman On 12/18/2012 10:53 AM, Roger Riggs wrote: > Hi Sherman, > > The javadoc lists the interfaces twice, once in the "All Implemented interfaces" section > (alphabetically) and again below the
    line; the one below the line is in declaration order. > > Consistently I would put Temporal first and include the others as needed. > > Roger > > > On 12/18/2012 1:46 PM, Xueming Shen wrote: >> On 12/18/2012 10:28 AM, Stephen Colebourne wrote: >>> It changes both. The Javadoc and the source code readers. >> >> The Temporal and their relatives will still be listed as they declares >> now in the current version. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/javadoc/ >> >> But if you want to list the Temporal explicitly as the first, you will have >> probably to explicitly put it first. >> >> ZDT now only has Temporal, the rest two have Temporal and WithAdjuster, >> kinda inconsistent. You want Temporal only or two? >> >> While make LD/LT/LDT/ZDT as adjuster is kinda of cool and sometime might >> be convenient, but personally I guess they might cause more confusion for >> the beginner, than the benefit they might bring in. >> >> -Sherman >> >>> I agree with Roger - Temporal first. >>> >>> Stephen >>> >>> >>> On 18 December 2012 18:28, Xueming Shen wrote: >>>> What did you guys mean here? I believe removing the explicit/redundant >>>> declaration from the code will not change the javadoc output...you still get >>>> all the interfaces listed, the same way. Or guy meant those "developers" >>>> that who peek into the source code? >>>> >>>> -Sherman >>>> >>>> >>>> On 12/18/2012 10:15 AM, Stephen Colebourne wrote: >>>>> I guess not. It does mean more developers will look at the Chrono >>>>> interface though to see the inheritence, which isn't a good thing. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 18 December 2012 17:49, Xueming Shen wrote: >>>>>> Given their interface hierarchy, it appears there is no reason why >>>>>> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >>>>>> Accessor explicitly? >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >>>>>> >>>>>> -Sherman >>>>>> >>>>>> >> > From yoshito_umaoka at us.ibm.com Tue Dec 18 11:14:02 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 18 Dec 2012 14:14:02 -0500 Subject: [threeten-dev] 64bit tzdata? Message-ID: Hi all, As far as I know, current Java releases use 32bit tzdata (effective between 1901-12-13T20:45:52Z and 2038-01-19T03:14:07Z) and offsets returned by java.util.TimeZone for dates before 1900 does not match the tz database in many cases. Does JSR-310 project introduce 64bit tzdata support? Thanks, Yoshito From Roger.Riggs at oracle.com Tue Dec 18 11:15:01 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 14:15:01 -0500 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0C021.3080701@oracle.com> References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> <50D0B9F0.3030909@oracle.com> <50D0BBC7.7020202@oracle.com> <50D0C021.3080701@oracle.com> Message-ID: <50D0C0B5.9030007@oracle.com> Hi Sherman, TemporalAccessor can be dropped as a duplicate of Temporal. Roger On 12/18/2012 2:12 PM, Xueming Shen wrote: > > I guess I always "pay attention" to the "all implemented interfaces" > section. > > Anyway, what are the "as needed" now for these 3 classes? TAccessor as > well? > and WithAdjuster for LDT and LD? > > ZDT implements Temporal, TemporalAccessor, ChronoZDT, Serialiable > LDT implements Temporal, WithAdjuster, TemporalAccessor, ChronoLDT, > Serialiable > LD implements Temporal, WithAdjuster, TemporalAccessor, ChronoLD, > Serialiable > > -Sherman > > On 12/18/2012 10:53 AM, Roger Riggs wrote: >> Hi Sherman, >> >> The javadoc lists the interfaces twice, once in the "All Implemented >> interfaces" section >> (alphabetically) and again below the
    line; the one below the >> line is in declaration order. >> >> Consistently I would put Temporal first and include the others as >> needed. >> >> Roger >> >> >> On 12/18/2012 1:46 PM, Xueming Shen wrote: >>> On 12/18/2012 10:28 AM, Stephen Colebourne wrote: >>>> It changes both. The Javadoc and the source code readers. >>> >>> The Temporal and their relatives will still be listed as they declares >>> now in the current version. >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/javadoc/ >>> >>> But if you want to list the Temporal explicitly as the first, you >>> will have >>> probably to explicitly put it first. >>> >>> ZDT now only has Temporal, the rest two have Temporal and WithAdjuster, >>> kinda inconsistent. You want Temporal only or two? >>> >>> While make LD/LT/LDT/ZDT as adjuster is kinda of cool and sometime >>> might >>> be convenient, but personally I guess they might cause more >>> confusion for >>> the beginner, than the benefit they might bring in. >>> >>> -Sherman >>> >>>> I agree with Roger - Temporal first. >>>> >>>> Stephen >>>> >>>> >>>> On 18 December 2012 18:28, Xueming Shen >>>> wrote: >>>>> What did you guys mean here? I believe removing the >>>>> explicit/redundant >>>>> declaration from the code will not change the javadoc output...you >>>>> still get >>>>> all the interfaces listed, the same way. Or guy meant those >>>>> "developers" >>>>> that who peek into the source code? >>>>> >>>>> -Sherman >>>>> >>>>> >>>>> On 12/18/2012 10:15 AM, Stephen Colebourne wrote: >>>>>> I guess not. It does mean more developers will look at the Chrono >>>>>> interface though to see the inheritence, which isn't a good thing. >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> On 18 December 2012 17:49, Xueming >>>>>> Shen wrote: >>>>>>> Given their interface hierarchy, it appears there is no reason why >>>>>>> LD, LDT and ZDT still need to declare Temporal, WithAdjuster and >>>>>>> Accessor explicitly? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/if_redundant >>>>>>> >>>>>>> -Sherman >>>>>>> >>>>>>> >>> >> > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Tue Dec 18 11:57:30 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 11:57:30 -0800 Subject: [threeten-dev] 64bit tzdata? In-Reply-To: References: Message-ID: <50D0CAAA.7020509@oracle.com> I think threeten tzdata does not have the limitation that existing jdk does. Though it tries to avoiding the "long" if possible. Code below is used to read in and write out the spoch sec of the date/time of the transition. static void writeEpochSec(long epochSec, DataOutput out) throws IOException { if (epochSec >= -4575744000L && epochSec < 10413792000L && epochSec % 900 == 0) { // quarter hours between 1825 and 2300 int store = (int) ((epochSec + 4575744000L) / 900); out.writeByte((store >>> 16) & 255); out.writeByte((store >>> 8) & 255); out.writeByte(store & 255); } else { out.writeByte(255); out.writeLong(epochSec); } } static long readEpochSec(DataInput in) throws IOException { int hiByte = in.readByte() & 255; if (hiByte == 255) { return in.readLong(); } else { int midByte = in.readByte() & 255; int loByte = in.readByte() & 255; long tot = ((hiByte << 16) + (midByte << 8) + loByte); return (tot * 900) - 4575744000L; } } On 12/18/2012 11:14 AM, yoshito_umaoka at us.ibm.com wrote: > Hi all, > > As far as I know, current Java releases use 32bit tzdata (effective > between 1901-12-13T20:45:52Z and 2038-01-19T03:14:07Z) and offsets > returned by java.util.TimeZone for dates before 1900 does not match the tz > database in many cases. > Does JSR-310 project introduce 64bit tzdata support? > > Thanks, > Yoshito From Roger.Riggs at oracle.com Tue Dec 18 11:54:19 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 14:54:19 -0500 Subject: [threeten-dev] Fixes for #171 and #175 in WeekDefinition Message-ID: <50D0C9EB.1080601@oracle.com> Updates for: #174: WeekDefinition serialization invalid; fixed serialization; #171: Consider adding US constant to WeekDefinition; added WeekDefinition.SUNDAY_START See http://cr.openjdk.java.net/~rriggs/webrev-weekdef/ Comments? -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From misterm at gmail.com Tue Dec 18 12:00:52 2012 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 18 Dec 2012 18:00:52 -0200 Subject: [threeten-dev] Fixes for #171 and #175 in WeekDefinition In-Reply-To: <50D0C9EB.1080601@oracle.com> References: <50D0C9EB.1080601@oracle.com> Message-ID: LGTM. Regards, Michael On Tue, Dec 18, 2012 at 5:54 PM, Roger Riggs wrote: > Updates for: > > #174: WeekDefinition serialization invalid; > fixed serialization; > #171: Consider adding US constant to WeekDefinition; > added WeekDefinition.SUNDAY_START > > See http://cr.openjdk.java.net/~rriggs/webrev-weekdef/ > > Comments? > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From xueming.shen at oracle.com Tue Dec 18 12:02:35 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 18 Dec 2012 20:02:35 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121218200320.4BE924722B@hg.openjdk.java.net> Changeset: eb7dc8321157 Author: sherman Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/eb7dc8321157 Updated the html files to the new package names ! src/share/classes/javax/time/overview.html ! src/share/classes/javax/time/package.html ! src/share/classes/javax/time/temporal/package.html Changeset: f0ef020e68b9 Author: sherman Date: 2012-12-18 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f0ef020e68b9 Listed Temporal interface first in javadoc for classes LDT, LD and ZDT ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/ZonedDateTime.java Changeset: ef2b214182c3 Author: sherman Date: 2012-12-18 12:06 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ef2b214182c3 Merge From yoshito_umaoka at us.ibm.com Tue Dec 18 12:21:23 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 18 Dec 2012 15:21:23 -0500 Subject: [threeten-dev] 64bit tzdata? In-Reply-To: <50D0CAAA.7020509@oracle.com> References: <50D0CAAA.7020509@oracle.com> Message-ID: Xueming, Thank you for checking this. Yes, the code you quoted obviously supports 64bit epoch seconds. I'm still trying to understand the entire picture... JSR-310 TzdbZoneRulesProvider is capable to handle rules described by date falling out of 32bit epoch seconds. Is the provider implementation also consumed by the traditional JDK TimeZone/Calendar classes? In other words, does java.util.TimeZone class no longer use the proprietary tzdata only supporting 32bit seconds transitions on Java 8? I'm worrying about the situation that JSR-310 APIs use the unrestricted rule data while traditional JDK classes still use the proprietary 32bit data. I hope this is not the case. -Yoshito From xueming.shen at oracle.com Tue Dec 18 12:59:20 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 12:59:20 -0800 Subject: [threeten-dev] 64bit tzdata? In-Reply-To: References: <50D0CAAA.7020509@oracle.com> Message-ID: <50D0D928.9090703@oracle.com> On 12/18/2012 12:21 PM, yoshito_umaoka at us.ibm.com wrote: > Xueming, > > Thank you for checking this. Yes, the code you quoted obviously supports 64bit epoch seconds. > I'm still trying to understand the entire picture... > > JSR-310 TzdbZoneRulesProvider is capable to handle rules described by date falling out of 32bit epoch seconds. > Is the provider implementation also consumed by the traditional JDK TimeZone/Calendar classes? > > In other words, does java.util.TimeZone class no longer use the proprietary tzdata only supporting 32bit seconds transitions on Java 8? The plan is to migrate the java.util.TimeZone to use the threeten tzdb date, probably after the M6. We do have a prototype implementation based on early threeten code, it worked fine back then. My concern right now is the possible performance regression if j.u.TimeZone is to be built on top of the ZoneRules (the prototype impl I have now). We probably need to make the final decision based on that. So it's not final. -Sherman > > I'm worrying about the situation that JSR-310 APIs use the unrestricted rule data while traditional JDK classes still use the proprietary 32bit data. I hope this is not the case. > > -Yoshito > From richard.warburton at gmail.com Tue Dec 18 13:43:37 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 18 Dec 2012 21:43:37 +0000 Subject: [threeten-dev] Interface hierarchy In-Reply-To: <50D0C021.3080701@oracle.com> References: <50D0ACB0.9010802@oracle.com> <50D0B5BB.8020604@oracle.com> <50D0B9F0.3030909@oracle.com> <50D0BBC7.7020202@oracle.com> <50D0C021.3080701@oracle.com> Message-ID: Something to bear in mind is that a lot of developers I've seen who setup their IDE to point at the JDK will just 'control click' through to the source code. This is made especially bad since eclipse's "show javadoc when you hover" feature won't show the "all implemented interfaces. If you look at the types in the type hierachy then directly implemented interfaces will be more clearly visible as well. regards, Richard From roger.riggs at oracle.com Tue Dec 18 13:49:09 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 18 Dec 2012 21:49:09 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121218214933.72D3347233@hg.openjdk.java.net> Changeset: 0764bb388375 Author: rriggs Date: 2012-12-18 16:32 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0764bb388375 #39 fix the locale in the LocalizedField Parser tests; the test data is specific to the 'en' locale ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java Changeset: 59d70b36572f Author: rriggs Date: 2012-12-18 16:49 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/59d70b36572f Merge From Roger.Riggs at oracle.com Tue Dec 18 15:10:12 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 18 Dec 2012 18:10:12 -0500 Subject: [threeten-dev] Threeten javadoc with packages renamed Message-ID: <50D0F7D4.5010906@oracle.com> Hi, The package renaming and consolidation of classes is reflected in the Mercurial repository and javadoc. http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ Some individual naming issues are still in discussion. The renaming from javax.time.* to java.time will be done in early January. Please review and comment to the lists, Roger From roger.riggs at oracle.com Tue Dec 18 16:30:11 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 19 Dec 2012 00:30:11 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121219003209.BDA2247243@hg.openjdk.java.net> Changeset: e2fa9b4ef06c Author: rriggs Date: 2012-12-18 14:34 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e2fa9b4ef06c #174: WeekDefinition serialization invalid; fix serialization; #171: Consider adding US constant to WeekDefinition; added WeekDefinition.SUNDAY_START ! src/share/classes/javax/time/temporal/WeekDefinition.java ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java Changeset: 64732bb05439 Author: rriggs Date: 2012-12-18 19:16 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/64732bb05439 minor source cleanup; placement of readResolve and some overly spec language relaxed ! src/share/classes/javax/time/temporal/WeekDefinition.java Changeset: c2c328818492 Author: rriggs Date: 2012-12-18 19:28 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c2c328818492 Merge From dan.chiba at oracle.com Tue Dec 18 16:43:53 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Tue, 18 Dec 2012 16:43:53 -0800 Subject: [threeten-dev] Islamic calendar variants need disambiguation In-Reply-To: References: <50CF9851.2060804@oracle.com> Message-ID: <50D10DC9.9080505@oracle.com> Yoshito-san, Please see my comments below: On 12/18/2012 9:23 AM, yoshito_umaoka at us.ibm.com wrote: > > Yoshito-san, > > > > I would like to get your opinion about identifying Islamic calendar > > variants in CLDR. It defines "islamic" and "islamicc" in calendar.xml > > for the astronomical and algorithmic variants respectively, while > > JSR-310 needs to clearly identify the variants and distinctively > > identify each of them, in order to identify the dates correctly. > > > > For example, the Umm Al-Qura calendar and Microsoft's Islamic calendar > > implementation with the Kuwaiti algorithm are both algorithmic but they > > are different, so the date information is not interchangeable under > > "islamicc" between different variants. A date in one variant may > > correspond to a different date in another variant. So, in terms of > > ensuring correct exchange of Islamic date information, not identifying > > the precise variants in the CLDR name space falls short of the use case > > expectation. In JSR-310, we anticipate Islamic end users might have > > their preferred Islamic calendar variant set in their user profile, or > > an application may be supporting different variants in producing some > > output with Islamic date information. > > > > May I ask if there is a chance to add more Islamic calendar variants or > > enhance the calendar naming scheme to resolve this issue? Or is this > > beyond the scope of CLDR? Do you suggest taking this to the CLDR list? > > I understand the issue. I don't think it's beyond the scope of CLDR. > I think the major question is - how many variants are enough. > > Historically, CLDR project was spawned from ICU project. ICU calendar > implementation is derived from a book - Caledrical Calculations > (Nachum Deshowitz, Edward M. Reingold - ISBN 0-521-56413-1). > In this book, "civil" calendar (arithmetic or tabular) is explained > along with "religious" calendar which is based on astronomical > observation. The "civil" algorithm explained in this book uses leap > year [2,5,7,10,13,16,18,21,24,26,29] that is different from Microsoft's > "Kawait algorithm". > Thank you so much for the clarifications. > I was looking at some web pages. This page > [http://www.staff.science.uu.nl/~gent0113/islam/islam_tabcal.htm > ] > illustrates at least four different arithmetical variations. It also > mentions that there are two possible variations for each intercalary > scheme based on epochs. > The types of variations we are aware of can be summarized as follows: 1. the different rules for tabular/arithmetic/astronomical variants 2. the different epoch used for some of the variants 3. the different deviations due to local sighting > Also, by the nature of "religious" calendar, which may vary depending > on astronomical observation of regional authorities, it is obviously > not suited for identify the dates across different regions. > > Here is what I think - > > - CLDR type "islamic" is used for religious calendar now. Although > actual date may vary, it is probably not worth adding variations. > > - CLDR type "islamicc" is used for arithmetical calendar now. This > type could be separated into multiple different variations. > > I'm wondering if you can create a CLDR ticket with proposed types? > I can add my comment and bring this to a CLDR meeting. Ticket #5525 opened: http://unicode.org/cldr/trac/ticket/5525 At the moment (for JDK8), we are only interested in the Saudi Arabia government's official sighting and Umm Al-Qura calendar only. However, I think it would be adequate to make it possible to add other variants as needed by users or in a future release. Regards, -Dan > > > Thanks, > Yoshito From xueming.shen at oracle.com Tue Dec 18 17:09:32 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 17:09:32 -0800 Subject: [threeten-dev] Threeten javadoc with packages renamed In-Reply-To: <50D0F7D4.5010906@oracle.com> References: <50D0F7D4.5010906@oracle.com> Message-ID: <50D113CC.3090806@oracle.com> I'm a little dizzy when realized that temporal package now has 29 classes/interfaces:-) After went through those classes/interfaces, the first thought is "do we really need that Year class?". The only useful methods of it are probably the Year.isLeap() and Year.length(). While it is convenient to check the leap year in a Year class, compared to find something in ISOChrono, just wonder if any code will really need a type and use it for the year, instead of a pure int. Arguably it maybe like the Integer for the int in j.lang, but given we also don't have a Day and we don't do Hour, Minute, personally I really don't think it is worth a specific date/time type for it (not like month, week), especially we already have too many types here. So should we just get rid of it? -Sherman On 12/18/12 3:10 PM, Roger Riggs wrote: > Hi, > > The package renaming and consolidation of classes is > reflected in the Mercurial repository and javadoc. > > http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ > > Some individual naming issues are still in discussion. > > The renaming from javax.time.* to java.time will be done in early > January. > > Please review and comment to the lists, Roger > From masayoshi.okutsu at oracle.com Tue Dec 18 19:12:36 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 19 Dec 2012 12:12:36 +0900 Subject: [threeten-dev] 64bit tzdata? In-Reply-To: References: Message-ID: <50D130A4.4070600@oracle.com> On 12/19/2012 4:14 AM, yoshito_umaoka at us.ibm.com wrote: > Hi all, > > As far as I know, current Java releases use 32bit tzdata (effective > between 1901-12-13T20:45:52Z and 2038-01-19T03:14:07Z) JDK uses SimpleTimeZone for DST rules with "max" beyond 2038. It doesn't have problems with future dates except for the limitations coming from the SimpleTimeZone API. > and offsets > returned by java.util.TimeZone for dates before 1900 does not match the tz > database in many cases. There were some customer codes which assumed consistent GMT offsets for old dates. In other words, apps assumed the SimpleTimeZone-based time zone support. I didn't want to break those apps back in 2000, which is the reason why JDK didn't introduce support for LMT. Actually I don't know why JDK 1.1 introduced SimpleTimeZone for time zone support when the Olson tzdata was available. The first time I saw the Olson tzdata-based time zone support it was on Ultrix. :-) Masayoshi From xueming.shen at oracle.com Tue Dec 18 20:45:45 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 20:45:45 -0800 Subject: [threeten-dev] SubstringTree Message-ID: <50D14679.9080803@oracle.com> Stephen, I had some doubts about the speed/memory performance of SubstringTree used for id parsing in DateTimeFormatterBuilder. Given the nature of HashMap + String (after the hash hit, you still need to do the char by char comparing for equality, except in the special case that they are the same String object), I doubt the HashMap+subString approach used in SubstringTree can really be "faster" than a normal character by character match. So I wrote a simple version of RadixTree for the prefix-string match http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/RadixTree.java run a non-scientific bench-mark http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/Parse.java to compare the RadixTree approach against the SubstringTree appraoch http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/SubstringTree.java The result suggests that SubstringTree is slower in most cases except if you feed in the zids (which is used to build the tree) directly, in which case it's an identity equal, so no character by character match needed. Even in this case, the "fastness" is marginal (I have not tried to feed in a non-String CharSequence, yet). Worse is the memory usage in the SubstringTree matching, millions of bytes of String objects got created during the run (substring for hashing). I know it's in young-gen, and GC should take well care of them. But if can avoid generate them. I guess this is also one of the reasons it is not as fast as expected. (we happened to have some internal meetings this week regarding the "millions of String objects in heap", 20%+ in some benchmarks. So we are sensitive of Strings these days :-) ) here is a snapshot of the netbeans profile. http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/SubStr.png compared to the RadixTree case http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/Radix.png It appears it might be hard to tune the SubstringTree approach, given the nature of the approach (to utilize hashmap for the substring). I would suggest to replace it with the RadixTree (or any thing better), if tuning is really difficult as I expected. -Sherman From yoshito_umaoka at us.ibm.com Tue Dec 18 20:46:25 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Tue, 18 Dec 2012 23:46:25 -0500 Subject: [threeten-dev] 64bit tzdata? In-Reply-To: <50D130A4.4070600@oracle.com> References: <50D130A4.4070600@oracle.com> Message-ID: Okutsu-san, Thank you for explaining some background. > > As far as I know, current Java releases use 32bit tzdata (effective > > between 1901-12-13T20:45:52Z and 2038-01-19T03:14:07Z) > > JDK uses SimpleTimeZone for DST rules with "max" beyond 2038. It doesn't > have problems with future dates except for the limitations coming from > the SimpleTimeZone API. > > > and offsets Right. I agree that it's not a major concern at this point. > > returned by java.util.TimeZone for dates before 1900 does not match the tz > > database in many cases. > > There were some customer codes which assumed consistent GMT offsets for > old dates. In other words, apps assumed the SimpleTimeZone-based time > zone support. I didn't want to break those apps back in 2000, which is > the reason why JDK didn't introduce support for LMT. I guessed this was the intent. However, it also introduced artificial transition at 1900-01-01T00:00Z (not local time) that is a little bit difficult to understand. Also, I suspect offset before 1900 was hardcoded somewhere and it's not necessarily matches the current GMT raw offset. (For example, Asia/Dili before 1900 returns +8 hours, while the zone uses +9 hours since Sep 2000...) Anyway, I just want to clarify if this hack will be gone with the new JSR-310 implementation. Thanks, Yoshito From xueming.shen at oracle.com Tue Dec 18 20:57:04 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Dec 2012 20:57:04 -0800 Subject: [threeten-dev] [threeten-develop] Threeten javadoc with packages renamed In-Reply-To: References: <50D0F7D4.5010906@oracle.com> Message-ID: <50D14920.5000001@oracle.com> We are still working on the "logistic" process to have a openjdk8+threeten binary for try-out. If you have the environment to build the openjdk8 yourself, here is the jdk8 threeten project repository http://hg.openjdk.java.net/threeten/threeten/jdk You will need a latest jdk8 binary to be the bootjdk. We may consider to push some binaries somewhere for tryout in the near future. I guess Stephen may have an "independent" binary somewhere on his git site for try. -Sherman On 12/18/12 8:16 PM, Andrew Black wrote: > > Excuse my ignorance - is it possible to download a version of 310 with > these changes to try out > > On 18 Dec 2012 23:10, "Roger Riggs" > wrote: > > Hi, > > The package renaming and consolidation of classes is > reflected in the Mercurial repository and javadoc. > > http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ > > > Some individual naming issues are still in discussion. > > The renaming from javax.time.* to java.time will be done in early > January. > > Please review and comment to the lists, Roger > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add > services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From yoshito_umaoka at us.ibm.com Tue Dec 18 21:42:45 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Wed, 19 Dec 2012 00:42:45 -0500 Subject: [threeten-dev] DateTimeFormatters - pattern Z and X and SimpleDateFormat Message-ID: http://cr.openjdk.java.net/~rriggs/threeten-javadoc/javax/time/format/DateTimeFormatters.html In this doc, pattern 'Z' and 'X' are defined as: ---- Z zone-offset offset-Z +0000; -0800; -08:00; X zone-offset 'Z' for zero offset-X Z; -0800; -08:00; Offset X: This formats the offset using 'Z' when the offset is zero. One letter outputs just the hour', such as '+01' Two letters outputs the hour and minute, without a colon, such as '+0130'. Three letters outputs the hour and minute, with a colon, such as '+01:30'. Four letters outputs the hour and minute and optional second, without a colon, such as '+013015'. Five letters outputs the hour and minute and optional second, with a colon, such as '+01:30:15'. Offset Z: This formats the offset using '+0000' or '+00:00' when the offset is zero. One or two letters outputs the hour and minute, without a colon, such as '+0130'. Three letters outputs the hour and minute, with a colon, such as '+01:30'. ---- The doc also mentions that: ---- The pattern string is similar, but not identical, to SimpleDateFormat. Pattern letters 'E' and 'u' are merged, which changes the meaning of "E" and "EE" to be numeric. Pattern letters 'Z' and 'X' are extended. ... ---- I have some comments: - Why don't you add "XXXX" and "XXXXX" example cases? i.e. "Z; -0800; -08:00;" -> "Z; -0800; -08:00;+013015;+01:30:15" - Pattern 'Z' and 'X' are extended. Can we simply extend the definition of SimpleDateFormat to support them? Of course, it will be an incompatible change, but the impact would be pretty minor. - Why don't you introduce optional second support to pattern Z? (By doing so, only the difference between Z and X is formatting offset zero; "+0000" vs "Z"). -Yoshito From yoshito_umaoka at us.ibm.com Tue Dec 18 22:06:23 2012 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Wed, 19 Dec 2012 01:06:23 -0500 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: <50CAA45D.6090000@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> Message-ID: > May I ask the status of the shortest GMT format? When could it be > implemented by vendors? LDML defines "localized GMT offset format" right now. This format is created by following two elements: root.xml +HH:mm;-HH:mm GMT{0} This is pretty similar to offset based time zone ID used by Java. In LDML, this is localizable and used as final fallback of time zone display name. For example, in Finnish (fi.xml) +H.mm;-H.mm UTC{0} The shortest localized GMT format we're currently discussing in CLDR project is based on this format, but shortest possible form. For example, "GMT-05:00" might be shortened to "GMT-5" (no leading zero, no minutes if zero). Also, LDML specification currently does not support non-zero seconds offset. So, we're currently trying to sort out the requirements and add necessary data structure to support them. > As for punctuations, I think comma and dot are already locale > sensitive for number formatting, so it would be easy for people to > understand how the locale sensitive punctuations for date time > formatting work. Because the predefined formatting patterns for > locales have the separators for date and time fields and they are > commonly used, it doesn't seem to be an issue that there is no > locale sensitive pattern letter for them. So I think I am only > interested in the decimal separator for fractional seconds. > Alternatively, if CLDR had predefined locale sensitive patterns with > fractional seconds, that could also be a solution. For instance, a > predefined common pattern to print hour, minute, second and > millisecond for the US locale may look like this: > > HH:mm:ss.SSS dateFormatItem> If forwarded a note to the CLDR development list and got a feedback about 'f'. Stephen pointed out 'f' can be used for min/max decimal digits. However, Mark Davis(google) suggested if JSR-310 can use number format pattern like syntax. For example, HH:mm:ss.SSS### Above pattern indicates minimum 3 /up to 6 decimal digits. Such syntax might be easier to understand and a little bit more flexible (can set maximum digits, not only for 9). I personally agree that above syntax is better than "HH:mm:ss.ffSSS". -Yoshito From xueming.shen at oracle.com Tue Dec 18 22:21:19 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 06:21:19 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 113 new changesets Message-ID: <20121219064228.283544726D@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author: katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags Changeset: 39f9b2cc5738 Author: bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author: bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author: bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author: bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author: lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author: bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author: serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author: serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author: serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author: kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java + test/javax/swing/dnd/7171812/bug7171812.java Changeset: 5600005b87fb Author: serb Date: 2012-11-27 17:03 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5600005b87fb 8002308: [macosx] 7198229 should be applied to the user action only Reviewed-by: anthony, skovatch ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java Changeset: 0e91d6f3019c Author: alexsch Date: 2012-11-29 07:42 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e91d6f3019c 8000423: Diacritic is not applyed to a base letter on Linux Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: abee1d528df1 Author: kshefov Date: 2012-11-30 12:39 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/abee1d528df1 7124242: [macosx] Test doesn't work because of the frame round corners in the LaF Reviewed-by: anthony, yan, alexsch ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 35d8085aa14a Author: lana Date: 2012-11-30 17:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/35d8085aa14a Merge Changeset: da55ef766e48 Author: alexsch Date: 2012-12-04 15:26 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/da55ef766e48 6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Reviewed-by: serb ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: bd175c70684c Author: alexsch Date: 2012-12-04 15:56 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd175c70684c 8003830: NPE at BasicTreeUI$Actions.page:4470 Reviewed-by: serb, alexsch Contributed-by: Jaroslav Tulach ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003830/bug8003830.java Changeset: 009fd6e1d9f5 Author: alexsch Date: 2012-12-04 16:42 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/009fd6e1d9f5 8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F Reviewed-by: serb ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java Changeset: 4aad3e6f68d2 Author: jviswana Date: 2012-12-04 17:17 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4aad3e6f68d2 4631925: JColor Chooser is not fully accessible Reviewed-by: alexsch ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java Changeset: ea20c9388d90 Author: aph Date: 2012-12-04 14:02 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea20c9388d90 8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c Summary: Code does not check for JNU_GetEnv returning NULL. Reviewed-by: anthony ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: bbbb5c70aa59 Author: lana Date: 2012-12-04 11:41 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bbbb5c70aa59 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d7ed56d57d97 Merge Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntSupplier.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/262b3b2f3aa3 Merge Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ba5eabd6a37b Merge Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java Changeset: e66ec5b8c15e Author: lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e66ec5b8c15e Merge Changeset: fd8ba2d8baec Author: sherman Date: 2012-12-01 11:36 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fd8ba2d8baec 8004212: java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Summary: to return the length instead of position Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: f657adf4fe78 Author: alanb Date: 2012-12-02 16:37 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f657adf4fe78 8003846: Override mechanism for currency data should not require creating currency.properties in java.home Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh Changeset: 60550cd2b527 Author: dholmes Date: 2012-12-02 19:16 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/60550cd2b527 7200297: agent code does not handle multiple boot library path elements correctly Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs. Reviewed-by: dholmes, sspitsyn, dsamersoff Contributed-by: Bill Pittore ! src/share/back/debugInit.c ! src/share/back/error_messages.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/npt/npt_md.h ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/npt/npt_md.h Changeset: a42da685dfca Author: weijun Date: 2012-12-03 17:14 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a42da685dfca 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: ead651efb271 Author: xuelei Date: 2012-12-03 06:00 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ead651efb271 8004184: security tests leave JSSEServer running Summary: Use othervm mode to release resources, and correct the system properties issues in JSSE Reviewed-by: chegar ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: ee9846f351d7 Author: mullan Date: 2012-12-03 11:07 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ee9846f351d7 7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout Summary: Added com.sun.security.ocsp.timeout system property to control timeout Reviewed-by: mullan, vinnie Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 38ec2838dd86 Author: dxu Date: 2012-12-04 14:07 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/38ec2838dd86 7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 7144997: (fs) Files.probeContentType returns null on Solaris 64-bit Reviewed-by: alanb, mduigou ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java + src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c Changeset: 2e8863c4f7d0 Author: kmo Date: 2012-12-04 15:10 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2e8863c4f7d0 8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Reviewed-by: twisti, alanb, dholmes ! test/java/lang/Math/DivModTests.java Changeset: 87028eb3f020 Author: lana Date: 2012-12-04 11:46 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/87028eb3f020 Merge Changeset: b68a5404de60 Author: lana Date: 2012-12-10 20:58 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b68a5404de60 Merge ! makefiles/CompileJavaClasses.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 379e3dfa521d Author: erikj Date: 2012-12-06 12:09 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/379e3dfa521d 8004104: build-infra: Minor cleanup Reviewed-by: ohrstrom, tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 2689f6cfe835 Author: erikj Date: 2012-12-11 12:27 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2689f6cfe835 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Changing boolean values of ENABLE_DEBUG_SYMBOLS. Reviewed-by: dholmes, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 53fb43e4d614 Author: katleman Date: 2012-12-12 13:21 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/53fb43e4d614 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 7fd56a5abd94 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7fd56a5abd94 Added tag jdk8-b68 for changeset 53fb43e4d614 ! .hgtags Changeset: e8b54ae97344 Author: jviswana Date: 2012-12-12 13:28 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e8b54ae97344 8004316: Printer - tempfile having incorrect extension Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: fd9e6b4c8488 Author: lana Date: 2012-12-14 11:21 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fd9e6b4c8488 Merge Changeset: c69424f78060 Author: serb Date: 2012-12-11 19:45 +0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c69424f78060 7154778: [macosx] NSView-based implementation of sun.awt.EmbeddedFrame Summary: The new implementation of EmbeddedFrame to support SWT_AWT Bridge Reviewed-by: anthony, serb, leonidr Contributed-by: Petr Pchelko ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java + src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e016ad35a764 Author: kshefov Date: 2012-12-13 15:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e016ad35a764 7132385: [macosx] IconifyTest of RepaintManager could use some delay Reviewed-by: serb, alexsch + test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java Changeset: 71e03e17c183 Author: kshefov Date: 2012-12-14 13:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/71e03e17c183 6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction Reviewed-by: serb, alexsch + test/javax/swing/JInternalFrame/5066752/bug5066752.java Changeset: 9fc7460ca3ac Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9fc7460ca3ac Merge Changeset: 7004848974a2 Author: jgish Date: 2012-12-04 20:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7004848974a2 8003596: TEST_BUG: java/util/logging/CheckLockLocationTest.java failing [win] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/logging/CheckLockLocationTest.java Changeset: 44ae777564eb Author: mullan Date: 2012-12-04 17:40 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/44ae777564eb 8004188: Rename src/share/lib/security/java.security to java.security-linux Reviewed-by: mullan, mchung Contributed-by: jason.uh at oracle.com ! make/java/security/Makefile - src/share/lib/security/java.security + src/share/lib/security/java.security-linux Changeset: b54a5b7d2e65 Author: alanb Date: 2012-12-05 12:20 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b54a5b7d2e65 8004491: Build breakage on Linux due to 8004188 Reviewed-by: chegar, erikj ! makefiles/CopyFiles.gmk Changeset: a971516029ab Author: jgish Date: 2012-12-05 21:08 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a971516029ab 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported Reviewed-by: alanb, dmocek, smarks ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 41a1b110f34d Author: lancea Date: 2012-12-06 15:51 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/41a1b110f34d 8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException Reviewed-by: naoto ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java Changeset: 896d4af2ebfd Author: rfield Date: 2012-12-06 21:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/896d4af2ebfd 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Summary: Lambda implementing inner classes now has private constructor (thanks Kumar) Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: da387f0cecb7 Author: ksrini Date: 2012-12-09 07:43 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/da387f0cecb7 8004042: Arrrghs.java test failed on windows with access error. Reviewed-by: smarks, jjh, ksrini Contributed-by: david.dehaven at oracle.com ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: 343615aa0539 Author: dxu Date: 2012-12-09 19:13 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/343615aa0539 7194370: (fs) WatchService fails if volume S/N is 0 [win] Reviewed-by: alanb, forax ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java Changeset: fda257689786 Author: okutsu Date: 2012-12-10 10:52 +0900 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fda257689786 8000983: Support narrow display names for calendar fields 8003267: Support generic time zone names in TimeZoneNameProvider (SPI) Reviewed-by: naoto ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/BundleGenerator.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/java/util/spi/TimeZoneNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.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/locale/provider/SPILocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/Calendar/GenericTimeZoneNamesTest.java + test/java/util/Calendar/GenericTimeZoneNamesTest.sh + test/java/util/Calendar/NarrowNamesTest.java + test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: fda2b2b5b98b Author: michaelm Date: 2012-12-10 14:56 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fda2b2b5b98b 8003948: NTLM/Negotiate authentication problem Reviewed-by: chegar, weijun ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/MessageHeaderTest.java Changeset: cac1bfaceaaa Author: mchung Date: 2012-12-10 15:15 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cac1bfaceaaa 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html Summary: Simple capitalization typo in LogManager() description Reviewed-by: darcy, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 883feced1cdd Author: dingxmin Date: 2012-12-11 10:42 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/883feced1cdd 6512101: Incorrect encoding in NetworkInterface.getDisplayName() Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface.c Changeset: d206e52bf8a6 Author: weijun Date: 2012-12-11 13:14 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d206e52bf8a6 8004488: wrong permissions checked in krb5 Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + test/sun/security/krb5/auto/KeyPermissions.java ! test/sun/security/krb5/auto/KeyTabCompat.java Changeset: c4bd81de2868 Author: akhil Date: 2012-12-11 15:33 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c4bd81de2868 8003246: Add InitialValue Supplier to ThreadLocal Reviewed-by: mduigou, forax, dl, chegar, briangoetz ! src/share/classes/java/lang/ThreadLocal.java + test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 6c795437f212 Author: mduigou Date: 2012-12-11 20:49 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6c795437f212 8004905: Correct license of test to remove classpath exception Reviewed-by: akhil ! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 12fba0974a9d Author: weijun Date: 2012-12-12 18:39 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/12fba0974a9d 8004904: Makefile for ntlm Reviewed-by: erikj, chegar ! make/com/sun/security/Makefile + make/com/sun/security/ntlm/Makefile Changeset: 806cf26e5063 Author: chegar Date: 2012-12-12 11:35 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/806cf26e5063 8004921: Trivial javadoc warnings in Base64 Reviewed-by: darcy ! src/share/classes/java/util/Base64.java Changeset: 81640e75c7a7 Author: alanb Date: 2012-12-12 13:03 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/81640e75c7a7 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener Reviewed-by: ksrini, mchung, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/logging/LogManager.java Changeset: 346c0af4af41 Author: mullan Date: 2012-12-12 09:25 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/346c0af4af41 8004064: Downgrade normative references to ${java.home}/lib/security/java.security Reviewed-by: alanb, vinnie, xuelei ! src/share/classes/com/sun/net/ssl/KeyManagerFactory.java ! src/share/classes/com/sun/net/ssl/TrustManagerFactory.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: c7f86908d5fd Author: mullan Date: 2012-12-12 09:27 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c7f86908d5fd Merge - src/share/lib/security/java.security Changeset: 68374c6e65c1 Author: robm Date: 2012-12-12 15:57 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile Changeset: bd84d0927a2e Author: smarks Date: 2012-12-12 09:53 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd84d0927a2e 8004748: clean up @build tags in RMI tests Reviewed-by: alanb, darcy, mchung ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/benchmark/runRmiBench.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java + test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java Changeset: 56fd5479a98f Author: jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instead of test failure Reviewed-by: mduigou, smarks ! test/java/util/logging/CheckLockLocationTest.java Changeset: 5a2ab2c3f106 Author: weijun Date: 2012-12-13 08:11 +0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5a2ab2c3f106 8004235: Disable native JGSS provider on Mac Reviewed-by: erikj, valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 7a8978a5bb6e Author: lancea Date: 2012-12-12 20:57 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7a8978a5bb6e 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety Reviewed-by: naoto ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 775b0050144a Author: chegar Date: 2012-12-13 09:55 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/775b0050144a 8004925: java/net/Socks/SocksV4Test.java failing on all platforms Reviewed-by: alanb, dsamersoff ! test/java/net/Socks/SocksV4Test.java Changeset: 682d2d3ccff5 Author: chegar Date: 2012-12-13 14:33 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/682d2d3ccff5 8004675: Inet6Address.getHostAddress should use string scope identifier where available Summary: ...and some minor stylistic cleanup Reviewed-by: khazra, dsamersoff, michaelm ! src/share/classes/java/net/Inet6Address.java ! src/share/native/java/net/Inet6Address.c + test/java/net/Inet6Address/StringScope.java Changeset: c97618a3c8c2 Author: juh Date: 2012-12-13 09:35 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c97618a3c8c2 7193792: sun/security/pkcs11/ec/TestECDSA.java failing intermittently Reviewed-by: vinnie, wetmore ! test/ProblemList.txt ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 7b697da6626a Author: mullan Date: 2012-12-13 09:37 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7b697da6626a Merge Changeset: ae5d04dbacd6 Author: chegar Date: 2012-12-13 14:47 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ae5d04dbacd6 8003890: corelibs test scripts should pass TESTVMOPTS Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! test/com/oracle/net/sanity.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/GetXSpace.sh ! test/java/io/File/MacPathTest.sh ! test/java/io/File/basic.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Runtime/exec/setcwd.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/ptr/lookup.sh ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/charset/Charset/default.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh ! test/java/nio/file/Path/MacPathTest.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/ZipFile/deletetempjar.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/print/applet/AppletPrintLookup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/net/InetAddress/nameservice/dns/cname.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/getcontenttype.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/SignUsingNONEwithRSA.sh ! test/sun/security/mscapi/SignUsingSHA2withRSA.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/MultipleJRE.sh Changeset: 087425441a48 Author: robm Date: 2012-12-13 15:28 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/087425441a48 8000525: Java.net.httpcookie api does not support 2-digit year format Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/CookieHandler/CookieManagerTest.java + test/java/net/HttpCookie/ExpiredCookieTest.java Changeset: 8d7323a9d8ed Author: dholmes Date: 2012-12-13 21:18 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d7323a9d8ed 8003632: HPROF class file version java.lang.RuntimeException errors Reviewed-by: mchung, lancea ! src/share/javavm/export/classfile_constants.h Changeset: de6b54a60d60 Author: lana Date: 2012-12-14 13:14 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/de6b54a60d60 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: d08d6409219e Author: sherman Date: 2012-12-18 22:03 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d08d6409219e Merge ! make/docs/CORE_PKGS.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java From xueming.shen at oracle.com Tue Dec 18 23:57:45 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 07:57:45 +0000 Subject: [threeten-dev] hg: threeten/threeten/corba: 2 new changesets Message-ID: <20121219075748.7849347271@hg.openjdk.java.net> Changeset: 82000531feaa Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags Changeset: 22ddcac208a8 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/corba/rev/22ddcac208a8 Added tag jdk8-b68 for changeset 82000531feaa ! .hgtags From xueming.shen at oracle.com Wed Dec 19 00:01:17 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 08:01:17 +0000 Subject: [threeten-dev] hg: threeten/threeten/hotspot: 48 new changesets Message-ID: <20121219080259.E37A347272@hg.openjdk.java.net> Changeset: e1d42ba865de Author: amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49cbd3e25ba9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author: coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author: mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author: dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author: mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author: zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author: hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author: coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author: coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 53715fb1597d Author: brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author: coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this->qualifications. Reviewed-by: coleenp, dholmes Contributed-by: duboscq at ssw.jku.at ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: d0aa87f04bd5 Author: stefank Date: 2012-11-27 10:13 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/d0aa87f04bd5 8003720: NPG: Method in interpreter stack frame can be deallocated Summary: Pass down a closure during root scanning to keep the class of the method alive. Reviewed-by: coleenp, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp + test/runtime/8003720/Asmator.java + test/runtime/8003720/Test8003720.java + test/runtime/8003720/Victim.java + test/runtime/8003720/VictimClassLoader.java Changeset: f34d701e952e Author: stefank Date: 2012-11-27 14:20 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f34d701e952e 8003935: Simplify the needed includes for using Thread::current() Reviewed-by: dholmes, rbackman, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/os/bsd/vm/mutex_bsd.cpp ! src/os/bsd/vm/mutex_bsd.inline.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/threadCritical_bsd.cpp ! src/os/bsd/vm/thread_bsd.inline.hpp ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp + src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 2fc0334f613a Author: johnc Date: 2012-11-27 14:11 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2fc0334f613a 7194633: G1: Assertion and guarantee failures in block offset table Summary: Add detailed error messages to assertions and guarantees in G1's block offset table. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/memory/space.cpp Changeset: c24f778e9401 Author: johnc Date: 2012-11-29 11:23 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/c24f778e9401 Merge ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b2dbd323c668 Author: jiangli Date: 2012-11-27 17:03 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b2dbd323c668 8003848: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Summary: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Reviewed-by: bdelsart, sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5505fbbae3d3 Author: cjplummer Date: 2012-11-29 13:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5505fbbae3d3 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 90273fc0a981 Author: coleenp Date: 2012-11-29 16:50 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/90273fc0a981 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Reviewed-by: twisti, jrose, stefank ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/prims/unsafe.cpp Changeset: dad48145e775 Author: stefank Date: 2012-11-29 23:02 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/dad48145e775 8004199: Change the ASM package for Test8003720 Reviewed-by: kvn, jrose ! test/runtime/8003720/Asmator.java ! test/runtime/8003720/Test8003720.java Changeset: 5fafdef522c6 Author: johnc Date: 2012-11-30 12:01 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5fafdef522c6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: b61d9c88b759 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b61d9c88b759 Merge Changeset: 25bdce771bb3 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/25bdce771bb3 Added tag hs25-b11 for changeset b61d9c88b759 ! .hgtags Changeset: 10587a580c51 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/10587a580c51 Added tag jdk8-b67 for changeset 25bdce771bb3 ! .hgtags Changeset: 816b7e5bf2ed Author: amurillo Date: 2012-11-30 17:00 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/816b7e5bf2ed 8004248: new hotspot build - hs25-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7cc69864a29b Author: kvn Date: 2012-11-16 15:49 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/7cc69864a29b 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Summary: Increase the stack size in the run parameters. Reviewed-by: kvn Contributed-by: david.r.chase at oracle.com ! test/compiler/6865265/StackOverflowBug.java Changeset: ee32440febeb Author: vlivanov Date: 2012-11-21 05:57 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ee32440febeb 8001538: hs_err file does not list anymore compiled methods in compilation events Summary: Fixed message buffer size calculation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/utilities/events.hpp Changeset: beebba0acc11 Author: twisti Date: 2012-11-26 17:25 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/beebba0acc11 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.hpp Changeset: 2cd5e15048e6 Author: twisti Date: 2012-11-27 12:48 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2cd5e15048e6 8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/shark_globals.hpp Changeset: 2aff40cb4703 Author: bharadwaj Date: 2012-11-27 17:24 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2aff40cb4703 7092905: C2: Keep track of the number of dead nodes Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes. Reviewed-by: kvn, twisti, jrose, vlivanov ! src/share/tools/LogCompilation/README ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 1acccb7c0b01 Author: kvn Date: 2012-11-27 17:41 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1acccb7c0b01 8003850: add support for constants in stub code Summary: remember the code section and switch back to the proper one when adding constants. Reviewed-by: twisti, kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp Changeset: 6ab62ad83507 Author: twisti Date: 2012-11-30 11:44 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/6ab62ad83507 8003195: AbstractAssembler should not store code pointers but use the CodeSection directly Reviewed-by: twisti, kvn Contributed-by: Bharadwaj Yadavalli ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.hpp Changeset: cd3d6a6b95d9 Author: twisti Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/cd3d6a6b95d9 8003240: x86: move MacroAssembler into separate file Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp + src/cpu/x86/vm/macroAssembler_x86.cpp + src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/metaspaceShared_x86_32.cpp ! src/cpu/x86/vm/metaspaceShared_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp + src/share/vm/asm/macroAssembler.hpp + src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp + src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: dd38cfd12c3a Author: twisti Date: 2012-12-03 15:48 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/dd38cfd12c3a 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: kvn, johnc ! src/share/vm/opto/library_call.cpp Changeset: c5d414e98fd4 Author: neliasso Date: 2012-11-26 15:11 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/c5d414e98fd4 8003983: LogCompilation tool is broken since c1 support Summary: Fixed emitting and parsing Reviewed-by: jrose, kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: b7ff5879152e Author: neliasso Date: 2012-12-06 09:50 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b7ff5879152e 8003934: Fix generation of malformed options to Projectcreator Summary: Makefile produces unmatched quotes due to nmake bug Reviewed-by: jwilhelm, brutisso ! make/windows/projectfiles/common/Makefile Changeset: 228a94f37a67 Author: neliasso Date: 2012-12-06 14:33 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/228a94f37a67 Merge Changeset: f0c2369fda5a Author: twisti Date: 2012-12-06 09:57 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f0c2369fda5a 8003250: SPARC: move MacroAssembler into separate file Reviewed-by: jrose, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.hpp + src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/metaspaceShared_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/vmreg.hpp Changeset: 522662fa9c16 Author: twisti Date: 2012-12-06 11:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/522662fa9c16 Merge Changeset: d2f8c38e543d Author: roland Date: 2012-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/d2f8c38e543d Merge ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0f80645e9c26 Author: johnc Date: 2012-11-30 11:46 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/0f80645e9c26 8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8 Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor. Reviewed-by: jwilhelm, azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/timer.cpp Changeset: eade6b2e4782 Author: jmasa Date: 2012-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/eade6b2e4782 8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp Reviewed-by: coleenp + src/share/vm/memory/metablock.cpp + src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metaspace.cpp Changeset: cbe736bc70fa Author: jwilhelm Date: 2012-12-07 07:36 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/cbe736bc70fa Merge Changeset: a35a72dd2e12 Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a35a72dd2e12 Merge Changeset: 121aa71316af Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/121aa71316af Added tag hs25-b12 for changeset a35a72dd2e12 ! .hgtags Changeset: 8af7d22f1f8f Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/8af7d22f1f8f Added tag jdk8-b68 for changeset 121aa71316af ! .hgtags From xueming.shen at oracle.com Wed Dec 19 00:10:03 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 08:10:03 +0000 Subject: [threeten-dev] hg: threeten/threeten/langtools: 20 new changesets Message-ID: <20121219081054.C943947273@hg.openjdk.java.net> Changeset: e9a13a6c9d5d Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: 98e14fc9ee11 Author: lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/98e14fc9ee11 Merge Changeset: 0e70eb71fec0 Author: mcimadamore Date: 2012-12-04 17:19 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/0e70eb71fec0 8004360: regression test DefaultMethodRegressionTests fails in langtools Summary: ignore broken failing test Reviewed-by: jjg - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java + test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 014a6a11dfe5 Author: lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags Changeset: c78acf6c2f3e Author: mcimadamore Date: 2012-12-10 12:10 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/c78acf6c2f3e 8004094: Javac compiler error - synthetic method accessor generated with duplicate name Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/8004094/B.java + test/tools/javac/generics/8004094/T8004094.java Changeset: fcf89720ae71 Author: vromero Date: 2012-12-10 16:21 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/fcf89720ae71 8003967: detect and remove all mutable implicit static enum fields in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/tools/StandardLocation.java + test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: cfde9737131e Author: jjg Date: 2012-12-11 15:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/cfde9737131e 8004828: refactor init of *DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: 170e486632d9 Author: jlahoda Date: 2012-12-12 20:26 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or null if none. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java + test/tools/javac/util/list/ListBufferTest.java Changeset: 376d6c1b49e5 Author: jfranck Date: 2012-12-03 11:16 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/376d6c1b49e5 8001114: Container annotation is not checked for semantic correctness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java Changeset: d7360bf35ee1 Author: lana Date: 2012-12-14 13:15 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d7360bf35ee1 Merge From xueming.shen at oracle.com Wed Dec 19 00:11:45 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 08:11:45 +0000 Subject: [threeten-dev] hg: threeten/threeten/jaxp: 2 new changesets Message-ID: <20121219081154.9D93547274@hg.openjdk.java.net> Changeset: b854e7008421 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/b854e7008421 Added tag jdk8-b67 for changeset 83df3493ca3c ! .hgtags Changeset: 789a855de959 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/789a855de959 Added tag jdk8-b68 for changeset b854e7008421 ! .hgtags From xueming.shen at oracle.com Wed Dec 19 00:12:31 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 19 Dec 2012 08:12:31 +0000 Subject: [threeten-dev] hg: threeten/threeten/jaxws: 2 new changesets Message-ID: <20121219081238.87D2947275@hg.openjdk.java.net> Changeset: d3fe408f3a9a Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags Changeset: 756323c99011 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/756323c99011 Added tag jdk8-b68 for changeset d3fe408f3a9a ! .hgtags From scolebourne at joda.org Wed Dec 19 02:46:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Dec 2012 10:46:38 +0000 Subject: [threeten-dev] SubstringTree In-Reply-To: <50D14679.9080803@oracle.com> References: <50D14679.9080803@oracle.com> Message-ID: I'm very happy for you to replace SubstringTree with anything that goes faster or has a smaller footprint. Push away! Stephen On 19 December 2012 04:45, Xueming Shen wrote: > Stephen, > > I had some doubts about the speed/memory performance of SubstringTree used > for > id parsing in DateTimeFormatterBuilder. Given the nature of HashMap + String > (after > the hash hit, you still need to do the char by char comparing for equality, > except in > the special case that they are the same String object), I doubt the > HashMap+subString > approach used in SubstringTree can really be "faster" than a normal > character by > character match. > > So I wrote a simple version of RadixTree for the prefix-string match > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/RadixTree.java > > run a non-scientific bench-mark > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/Parse.java > > to compare the RadixTree approach against the SubstringTree appraoch > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/SubstringTree.java > > The result suggests that SubstringTree is slower in most cases except if you > feed in the zids (which is used to build the tree) directly, in which case > it's an > identity equal, so no character by character match needed. Even in this > case, > the "fastness" is marginal (I have not tried to feed in a non-String > CharSequence, > yet). > > Worse is the memory usage in the SubstringTree matching, millions of bytes > of String objects got created during the run (substring for hashing). I know > it's > in young-gen, and GC should take well care of them. But if can avoid > generate > them. I guess this is also one of the reasons it is not as fast as expected. > (we happened to have some internal meetings this week regarding the > "millions > of String objects in heap", 20%+ in some benchmarks. So we are sensitive of > Strings these days :-) ) > > here is a snapshot of the netbeans profile. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/SubStr.png > > compared to the RadixTree case > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree/Radix.png > > It appears it might be hard to tune the SubstringTree approach, given the > nature of the approach (to utilize hashmap for the substring). > > I would suggest to replace it with the RadixTree (or any thing better), if > tuning > is really difficult as I expected. > > -Sherman > > From scolebourne at joda.org Wed Dec 19 02:49:54 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Dec 2012 10:49:54 +0000 Subject: [threeten-dev] [threeten-develop] Threeten javadoc with packages renamed In-Reply-To: <50D14920.5000001@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D14920.5000001@oracle.com> Message-ID: The JDK7 version in GitHub has most of the same code, but not the latest renames. At some stage the renames will be backported. Stephen On 19 December 2012 04:57, Xueming Shen wrote: > We are still working on the "logistic" process to have a openjdk8+threeten > binary > for try-out. If you have the environment to build the openjdk8 yourself, > here is the > jdk8 threeten project repository > > http://hg.openjdk.java.net/threeten/threeten/jdk > > You will need a latest jdk8 binary to be the bootjdk. > > We may consider to push some binaries somewhere for tryout in the near > future. > > I guess Stephen may have an "independent" binary somewhere on his git site > for > try. > > -Sherman > > On 12/18/12 8:16 PM, Andrew Black wrote: > > Excuse my ignorance - is it possible to download a version of 310 with these > changes to try out > > On 18 Dec 2012 23:10, "Roger Riggs" wrote: >> >> Hi, >> >> The package renaming and consolidation of classes is >> reflected in the Mercurial repository and javadoc. >> >> http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ >> >> Some individual naming issues are still in discussion. >> >> The renaming from javax.time.* to java.time will be done in early January. >> >> Please review and comment to the lists, Roger >> >> >> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > From scolebourne at joda.org Wed Dec 19 02:52:15 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Dec 2012 10:52:15 +0000 Subject: [threeten-dev] [threeten-develop] Threeten javadoc with packages renamed In-Reply-To: <50D113CC.3090806@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> Message-ID: Large packages seems to be a JDK thing. The decision we seem to have taken is to keep the top package small so newcomers are not overwhelmed. The trade off is that this package is larger. Picking on one of the 29 items doesn't really change the size of the package. The classes/interfaces we do have seem to me to be a good set of things that we've been working towards for 5 years. Stephen On 19 December 2012 01:09, Xueming Shen wrote: > I'm a little dizzy when realized that temporal package now has 29 > classes/interfaces:-) > After went through those classes/interfaces, the first thought is "do we > really need that > Year class?". The only useful methods of it are probably the > Year.isLeap() and Year.length(). > While it is convenient to check the leap year in a Year class, compared > to find something > in ISOChrono, just wonder if any code will really need a type and use it > for the year, instead > of a pure int. Arguably it maybe like the Integer for the int in j.lang, > but given we also don't > have a Day and we don't do Hour, Minute, personally I really don't think > it is worth a specific > date/time type for it (not like month, week), especially we already have > too many types > here. So should we just get rid of it? > > -Sherman > > On 12/18/12 3:10 PM, Roger Riggs wrote: >> Hi, >> >> The package renaming and consolidation of classes is >> reflected in the Mercurial repository and javadoc. >> >> http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ >> >> Some individual naming issues are still in discussion. >> >> The renaming from javax.time.* to java.time will be done in early >> January. >> >> Please review and comment to the lists, Roger >> > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Wed Dec 19 06:47:20 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 19 Dec 2012 14:47:20 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20121219144842.1863447283@hg.openjdk.java.net> Changeset: 9d03ff0395a8 Author: scolebourne Date: 2012-12-19 12:03 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9d03ff0395a8 Use constant on Year class, now Year is fully integrated into core ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/temporal/ChronoField.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! src/share/classes/javax/time/zone/StandardZoneRules.java ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/zone/TCKZoneOffsetTransition.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime_instants.java ! test/javax/time/test/javax/time/zone/TestStandardZoneRules.java Changeset: b19c95137197 Author: scolebourne Date: 2012-12-19 13:52 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b19c95137197 Use method reference for querying parse result ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/temporal/DateTimeBuilder.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java Changeset: 835613a76bf0 Author: scolebourne Date: 2012-12-19 14:26 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/835613a76bf0 Clearer Temporal Javadoc ! src/share/classes/javax/time/temporal/Temporal.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java Changeset: df77c39fadca Author: scolebourne Date: 2012-12-19 14:26 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/df77c39fadca Better error messages in from(TemporalAccessor) ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java From scolebourne at joda.org Wed Dec 19 06:51:01 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 19 Dec 2012 14:51:01 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Simplify error message while method references have no toString() Message-ID: <20121219145142.D054547284@hg.openjdk.java.net> Changeset: 7257d27ad996 Author: scolebourne Date: 2012-12-19 14:50 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7257d27ad996 Simplify error message while method references have no toString() ! src/share/classes/javax/time/format/DateTimeFormatter.java From scolebourne at joda.org Wed Dec 19 07:37:12 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 19 Dec 2012 15:37:12 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121219153746.7EC944728A@hg.openjdk.java.net> Changeset: 4e3ae517cb62 Author: scolebourne Date: 2012-12-19 14:58 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4e3ae517cb62 Move DateTimeBuidler to format package Organize imports ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/Ser.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneRegion.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/JapaneseEra.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/MinguoDate.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistDate.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java + src/share/classes/javax/time/format/DateTimeBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! src/share/classes/javax/time/format/DateTimeTextProvider.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ChronoField.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java - src/share/classes/javax/time/temporal/DateTimeBuilder.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOFields.java ! src/share/classes/javax/time/temporal/JulianDayField.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/TemporalField.java ! src/share/classes/javax/time/temporal/WeekDefinition.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java ! test/javax/time/tck/javax/time/temporal/TCKISOFields.java ! test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/format/TestCharLiteralParser.java ! test/javax/time/test/javax/time/format/TestFractionPrinterParser.java ! test/javax/time/test/javax/time/format/TestNumberParser.java ! test/javax/time/test/javax/time/format/TestPadParserDecorator.java ! test/javax/time/test/javax/time/format/TestReducedParser.java ! test/javax/time/test/javax/time/format/TestStringLiteralParser.java ! test/javax/time/test/javax/time/format/TestTextParser.java ! test/javax/time/test/javax/time/format/TestZoneIdParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetParser.java ! test/javax/time/test/javax/time/format/TestZoneOffsetPrinter.java ! test/javax/time/test/javax/time/temporal/MockFieldNoValue.java ! test/javax/time/test/javax/time/temporal/TestDateTimeBuilderCombinations.java Changeset: ef953402ce7b Author: scolebourne Date: 2012-12-19 15:36 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ef953402ce7b Fix Javadoc ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatters.java From scolebourne at joda.org Wed Dec 19 08:43:51 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 19 Dec 2012 16:43:51 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121219164424.E953A4728C@hg.openjdk.java.net> Changeset: 55f6be8206af Author: scolebourne Date: 2012-12-19 16:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/55f6be8206af Check for null to ensure NPE rather than DateTimeException ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java Changeset: 65d919216b5d Author: scolebourne Date: 2012-12-19 16:43 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/65d919216b5d Ensure that periodUntil uses instants for times and locals for dates Fixes #160 ! src/share/classes/javax/time/ZonedDateTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java From scolebourne at joda.org Wed Dec 19 13:37:39 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 19 Dec 2012 21:37:39 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121219213827.8AB1147299@hg.openjdk.java.net> Changeset: 1d97b90e0540 Author: scolebourne Date: 2012-12-18 23:35 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1d97b90e0540 Javadoc fixes ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java Changeset: c4e05940801f Author: scolebourne Date: 2012-12-19 21:36 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c4e05940801f Merge ! src/share/classes/javax/time/LocalTime.java - src/share/classes/javax/time/temporal/DateTimeBuilder.java - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java From dan.chiba at oracle.com Wed Dec 19 15:14:32 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Wed, 19 Dec 2012 15:14:32 -0800 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> Message-ID: <50D24A58.4030303@oracle.com> Hi Yoshito-san, I think JSR-310 could look at the shortest GMT format when the CLDR requirements are sorted out and its spec becomes available. At this point, best we can do is to agree on the intent to revisit once the CLDR spec is ready for implementation in the future. It would be adequate to document the chance of enhancements to follow CLDR updates. For fractional seconds, I think JSR-310 should use the number formatting conventions if CLDR updates the syntax to incorporate them. Imho conformance is far more important than whether we use 'f' or number format syntax. Hi Stephen, Would you agree to do "HH:mm:ss.SSS###" for printing 3 to 6 fractional digits, like number formatting? Regards, -Dan On 12/18/2012 10:06 PM, yoshito_umaoka at us.ibm.com wrote: > > May I ask the status of the shortest GMT format? When could it be > > implemented by vendors? > > LDML defines "localized GMT offset format" right now. > This format is created by following two elements: > > root.xml > > +HH:mm;-HH:mm > GMT{0} > > This is pretty similar to offset based time zone ID used by Java. > In LDML, this is localizable and used as final fallback of time zone > display name. > > For example, in Finnish (fi.xml) > > +H.mm;-H.mm > UTC{0} > > The shortest localized GMT format we're currently discussing in CLDR > project is based on this format, but shortest possible form. For > example, "GMT-05:00" might be shortened to "GMT-5" (no leading zero, > no minutes if zero). > > Also, LDML specification currently does not support non-zero seconds > offset. So, we're currently trying to sort out the requirements and > add necessary data structure to support them. > > > As for punctuations, I think comma and dot are already locale > > sensitive for number formatting, so it would be easy for people to > > understand how the locale sensitive punctuations for date time > > formatting work. Because the predefined formatting patterns for > > locales have the separators for date and time fields and they are > > commonly used, it doesn't seem to be an issue that there is no > > locale sensitive pattern letter for them. So I think I am only > > interested in the decimal separator for fractional seconds. > > Alternatively, if CLDR had predefined locale sensitive patterns with > > fractional seconds, that could also be a solution. For instance, a > > predefined common pattern to print hour, minute, second and > > millisecond for the US locale may look like this: > > > > HH:mm:ss.SSS > dateFormatItem> > > If forwarded a note to the CLDR development list and got a feedback > about 'f'. > Stephen pointed out 'f' can be used for min/max decimal digits. > However, Mark Davis(google) suggested if JSR-310 can use number format > pattern like syntax. For example, > > HH:mm:ss.SSS### > > Above pattern indicates minimum 3 /up to 6 decimal digits. Such syntax > might be easier to understand and a little bit more flexible (can set > maximum digits, not only for 9). I personally agree that above syntax > is better than "HH:mm:ss.ffSSS". > > -Yoshito From scolebourne at joda.org Wed Dec 19 18:19:38 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 20 Dec 2012 02:19:38 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets Message-ID: <20121220022057.C0437472B4@hg.openjdk.java.net> Changeset: 5260a56d5678 Author: scolebourne Date: 2012-12-19 23:13 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5260a56d5678 Refactor Query to real interface TemporalQuery ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/ZoneId.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/format/DateTimeBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java + src/share/classes/javax/time/temporal/TemporalQuery.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatters.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java ! test/javax/time/test/javax/time/TestInstant.java ! test/javax/time/test/javax/time/TestZoneId.java Changeset: deebc47cd653 Author: scolebourne Date: 2012-12-19 23:55 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/deebc47cd653 Refactor WithAdjuster to real interface TemporalAdjuster ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/temporal/Adjusters.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java + src/share/classes/javax/time/temporal/TemporalAdjuster.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: 4606462e13e6 Author: scolebourne Date: 2012-12-20 00:20 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4606462e13e6 Refactor PlusAdjuster to real interface TemporalAdder ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java + src/share/classes/javax/time/temporal/TemporalAdder.java ! src/share/classes/javax/time/temporal/TemporalUnit.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/MockSimplePeriod.java ! test/javax/time/test/javax/time/TestPeriod.java Changeset: fc3b5427c287 Author: scolebourne Date: 2012-12-20 00:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fc3b5427c287 Refactor MinusAdjuster to real interface TemporalSubtractor ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java ! src/share/classes/javax/time/temporal/TemporalAdder.java + src/share/classes/javax/time/temporal/TemporalSubtractor.java ! src/share/classes/javax/time/temporal/TemporalUnit.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/MockSimplePeriod.java ! test/javax/time/test/javax/time/TestPeriod.java Changeset: 1720b7977837 Author: scolebourne Date: 2012-12-20 01:17 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1720b7977837 Rename adjust() to adjustInto() ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/LocalDateTime.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/temporal/Adjusters.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTimeImpl.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/Temporal.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java ! src/share/classes/javax/time/temporal/TemporalAdder.java ! src/share/classes/javax/time/temporal/TemporalAdjuster.java ! src/share/classes/javax/time/temporal/TemporalQuery.java ! src/share/classes/javax/time/temporal/TemporalSubtractor.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! src/share/classes/javax/time/temporal/package.html ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKDateTimeAdjusters.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: 578fb8ee1ac4 Author: scolebourne Date: 2012-12-20 01:51 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/578fb8ee1ac4 Enhance Javadoc ! src/share/classes/javax/time/Duration.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/Period.java ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/MonthDay.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/TemporalAdder.java ! src/share/classes/javax/time/temporal/TemporalAdjuster.java ! src/share/classes/javax/time/temporal/TemporalSubtractor.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java From scolebourne at joda.org Wed Dec 19 18:27:45 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Dec 2012 02:27:45 +0000 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: <50D24A58.4030303@oracle.com> References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> <50D24A58.4030303@oracle.com> Message-ID: On 19 December 2012 23:14, Dan Chiba wrote: > For fractional seconds, I think JSR-310 should use the number formatting > conventions if CLDR updates the syntax to incorporate them. Imho conformance > is far more important than whether we use 'f' or number format syntax. > > Hi Stephen, > > Would you agree to do "HH:mm:ss.SSS###" for printing 3 to 6 fractional > digits, like number formatting? I am happy with the ### approach, but we need a GitHub issue to track it. Also, it does not handle the localized decimal point (dot or comma), but perhaps we don't need that. Stephen From Roger.Riggs at Oracle.com Wed Dec 19 20:30:21 2012 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Dec 2012 23:30:21 -0500 Subject: [threeten-dev] Webrev for renames of WeekDefinition and JulianDayFields Message-ID: <50D2945D.4030707@Oracle.com> Hi, Please review these changes to rename WeekDefinition to WeekFields and JulianDayField to JulianFields. http://cr.openjdk.java.net/~rriggs/webrev-renames/ Thanks, Roger From xueming.shen at oracle.com Wed Dec 19 21:47:18 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 20 Dec 2012 05:47:18 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Hooked BuildJdk.gmk to build tzdb.jar in new build system Message-ID: <20121220054739.5E351472BD@hg.openjdk.java.net> Changeset: 5c7bb7fbc31d Author: sherman Date: 2012-12-19 21:52 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5c7bb7fbc31d Hooked BuildJdk.gmk to build tzdb.jar in new build system ! makefiles/BuildJdk.gmk + makefiles/CompileTimeZoneData.gmk From xueming.shen at oracle.com Wed Dec 19 23:46:53 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 20 Dec 2012 07:46:53 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated j.u.Formatter to TemporalQuery. Message-ID: <20121220074743.E6524472C3@hg.openjdk.java.net> Changeset: 55c93d854e2c Author: sherman Date: 2012-12-19 23:51 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/55c93d854e2c Updated j.u.Formatter to TemporalQuery. ! src/share/classes/java/util/Formatter.java From xueming.shen at oracle.com Thu Dec 20 00:05:29 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 00:05:29 -0800 Subject: [threeten-dev] ZoneId.getText() and generic name Message-ID: <50D2C6C9.7090503@oracle.com> The change to support the generic zone name in ZoneId.getText(...) http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidtext Naoto, Masayoshi, Is it possible to have a TimeZoneNameUtility.retrieveDispalyNamesExt(id, locale); to have the generic names attached to the id/std/dst list? preferred cached as well:-) btw, the generic names in cldr are not translated? I tried the Japanese locale, it appears they are all English, while the std/dst are translated. Or did I do anything wrong? Thanks, -Sherman From scolebourne at joda.org Thu Dec 20 01:06:11 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Dec 2012 09:06:11 +0000 Subject: [threeten-dev] Webrev for renames of WeekDefinition and JulianDayFields In-Reply-To: <50D2945D.4030707@Oracle.com> References: <50D2945D.4030707@Oracle.com> Message-ID: +1 On 20 December 2012 04:30, Roger Riggs wrote: > Hi, > > Please review these changes to rename WeekDefinition to WeekFields and > JulianDayField to JulianFields. > > http://cr.openjdk.java.net/~rriggs/webrev-renames/ > > Thanks, Roger > From masayoshi.okutsu at oracle.com Thu Dec 20 01:29:36 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 20 Dec 2012 18:29:36 +0900 Subject: [threeten-dev] ZoneId.getText() and generic name In-Reply-To: <50D2C6C9.7090503@oracle.com> References: <50D2C6C9.7090503@oracle.com> Message-ID: <50D2DA80.1080207@oracle.com> On 12/20/2012 5:05 PM, Xueming Shen wrote: > The change to support the generic zone name in ZoneId.getText(...) > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidtext > > Naoto, Masayoshi, > > Is it possible to have a > > TimeZoneNameUtility.retrieveDispalyNamesExt(id, locale); > > to have the generic names attached to the id/std/dst list? > preferred cached as well:-) Yes, it's possible, but I prefer not to cache resources in JSR 310. Naoto is cleaning up/improving caches. > btw, the generic names in cldr are not translated? I tried > the Japanese locale, it appears they are all English, while > the std/dst are translated. Or did I do anything wrong? The generic names in JRE are not translated. There are some differences between the legacy JRE localized time zone names and CLDR ones. I "invented" generic names in English, but will need to request translation of generic time zone names. If you specify CLDR as the source of localized resources, you should get translated generic names. That is, specify -Djava.locale.providers=CLDR. Thanks, Masayoshi From scolebourne at joda.org Thu Dec 20 02:35:11 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Dec 2012 10:35:11 +0000 Subject: [threeten-dev] ZoneId.getText() and generic name In-Reply-To: <50D2C6C9.7090503@oracle.com> References: <50D2C6C9.7090503@oracle.com> Message-ID: This seems like a step forward. Caching of this data would be best placed in the providers rather than the 310 code. Stephen On 20 December 2012 08:05, Xueming Shen wrote: > The change to support the generic zone name in ZoneId.getText(...) > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidtext > > Naoto, Masayoshi, > > Is it possible to have a > > TimeZoneNameUtility.retrieveDispalyNamesExt(id, locale); > > to have the generic names attached to the id/std/dst list? > preferred cached as well:-) > > btw, the generic names in cldr are not translated? I tried > the Japanese locale, it appears they are all English, while > the std/dst are translated. Or did I do anything wrong? > > Thanks, > -Sherman > > From scolebourne at joda.org Thu Dec 20 04:37:01 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 20 Dec 2012 12:37:01 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121220123823.498CB472CC@hg.openjdk.java.net> Changeset: 9029aef705bb Author: scolebourne Date: 2012-12-20 12:31 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9029aef705bb Test and fix null handling in Period add/subtract ! src/share/classes/javax/time/Period.java ! test/javax/time/test/javax/time/TestPeriod.java Changeset: 3c48cec5f376 Author: scolebourne Date: 2012-12-20 12:32 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3c48cec5f376 Change PeriodBetween interface to SimplePeriod class Fixes #181 ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ISOFields.java ! src/share/classes/javax/time/temporal/Ser.java + src/share/classes/javax/time/temporal/SimplePeriod.java ! src/share/classes/javax/time/temporal/TemporalUnit.java + test/javax/time/resources/SimplePeriod.bin ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/calendar/TestChronoLocalDateTime.java + test/javax/time/tck/javax/time/temporal/TCKSimplePeriod.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDate.java ! test/javax/time/tck/javax/time/temporal/TestChronoLocalDateTime.java ! test/javax/time/tck/javax/time/temporal/TestChronoZonedDateTime.java From Roger.Riggs at Oracle.com Thu Dec 20 10:38:12 2012 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 20 Dec 2012 13:38:12 -0500 Subject: [threeten-dev] Review for changes to JulianFields and QuarterOfYear unit Message-ID: <50D35B14.7030605@Oracle.com> Addressing changes in: #177 Refactor JulianDayFeild enum to Julian Fields Renamed and refactored #183 Rename WeekDefinition to WeekFields Renamed and refactored #180 Reduce set of ChronoUnits Removed HALF_YEARS Moved QUARTER_YEARS to ISOFields http://cr.openjdk.java.net/~rriggs/webrev-units/ Comments, please. Roger From xueming.shen at oracle.com Thu Dec 20 10:48:46 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 10:48:46 -0800 Subject: [threeten-dev] ZoneId.getText() and generic name In-Reply-To: <50D2DA80.1080207@oracle.com> References: <50D2C6C9.7090503@oracle.com> <50D2DA80.1080207@oracle.com> Message-ID: <50D35D8E.9070106@oracle.com> On 12/20/2012 01:29 AM, Masayoshi Okutsu wrote: > On 12/20/2012 5:05 PM, Xueming Shen wrote: >> The change to support the generic zone name in ZoneId.getText(...) >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidtext >> >> Naoto, Masayoshi, >> >> Is it possible to have a >> >> TimeZoneNameUtility.retrieveDispalyNamesExt(id, locale); >> >> to have the generic names attached to the id/std/dst list? >> preferred cached as well:-) > > Yes, it's possible, but I prefer not to cache resources in JSR 310. Naoto is cleaning up/improving caches. Agree the cache need to be in Naoto's place:-) So far I have had three places need to cache those Strings... and ZoneId.getText(...) should/can then invoke the utility method directly to obtain the text for specific style/locale without having to build a date/time formatter. > >> btw, the generic names in cldr are not translated? I tried >> the Japanese locale, it appears they are all English, while >> the std/dst are translated. Or did I do anything wrong? > > The generic names in JRE are not translated. There are some differences between the legacy JRE localized time zone names and CLDR ones. I "invented" generic names in English, but will need to request translation of generic time zone names. > > If you specify CLDR as the source of localized resources, you should get translated generic names. That is, specify -Djava.locale.providers=CLDR. > Yep, I'm having Japanese name now with CLDR. Thanks! -Sherman From scolebourne at joda.org Thu Dec 20 10:45:17 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 20 Dec 2012 18:45:17 +0000 Subject: [threeten-dev] [threeten-develop] Review for changes to JulianFields and QuarterOfYear unit In-Reply-To: <50D35B14.7030605@Oracle.com> References: <50D35B14.7030605@Oracle.com> Message-ID: WeekFields has a mstaken text: "/**format" Otherwise push away. Stephen On 20 December 2012 18:38, Roger Riggs wrote: > Addressing changes in: > > #177 Refactor JulianDayFeild enum to Julian Fields > Renamed and refactored > #183 Rename WeekDefinition to WeekFields > Renamed and refactored > #180 Reduce set of ChronoUnits > Removed HALF_YEARS > Moved QUARTER_YEARS to ISOFields > > http://cr.openjdk.java.net/~rriggs/webrev-units/ > > Comments, please. > > Roger > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > From xueming.shen at oracle.com Thu Dec 20 10:56:27 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 10:56:27 -0800 Subject: [threeten-dev] Review for changes to JulianFields and QuarterOfYear unit In-Reply-To: <50D35B14.7030605@Oracle.com> References: <50D35B14.7030605@Oracle.com> Message-ID: <50D35F5B.3000107@oracle.com> The "implementation notes" of JulianFields still says "This is ...enum". On 12/20/2012 10:38 AM, Roger Riggs wrote: > Addressing changes in: > > #177 Refactor JulianDayFeild enum to Julian Fields > Renamed and refactored > #183 Rename WeekDefinition to WeekFields > Renamed and refactored > #180 Reduce set of ChronoUnits > Removed HALF_YEARS > Moved QUARTER_YEARS to ISOFields > > http://cr.openjdk.java.net/~rriggs/webrev-units/ > > Comments, please. > > Roger > From naoto.sato at oracle.com Thu Dec 20 10:46:07 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 20 Dec 2012 10:46:07 -0800 Subject: [threeten-dev] ZoneId.getText() and generic name In-Reply-To: <50D2DA80.1080207@oracle.com> References: <50D2C6C9.7090503@oracle.com> <50D2DA80.1080207@oracle.com> Message-ID: <50D35CEF.6050204@oracle.com> On 12/20/12 1:29 AM, Masayoshi Okutsu wrote: > On 12/20/2012 5:05 PM, Xueming Shen wrote: >> The change to support the generic zone name in ZoneId.getText(...) >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidtext >> >> Naoto, Masayoshi, >> >> Is it possible to have a >> >> TimeZoneNameUtility.retrieveDispalyNamesExt(id, locale); >> >> to have the generic names attached to the id/std/dst list? >> preferred cached as well:-) > > Yes, it's possible, but I prefer not to cache resources in JSR 310. > Naoto is cleaning up/improving caches. Right. I also would like to keep caches in one place. As I mentioned, I moved the cache in TimeZone down to TimeZoneNameUtility. Currently I am asking Masayoshi for the review internally, but if you dare, I'd appreciate it :-) http://cr.openjdk.java.net/~naoto/7162007/webrev.01/ Naoto > >> btw, the generic names in cldr are not translated? I tried >> the Japanese locale, it appears they are all English, while >> the std/dst are translated. Or did I do anything wrong? > > The generic names in JRE are not translated. There are some differences > between the legacy JRE localized time zone names and CLDR ones. I > "invented" generic names in English, but will need to request > translation of generic time zone names. > > If you specify CLDR as the source of localized resources, you should get > translated generic names. That is, specify -Djava.locale.providers=CLDR. > > Thanks, > Masayoshi > From xueming.shen at oracle.com Thu Dec 20 11:04:23 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 20 Dec 2012 19:04:23 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added zone generic name support to DTFB Message-ID: <20121220190507.4CA46472F5@hg.openjdk.java.net> Changeset: fa93697fc946 Author: sherman Date: 2012-12-20 11:09 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fa93697fc946 Added zone generic name support to DTFB ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java From roger.riggs at oracle.com Thu Dec 20 11:44:36 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 20 Dec 2012 19:44:36 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets Message-ID: <20121220194543.144E2472FA@hg.openjdk.java.net> Changeset: 07e17da342d9 Author: rriggs Date: 2012-12-19 23:18 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/07e17da342d9 Rename WeekDefinition to WeekFields; JulianDayField to JulianFields ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java - src/share/classes/javax/time/temporal/JulianDayField.java + src/share/classes/javax/time/temporal/JulianFields.java - src/share/classes/javax/time/temporal/WeekDefinition.java + src/share/classes/javax/time/temporal/WeekFields.java ! src/share/classes/javax/time/temporal/package.html ! src/share/classes/javax/time/zone/TzdbZoneRulesCompiler.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/format/TCKLocalizedFieldParser.java - test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java + test/javax/time/tck/javax/time/temporal/TCKJulianFields.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java - test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java + test/javax/time/tck/javax/time/temporal/TCKWeekFields.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/test/javax/time/TestDayOfWeek.java ! test/javax/time/test/javax/time/TestLocalDate.java ! test/javax/time/test/javax/time/TestLocalDateTime.java ! test/javax/time/test/javax/time/TestMonth.java ! test/javax/time/test/javax/time/TestZoneOffset.java ! test/javax/time/test/javax/time/temporal/TestISOChronoImpl.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestOffsetDateTime.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: abe9d987bc04 Author: rriggs Date: 2012-12-20 13:09 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/abe9d987bc04 #177 Refactor JulianDayFeild enum to Julian Fields Renamed and refactored #183 Rename WeekDefinition to WeekFields Renamed and refactored #180 Reduce set of ChronoUnits Removed HALF_YEARS Moved QUARTER_YEARS to ISOFields ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ISOFields.java ! src/share/classes/javax/time/temporal/JulianFields.java ! src/share/classes/javax/time/temporal/WeekFields.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/temporal/TCKJulianFields.java Changeset: 8da45dcf3383 Author: rriggs Date: 2012-12-20 13:19 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8da45dcf3383 Remove spurious text ! src/share/classes/javax/time/temporal/WeekFields.java Changeset: c1120a63b2b6 Author: rriggs Date: 2012-12-20 14:12 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c1120a63b2b6 Merge ! src/share/classes/javax/time/LocalDate.java ! src/share/classes/javax/time/calendar/ChronoDateImpl.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/temporal/ChronoUnit.java ! src/share/classes/javax/time/temporal/ISOFields.java ! src/share/classes/javax/time/temporal/JulianFields.java ! src/share/classes/javax/time/temporal/YearMonth.java ! src/share/classes/javax/time/temporal/package.html ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKMonthDay.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/tck/javax/time/temporal/TCKYear.java ! test/javax/time/tck/javax/time/temporal/TCKYearMonth.java ! test/javax/time/test/javax/time/temporal/TestMonthDay.java ! test/javax/time/test/javax/time/temporal/TestYear.java ! test/javax/time/test/javax/time/temporal/TestYearMonth.java Changeset: 7773c2ddae70 Author: rriggs Date: 2012-12-20 14:44 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7773c2ddae70 Merge ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java From dan.chiba at oracle.com Thu Dec 20 12:21:42 2012 From: dan.chiba at oracle.com (Dan Chiba) Date: Thu, 20 Dec 2012 12:21:42 -0800 Subject: [threeten-dev] Possible addition of pattern letters in CLDR In-Reply-To: References: <50C8ACE8.2060907@oracle.com> <50CA6014.3080209@oracle.com> <50CAA45D.6090000@oracle.com> <50D24A58.4030303@oracle.com> Message-ID: <50D37356.1060709@oracle.com> Hi Stephen, Github issue filed: https://github.com/ThreeTen/threeten/issues/187 Regards, -Dan On 12/19/2012 6:27 PM, Stephen Colebourne wrote: > On 19 December 2012 23:14, Dan Chiba wrote: >> For fractional seconds, I think JSR-310 should use the number formatting >> conventions if CLDR updates the syntax to incorporate them. Imho conformance >> is far more important than whether we use 'f' or number format syntax. >> >> Hi Stephen, >> >> Would you agree to do "HH:mm:ss.SSS###" for printing 3 to 6 fractional >> digits, like number formatting? > I am happy with the ### approach, but we need a GitHub issue to track it. > > Also, it does not handle the localized decimal point (dot or comma), > but perhaps we don't need that. > > Stephen From xueming.shen at oracle.com Thu Dec 20 14:25:55 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 14:25:55 -0800 Subject: [threeten-dev] #176 Cnveret ZoneRules from interface to calss Message-ID: <50D39073.4010906@oracle.com> Here is the webrev of the changes for #176 http://cr.openjdk.java.net/~sherman/jdk8_threeten/zrules -Sherman From scolebourne at joda.org Thu Dec 20 16:07:46 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 00:07:46 +0000 Subject: [threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss In-Reply-To: <50D39073.4010906@oracle.com> References: <50D39073.4010906@oracle.com> Message-ID: The rules for offsets are created and thrown away rapidly, whereas ZoneId rules are cached. Thus I think we should keep the special implementation for offsets (as a hidden inner class). It is likely to have much better performance and garbage collection because it is simpler. At the very least, there should be a dedicated factory method, perhaps setting fields to null rather than empty arrays. ZoneRules.of(ZoneOffset) The factory will need more Javadoc to describe what the parameters are and how they describe the rules, but you don't need to do that now. The limit of 15 zone rules is weird (my previous weird code), it should be an even number, such as 16. ZoneRules.of(...) factory needs to ensure that no nulls are passed in any list. I suspect that this happens now, but there needs to be a test for it. ZoneOffsetTransition @return should say "not null". It should also declare IllegalArgumentException being thrown. ZoneOffsetTransitionRule @return should be before @throws. "This method is intended for use for construction of {@code ZoneRules}." might be better phrased as "This factory is only intended for use when creating {@code ZoneRules}." (both ZoneOffsetTransition and ZoneOffsetTransitionRule) The variable SZR in Ser should be renamed to ZRULES. Otherwise looks good. And I think its a better and more maintainable solution. Stephen On 20 December 2012 22:25, Xueming Shen wrote: > Here is the webrev of the changes for #176 > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/zrules > > -Sherman > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Thu Dec 20 16:15:23 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 00:15:23 +0000 Subject: [threeten-dev] CFV: New threeten-dev Committer: Michael Nascimento Message-ID: I hereby nominate Michael Nascimento to threeten-dev Committer. Michael is a spec lead of JSR 310 and made significant contributions to the specification and implementation. Votes are due by Friday Dec 21 (tomorrow). Only current threeten-dev Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. Stephen Colebourne [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From scolebourne at joda.org Thu Dec 20 16:16:55 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 00:16:55 +0000 Subject: [threeten-dev] CFV: New threeten-dev Committer: Michael Nascimento In-Reply-To: References: Message-ID: Vote: yes On 21 December 2012 00:15, Stephen Colebourne wrote: > > I hereby nominate Michael Nascimento to threeten-dev Committer. > > Michael is a spec lead of JSR 310 and made significant contributions > to the specification and implementation. > > Votes are due by Friday Dec 21 (tomorrow). > > Only current threeten-dev Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Stephen Colebourne > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From xueming.shen at oracle.com Thu Dec 20 17:08:25 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 17:08:25 -0800 Subject: [threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss In-Reply-To: References: <50D39073.4010906@oracle.com> <50D3ABE2.2060608@oracle.com> Message-ID: <50D3B689.6050409@oracle.com> I'm not sure if we want to have an extra public factory method of(ZoneOffset) to simply for better memory performance when being created from ZoneOffset.getRules(), which probably will not happen in normal scenario. The webrev has been updated for your other comments. I will try to see if we can have a better option. -Sherman On 12/20/2012 04:52 PM, Stephen Colebourne wrote: > On 21 December 2012 00:22, Xueming Shen wrote: >> On 12/20/2012 04:07 PM, Stephen Colebourne wrote: >>> The rules for offsets are created and thrown away rapidly, whereas >>> ZoneId rules are cached. Thus I think we should keep the special >>> implementation for offsets (as a hidden inner class). It is likely to >>> have much better performance and garbage collection because it is >>> simpler. >> Agreed. But the problem is that we want to return a ZoneRules, which is >> supposed to be final... There should be not too big impact to the memory >> footprint, given those a singleton empty list or zero-length array, but yes, >> ideally we can have a simple representation for this special case. > A non-final class with a package-scoped construcor can be considered > to be immutable if all the fields it holds are declared final. > > We're talking about 16 extra bytes per instance created, which isn't > ideal. If the other fields were null it may help the gc more than > having empty arrays. > > Perhaps we could invert the internal hierarchy. Have the simple > implementation as ZoneRules and the complex implementation as the > subclass? A little weird, but effective in memory usage, and hidden > from most users. > > I'd suggest you start by adding the extra factory method, and maybe > push that. The internal optimisation can then come later. > > Stephen > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Thu Dec 20 17:08:56 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 01:08:56 +0000 Subject: [threeten-dev] DateTimeFormatters - pattern Z and X and SimpleDateFormat In-Reply-To: References: Message-ID: On 19 December 2012 05:42, wrote: > I have some comments: > > - Why don't you add "XXXX" and "XXXXX" example cases? i.e. "Z; -0800; > -08:00;" -> "Z; -0800; -08:00;+013015;+01:30:15" It does get quite long, but I've made the change. > - Pattern 'Z' and 'X' are extended. Can we simply extend the definition of > SimpleDateFormat to support them? Of course, it will be an incompatible > change, but the impact would be pretty minor. Its not up to me to control SimpleDateFormat. There would be some logic to them being the same. > - Why don't you introduce optional second support to pattern Z? (By doing > so, only the difference between Z and X is formatting offset zero; "+0000" > vs "Z"). That would be desirable. However, I note that CLDR/LDML already defines 4 and 5 pattern letters for Z, and they don't match 310 or this proposal. Stephen From scolebourne at joda.org Thu Dec 20 17:11:56 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 01:11:56 +0000 Subject: [threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss In-Reply-To: <50D3B689.6050409@oracle.com> References: <50D39073.4010906@oracle.com> <50D3ABE2.2060608@oracle.com> <50D3B689.6050409@oracle.com> Message-ID: On 21 December 2012 01:08, Xueming Shen wrote: > I'm not sure if we want to have an extra public factory method of(ZoneOffset) > to simply for better memory performance when being created from > ZoneOffset.getRules(), which probably will not happen in normal scenario. ZoneOffset.getRules() will be called a lot via ZDT. It is vital to have the extra factory so we can optimise later. Just constructing the empty lsts and passin 5 arguments rather than 1 is an overhead. Stephen > The webrev has been updated for your other comments. > > I will try to see if we can have a better option. > > -Sherman > > On 12/20/2012 04:52 PM, Stephen Colebourne wrote: >> On 21 December 2012 00:22, Xueming Shen wrote: >>> On 12/20/2012 04:07 PM, Stephen Colebourne wrote: >>>> The rules for offsets are created and thrown away rapidly, whereas >>>> ZoneId rules are cached. Thus I think we should keep the special >>>> implementation for offsets (as a hidden inner class). It is likely to >>>> have much better performance and garbage collection because it is >>>> simpler. >>> Agreed. But the problem is that we want to return a ZoneRules, which is >>> supposed to be final... There should be not too big impact to the memory >>> footprint, given those a singleton empty list or zero-length array, but yes, >>> ideally we can have a simple representation for this special case. >> A non-final class with a package-scoped construcor can be considered >> to be immutable if all the fields it holds are declared final. >> >> We're talking about 16 extra bytes per instance created, which isn't >> ideal. If the other fields were null it may help the gc more than >> having empty arrays. >> >> Perhaps we could invert the internal hierarchy. Have the simple >> implementation as ZoneRules and the complex implementation as the >> subclass? A little weird, but effective in memory usage, and hidden >> from most users. >> >> I'd suggest you start by adding the extra factory method, and maybe >> push that. The internal optimisation can then come later. >> >> Stephen >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Thu Dec 20 17:32:19 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Fri, 21 Dec 2012 01:32:19 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Better example for pattern letter X Message-ID: <20121221013241.9481747317@hg.openjdk.java.net> Changeset: 40a86243066d Author: scolebourne Date: 2012-12-21 01:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/40a86243066d Better example for pattern letter X ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeFormatters.java From Roger.Riggs at Oracle.com Thu Dec 20 17:34:39 2012 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 20 Dec 2012 20:34:39 -0500 Subject: [threeten-dev] CFV: New threeten-dev Committer: Michael Nascimento In-Reply-To: References: Message-ID: <50D3BCAF.50907@Oracle.com> Vote: yes On 12/20/12 7:15 PM, Stephen Colebourne wrote: > I hereby nominate Michael Nascimento to threeten-dev Committer. > > Michael is a spec lead of JSR 310 and made significant contributions > to the specification and implementation. > > Votes are due by Friday Dec 21 (tomorrow). > > Only current threeten-dev Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Stephen Colebourne > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From xueming.shen at oracle.com Thu Dec 20 17:55:15 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 17:55:15 -0800 Subject: [threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss In-Reply-To: References: <50D39073.4010906@oracle.com> <50D3ABE2.2060608@oracle.com> <50D3B689.6050409@oracle.com> Message-ID: <50D3C183.6000609@oracle.com> On 12/20/12 5:11 PM, Stephen Colebourne wrote: > On 21 December 2012 01:08, Xueming Shen wrote: >> I'm not sure if we want to have an extra public factory method of(ZoneOffset) >> to simply for better memory performance when being created from >> ZoneOffset.getRules(), which probably will not happen in normal scenario. > ZoneOffset.getRules() will be called a lot via ZDT. It is vital to > have the extra factory so we can optimise later. Just constructing the > empty lsts and passin 5 arguments rather than 1 is an overhead. We definitely need to come back and address this issue. Even with the specific factory method and an optimized version of ZoneRules, we probably still have a bigger issue with the current design/implementation, if ZDT.getZone().getRules() always creates a new rules object when the zone is a ZoneOffset. I will add a of(ZoneOffset) to rest the case for now. > > Stephen > > >> The webrev has been updated for your other comments. >> >> I will try to see if we can have a better option. >> >> -Sherman >> >> On 12/20/2012 04:52 PM, Stephen Colebourne wrote: >>> On 21 December 2012 00:22, Xueming Shen wrote: >>>> On 12/20/2012 04:07 PM, Stephen Colebourne wrote: >>>>> The rules for offsets are created and thrown away rapidly, whereas >>>>> ZoneId rules are cached. Thus I think we should keep the special >>>>> implementation for offsets (as a hidden inner class). It is likely to >>>>> have much better performance and garbage collection because it is >>>>> simpler. >>>> Agreed. But the problem is that we want to return a ZoneRules, which is >>>> supposed to be final... There should be not too big impact to the memory >>>> footprint, given those a singleton empty list or zero-length array, but yes, >>>> ideally we can have a simple representation for this special case. >>> A non-final class with a package-scoped construcor can be considered >>> to be immutable if all the fields it holds are declared final. >>> >>> We're talking about 16 extra bytes per instance created, which isn't >>> ideal. If the other fields were null it may help the gc more than >>> having empty arrays. >>> >>> Perhaps we could invert the internal hierarchy. Have the simple >>> implementation as ZoneRules and the complex implementation as the >>> subclass? A little weird, but effective in memory usage, and hidden >>> from most users. >>> >>> I'd suggest you start by adding the extra factory method, and maybe >>> push that. The internal optimisation can then come later. >>> >>> Stephen >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop From xueming.shen at oracle.com Thu Dec 20 17:57:24 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 17:57:24 -0800 Subject: [threeten-dev] CFV: New threeten-dev Committer: Michael Nascimento In-Reply-To: References: Message-ID: <50D3C204.1040008@oracle.com> Vote: yes On 12/20/12 4:15 PM, Stephen Colebourne wrote: > I hereby nominate Michael Nascimento to threeten-dev Committer. > > Michael is a spec lead of JSR 310 and made significant contributions > to the specification and implementation. > > Votes are due by Friday Dec 21 (tomorrow). > > Only current threeten-dev Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Stephen Colebourne > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From xueming.shen at oracle.com Thu Dec 20 18:49:21 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 18:49:21 -0800 Subject: [threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss In-Reply-To: References: <50D39073.4010906@oracle.com> <50D3ABE2.2060608@oracle.com> <50D3B689.6050409@oracle.com> Message-ID: <50D3CE31.6090501@oracle.com> Stephen, Webrev has been updated with the ZO factory method and some cached 0-length array optimization. http://cr.openjdk.java.net/~sherman/jdk8_threeten/zrules/ -Sherman On 12/20/12 5:11 PM, Stephen Colebourne wrote: > On 21 December 2012 01:08, Xueming Shen wrote: >> I'm not sure if we want to have an extra public factory method of(ZoneOffset) >> to simply for better memory performance when being created from >> ZoneOffset.getRules(), which probably will not happen in normal scenario. > ZoneOffset.getRules() will be called a lot via ZDT. It is vital to > have the extra factory so we can optimise later. Just constructing the > empty lsts and passin 5 arguments rather than 1 is an overhead. > > Stephen > > >> The webrev has been updated for your other comments. >> >> I will try to see if we can have a better option. >> >> -Sherman >> >> On 12/20/2012 04:52 PM, Stephen Colebourne wrote: >>> On 21 December 2012 00:22, Xueming Shen wrote: >>>> On 12/20/2012 04:07 PM, Stephen Colebourne wrote: >>>>> The rules for offsets are created and thrown away rapidly, whereas >>>>> ZoneId rules are cached. Thus I think we should keep the special >>>>> implementation for offsets (as a hidden inner class). It is likely to >>>>> have much better performance and garbage collection because it is >>>>> simpler. >>>> Agreed. But the problem is that we want to return a ZoneRules, which is >>>> supposed to be final... There should be not too big impact to the memory >>>> footprint, given those a singleton empty list or zero-length array, but yes, >>>> ideally we can have a simple representation for this special case. >>> A non-final class with a package-scoped construcor can be considered >>> to be immutable if all the fields it holds are declared final. >>> >>> We're talking about 16 extra bytes per instance created, which isn't >>> ideal. If the other fields were null it may help the gc more than >>> having empty arrays. >>> >>> Perhaps we could invert the internal hierarchy. Have the simple >>> implementation as ZoneRules and the complex implementation as the >>> subclass? A little weird, but effective in memory usage, and hidden >>> from most users. >>> >>> I'd suggest you start by adding the extra factory method, and maybe >>> push that. The internal optimisation can then come later. >>> >>> Stephen >>> >>> From xueming.shen at oracle.com Thu Dec 20 19:10:37 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 21 Dec 2012 03:10:37 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Changed ZoneRules back to final class from interface Message-ID: <20121221031050.F11D94731B@hg.openjdk.java.net> Changeset: 35911ae14de2 Author: sherman Date: 2012-12-20 19:15 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/35911ae14de2 Changed ZoneRules back to final class from interface ! src/share/classes/javax/time/ZoneOffset.java ! src/share/classes/javax/time/zone/Ser.java - src/share/classes/javax/time/zone/StandardZoneRules.java ! src/share/classes/javax/time/zone/ZoneOffsetTransition.java ! src/share/classes/javax/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/javax/time/zone/ZoneRules.java ! src/share/classes/javax/time/zone/ZoneRulesBuilder.java + test/javax/time/tck/javax/time/zone/TCKZoneRules.java - test/javax/time/test/javax/time/zone/TestStandardZoneRules.java From masayoshi.okutsu at oracle.com Thu Dec 20 23:06:09 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 21 Dec 2012 16:06:09 +0900 Subject: [threeten-dev] DateTimeFormatters - pattern Z and X and SimpleDateFormat In-Reply-To: References: Message-ID: <50D40A61.7040403@oracle.com> On 12/21/2012 10:08 AM, Stephen Colebourne wrote: > On 19 December 2012 05:42, wrote: >> - Pattern 'Z' and 'X' are extended. Can we simply extend the definition of >> SimpleDateFormat to support them? Of course, it will be an incompatible >> change, but the impact would be pretty minor. > Its not up to me to control SimpleDateFormat. There would be some > logic to them being the same. It's always a problem that there's no way to predict the impact of an incompatible change. If it's known that there's a minor compatibility impact, probably the incompatible change shouldn't be made. Masayoshi From xueming.shen at oracle.com Thu Dec 20 23:54:20 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Dec 2012 23:54:20 -0800 Subject: [threeten-dev] TemporalAdder and TemporalSubtractor In-Reply-To: <50D2205D.4040502@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> Message-ID: <50D415AC.4020209@oracle.com> Stephen, My guts suggest that these two still don't fit well into the rest of the "mini temporal framework:-)" that you are busy building inside the temporal package. It has been a while since we spent lots of time trying to find the best solution for the field/unit interfaces, lots of changes/evolution in this date/time + field/unit interface group since then. The changes for the adjuster and query appear reasonable and I agree the current approach provides good extensibility and fits well into the coming lambda world. However I kinda feel we might have better alternative for adder and subtractor interfaces. Basically we need 2 types of the plus/minus support (on top of those fluent style convenient plus/minus methods in those concrete date/time classes). (1) Temporal + N TemporalUnit (2) Temporal + Duration/Period (1) has been well designed/implemented and very extensible, developer can easily design/implement their own TemporalUnit and fit into the "framework" smoothly, if they can not find the good match in existing ChronoUnit The problem is the duration/period part. The current approach is to have two powerful and "general purpose" interface adder and subtractor (like the adjuster) to serve the purposes of (1) a common interface for duration/period/simpleperiod, so those temporal classes don't have to have multiple individual methods for each type (2) provide the extensibility for time duration/period. My first concern with this approach is that we already have a general purpose/ powerful hook TemporalAdjuster in Temporal already, yes, it's "with" family, but conceptually plus/minus is a kind of "adjust" operation as well. They take a "temporal" and then turn/adjust it into something else with certain algorithm (to tweak certain fields, or plus/minus something to certain fields). So do we really need the second and third similar interface on a single/simple abstraction? You can reasonably do anything to the "Temporal" with a "adjuster" and make it a lambda expression, if desired. Another concern is the mismatch of what we really need here and the rest of the interface family (and naming as well). Developer will have to take two new and "abstract" concepts here, the TemporalAdder and TemporalSubstractor. Compared to their straightforward siblings a) fluent style plus/minusDate/Time(...) and 2) plus/minus(N, Unit), which basically says a certain point at time scale plus/minus a certain time duration, the TemporalAdder/Subtractor appear to be strange, they are "something can be added to a date/time/temporal". Given the nature of the plus/minus operation on a time, why not just specify this "something" clearly, it's a "time duration/period" (what else you can add and substract from a date/time?), which is what we really need here. We need an abstraction/super interface for Duration, Period and SimplePeriod, so Temporal.minus/plus can apply on it. And something can also provide the extensibility if these three can not meet what developers need in their specific scenario and have to define something by themselves (but this something still have to be some "time duration", right?) And take a look at your "mini framework", we now have abstractions Temporal and its read-only buddy TemporalAccessor, for date/time types TemporalField, for those date/time fields TemporalUnit, for those date/time units the only piece missing is the "temporal" duration/period, we have concrete classes of Duration, Period and SimplePeriod, but don't have a "temporal" version of it. And it appears the Temporal.minus/plus() really need such one to fit into its API. Instead of a pair of abstract "adder" and "substractor", isn't a single TemporalPeriod a better alternative here? I'm not sure what should be really in this super interface, maybe abs(), isPositive(), doPlus() and a doMinus() (arguably, if it's "directed", maybe doMinus() is not necessary) But this should not be an issue. Sure, we might miss the fancy functional type with such an interface, but given the existing TemporalAdjuster, we really don't need another similar weapon. Personally I believe a TemporalPeriod is clear and simple, provides the extensibility we are looking for and well fit into the rest of the APIs. -Sherman From xueming.shen at oracle.com Fri Dec 21 00:11:20 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 21 Dec 2012 08:11:20 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Added jdk_time to test/Makefile so it can run nightly Message-ID: <20121221081142.2477047328@hg.openjdk.java.net> Changeset: 7aa1cde90807 Author: sherman Date: 2012-12-21 00:16 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7aa1cde90807 Added jdk_time to test/Makefile so it can run nightly ! test/Makefile From richard.warburton at gmail.com Fri Dec 21 06:57:42 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Fri, 21 Dec 2012 14:57:42 +0000 Subject: [threeten-dev] CFV: New threeten-dev Committer: Michael Nascimento In-Reply-To: <50D3C204.1040008@oracle.com> References: <50D3C204.1040008@oracle.com> Message-ID: Vote: yes regards, Richard From scolebourne at joda.org Fri Dec 21 07:56:33 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 15:56:33 +0000 Subject: [threeten-dev] Result: New ThreeTen Committer: Michael Nascimento Message-ID: Voting for Michael Nascimento [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Stephen Colebourne [1] http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000329.html From scolebourne at joda.org Fri Dec 21 09:35:30 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 21 Dec 2012 17:35:30 +0000 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: <50D415AC.4020209@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> Message-ID: On 21 December 2012 07:54, Xueming Shen wrote: A TemporalPeriod concept is reasonable, however I don't think it removes the need for Adder/Subtractor. Consider the a balanced equivalence: Temporal - defines the date-time type TemporalAdjuster - deifnes how to make the adjustment TemporalPeriod - defines the period type TemporalAdder/Subtractor - defines how to add/subtract Currently, we don't have TemporalPeriod, primarily because we don't have period formatting (a useful thing for JDK9 maybe). Under this balanced equivalence approach, the TemporalPeriod would look something like this: isSupported(Unit) get(Unit) getLong(Unit) ie, it would provide access to the unit-long map, not the addition/subtraction (which is what would be needed for a period formatter) By contrast, your chosen set of methods for TemporalPeriod are really an extended set from Adder/Subtractor, and would not fulfil the period formatter use case. Stephen From scolebourne at joda.org Fri Dec 21 10:51:55 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Fri, 21 Dec 2012 18:51:55 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Better Javadoc for case sensitivity, and no switch on ennum Message-ID: <20121221185227.0B5F94734A@hg.openjdk.java.net> Changeset: d6809a1a0dcf Author: scolebourne Date: 2012-12-21 18:51 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d6809a1a0dcf Better Javadoc for case sensitivity, and no switch on ennum See #189 ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java From xueming.shen at oracle.com Fri Dec 21 12:27:17 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 21 Dec 2012 12:27:17 -0800 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> Message-ID: <50D4C625.1050601@oracle.com> On 12/21/2012 09:35 AM, Stephen Colebourne wrote: > On 21 December 2012 07:54, Xueming Shen wrote: > A TemporalPeriod concept is reasonable, however I don't think it > removes the need for Adder/Subtractor. > > Consider the a balanced equivalence: > > Temporal - defines the date-time type > TemporalAdjuster - deifnes how to make the adjustment > > TemporalPeriod - defines the period type > TemporalAdder/Subtractor - defines how to add/subtract > While duration is one of the two fundamental elements (time and duration), I would assume the "time" (date/time) is the main topic in this API, which is Temporal in this mini framework, everything works on it and for it. The Adder and Subtractor here are not an exception, they try to help the plus and minus operations on a Temporal. What is Adder/Subtractor? If I understand the design correctly, it is something that is supposed to know how to add a duration (machine time duration, human time duration, known/existing duration or unknown type) to a known or unknown type of date/time. The method name plus/minus has already provided enough semantics information of WHAT should be done, it is temporal +/- duration -> new temporal And the HOW is clearly specified & implemented if the temporal and duration on the left side are known/existing date/time and duration classes. What needed here is SOMETHING that can help if there is an unknow type, either the temporal or the duration or both. This is similar to other extensibility mechanism need in other places with(field) minus/plus(unit) We add an general abstraction for field and unit, specify that the classes that implement/extend those interface take the responsibility of handling how to doWith and doMinus/Plus. There is no difference here for the period case. The one that has the best knowledge of how to add itself to a "temporal" is the period itself. Any adder/subtracter has to know the period first and then to know how to add/subtractor it to the temporal. Again, the equivalence here is New Temporal = Old Temporal +/- TemporalPeriod One of the temporal and/or temporal period need to know how to handle the plus/minus, if the TemporalPeriod is not one of those existing duration/period classes, it should take the responsibility of how to plus/minus it to a known temporal. The existing approach is New Temporal = Old Temporal +/- Adder/Subtractor(TemporalPeriod) what's the benefit of introducing a new layer of abstraction of "adder" and "subtracter" here? As I said, we have already have a general purpose "adjuster" interface to make adjustment on a temporal already. plus and minus is a special case of "adjustment", add/subtract 10 days from a date/time is the same as "adjust" the date/time 10 days from the date/time or before date/time. What we need here is NOT a mechanism of "HOW to add or minus a SOMETHING from a Temporal" but how to provide the extensibility of adding/subtracting a customized duration/period from a Temporal. "HOW to add or minus a SOMETHING from a Temporal" is the same as "HOW to ADJUST the Temporal by adding/minus SOMETHING", it's a manipulation of those date/time fields inside the temporal to make a new temporal, with a specific algorithm/rule. As I said in my previous email, we don't need a second one. How to define TemporalPeriod is not my point here, the methods I'm adding in are to fit it for the minus/plus operation, as the TemporalField/ Unit interface does. We definitely add more "general" access method into it, as you just suggested. Consider this, if we do introduce the TemporalPeriod later, does that make the TemporalAdder/Subtractor a redundant? at least for all the functionality it currently trying to provide? then make the TemporalPeriod subclass of both Adder and Subtractor? I would rather add a pure TemporalPeriod here for this purpose first, with the hope that we can add more concrete methods (with default implementation) later, if we are not sure what should be in for now. Bottom line is why you need an extra Adder and Subtractor to stand in the middle of Temporal = Temporal +/- TemporalDuration, when we have a clear defintion of plus/minus, and we have two abstractions clearly should/could know how to handle this well-defined operation. -Sherman > Currently, we don't have TemporalPeriod, primarily because we don't > have period formatting (a useful thing for JDK9 maybe). > > Under this balanced equivalence approach, the TemporalPeriod would > look something like this: > > isSupported(Unit) > get(Unit) > getLong(Unit) > > ie, it would provide access to the unit-long map, not the > addition/subtraction (which is what would be needed for a period > formatter) > > By contrast, your chosen set of methods for TemporalPeriod are really > an extended set from Adder/Subtractor, and would not fulfil the period > formatter use case. > > Stephen From xueming.shen at oracle.com Fri Dec 21 12:40:14 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 21 Dec 2012 12:40:14 -0800 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> Message-ID: <50D4C92E.2070408@oracle.com> On 12/21/2012 09:35 AM, Stephen Colebourne wrote: > On 21 December 2012 07:54, Xueming Shen wrote: > A TemporalPeriod concept is reasonable, however I don't think it > removes the need for Adder/Subtractor. > > Consider the a balanced equivalence: > > Temporal - defines the date-time type > TemporalAdjuster - deifnes how to make the adjustment > > TemporalPeriod - defines the period type > TemporalAdder/Subtractor - defines how to add/subtract While duration is one of the two fundamental elements (time and duration), I would assume the "time" (date/time) is the main topic in this API, which is Temporal in this mini framework, everything works on it and for it. The Adder and Subtractor here are not an exception, they try to help the plus and minus operations on a Temporal. What is Adder/Subtractor? If I understand the design correctly, it is something that is supposed to know how to add a duration (machine time duration, human time duration, known/existing duration or unknown type) to a known or unknown type of date/time. The method name plus/minus has already provided enough semantics information of WHAT should be done, it is temporal ? duration -> new temporal And the HOW is clearly specified & implemented if the temporal and duration on the left side are known/existing date/time and duration classes. What needed here is SOMETHING that can help if there is an unknow type, either the temporal or the duration or both. This is similar to other extensibility mechanism need in other places with(field) minus/plus(unit) We add an general abstraction for field and unit, specify that the classes that implement/extend those interface take the responsibility of handling how to doWith and doMinus/Plus. There is no difference here for the period case. The one that has the best knowledge of how to add itself to a "temporal" is the period itself. Any adder/subtracter has to know the period first and then to know how to add/subtractor it to the temporal. Again, the equivalence here is New Temporal = Old Temporal ? TemporalPeriod One of the temporal and/or temporal period need to know how to handle the plus/minus, if the TemporalPeriod is not one of those existing duration/period classes, it should take the responsibility of how to plus/minus it to a known temporal. The existing approach is New Temporal = Old Temporal ? Adder/Subtractor(TemporalPeriod) what's the benefit of introducing a new layer of abstraction of "adder" and "subtracter" here? As I said, we have already have a general purpose "adjuster" interface to make adjustment on a temporal already. plus and minus is a special case of "adjustment", add/subtract 10 days from a date/time is the same as "adjust" the date/time 10 days from the date/time or before date/time. What we need here is NOT a mechanism of "HOW to add or minus a SOMETHING from a Temporal" but how to provide the extensibility of adding/subtracting a customized duration/period from a Temporal. "HOW to add or minus a SOMETHING from a Temporal" is the same as "HOW to ADJUST the Temporal by adding/minus SOMETHING", it's a manipulation of those date/time fields inside the temporal to make a new temporal, with a specific algorithm/rule. As I said in my previous email, we don't need a second one. How to define TemporalPeriod is not my point here, the methods I'm adding in are to fit it for the minus/plus operation, as the TemporalField/ Unit interface does. We definitely add more "general" access method into it, as you just suggested. Consider this, if we do introduce the TemporalPeriod later, does that make the TemporalAdder/Subtractor a redundant? at least for all the functionality it currently trying to provide? then make the TemporalPeriod subclass of both Adder and Subtractor? I would rather add a pure TemporalPeriod here for this purpose first, with the hope that we can add more concrete methods (with default implementation) later, if we are not sure what should be in for now. Bottom line is why you need an extra Adder and Subtractor to stand in the middle of Temporal = Temporal ? TemporalDuration, when we have a clear definition of plus/minus, and we have two abstractions clearly should/could know how to handle this well-defined operation. -Sherman > Currently, we don't have TemporalPeriod, primarily because we don't > have period formatting (a useful thing for JDK9 maybe). > > Under this balanced equivalence approach, the TemporalPeriod would > look something like this: > > isSupported(Unit) > get(Unit) > getLong(Unit) > > ie, it would provide access to the unit-long map, not the > addition/subtraction (which is what would be needed for a period > formatter) > > By contrast, your chosen set of methods for TemporalPeriod are really > an extended set from Adder/Subtractor, and would not fulfil the period > formatter use case. > > Stephen From xueming.shen at oracle.com Sun Dec 23 00:18:21 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 23 Dec 2012 00:18:21 -0800 Subject: [threeten-dev] Move tzdb compiler out of j.t.z Message-ID: <50D6BE4D.1040008@oracle.com> Stephen, Here is the webrev for moving the tzdb compiler out of j.t.z package. http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzc/ The approach here appears to cause a slower startup compared to the existing one, as it uses ObjectOutput/InputStream directly to write out and read in zrules, instead of the DateOutput/InputStream, in which the existing impl can take advantage of the direct access to Ser to write out/read in "byte[]" of the zrules, so the TzdbZoneRuleProvider can do lazy-init. The compiler can't do it now because the Ser is package private. The plan-B is to externalize the Ser.write/read to somewhere, so the byte[] of the zrules' serialization form can be shared by the tzdb compiler (output side) and the tzdb provider (input side). Given we are talking about 600+ zone (the rules number is bigger) and a total < 40k data here, I took the simple, but slow, approach. We can revisit the start-up issue later, if it indeed is a concern. Let me know if you have concern of this approach, we can go Plan-B. I brought back the test for the ZoneRulesBuilder, as promised. But it appears there is a test failure at line#805. I have not looked into the detail yet. Just wonder if you have any idea. The changes in ZoneRulesBuilder are to workaround the beforeOffset==afterOffset issue. The old implementation creates the trans even two offsets are the same (use that package private constructor which does not do sanity check), but then throw it away. The code now does the sanity check before creating the trans. -Sherman From Roger.Riggs at Oracle.com Sun Dec 23 14:59:46 2012 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sun, 23 Dec 2012 17:59:46 -0500 Subject: [threeten-dev] Review updates to support multiple Hijrah deviations Message-ID: <50D78CE2.6000008@Oracle.com> Hi, This review addresses some of the issues in #95 Deviation Options for the Hijrah Calendar Please review and comment on: http://cr.openjdk.java.net/~rriggs/webrev-deviations/ The changes include refactoring the support for the deviations into the Chrono class from the HijrahDate class. The change includes changing HijrahDate so that it refers explicitly to an instance of HijrahChrono. Changes to HijrahChrono include multiple instances with different Ids and calendarTypes that encapsulate the different deviations. Each acts as a different calendar. The serialized form of HijrahDate includes the reference to the HijrahChrono instance (already serialized as represented by the id). The format of the deviation file is modified to use ISO dates which are converted to HijrahDates using the default Islamic calendar. The offsets modify the length of the HijrahMonths for the alternate calendar. The configuration mechanism for the deviation options is not final. System properties identify the additional Hijrah calendars; and the default location of the deviation files which are named according to the calendar id. The additional calendars are created when the standard Hijrah calendar is initialized. These changes also exposed a flaw in the registration mechanism used for Chrono.of(id); the registration was being done before the constructor of the Chrono was complete allowing incompletely constructed Chronos to be visible to other threads. A separate registerChrono method was added that is the last thing called in the subclasses constructor. There may be a better initialization sequence but it cannot involve recursion between the static initializers and the constructors. Happy Holidays, Roger From xueming.shen at oracle.com Sun Dec 23 21:34:02 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 23 Dec 2012 21:34:02 -0800 Subject: [threeten-dev] CaseInsensitive parsing Message-ID: <50D7E94A.4020307@oracle.com> Here is the case insensitive version of the prefix tree. http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTreeCI.java It holds performance relative good in -serve mode, about 2 x the case sensitive version (it's 6 x in -client vm) http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java I do have a combined version, but it slows down the case sensitive version about 20%. I'm not sure if we really case about this 20% in parsing. -Sherman From scolebourne at joda.org Mon Dec 24 04:21:51 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Dec 2012 12:21:51 +0000 Subject: [threeten-dev] CaseInsensitive parsing In-Reply-To: <50D7E94A.4020307@oracle.com> References: <50D7E94A.4020307@oracle.com> Message-ID: I think a single class that can handle cases sensitive and insensitive is probably best. Bytecode size and lack of duplication probably trumps absolute performance. I'm happy for you to integrate this and push if you want. Stephen On 24 December 2012 05:34, Xueming Shen wrote: > Here is the case insensitive version of the prefix tree. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTreeCI.java > > It holds performance relative good in -serve mode, about 2 x the case > sensitive > version (it's 6 x in -client vm) > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java > > I do have a combined version, but it slows down the case sensitive version > about 20%. > I'm not sure if we really case about this 20% in parsing. > > -Sherman From xueming.shen at oracle.com Mon Dec 24 19:47:44 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 24 Dec 2012 19:47:44 -0800 Subject: [threeten-dev] CaseInsensitive parsing In-Reply-To: References: <50D7E94A.4020307@oracle.com> Message-ID: <50D921E0.30106@oracle.com> Sure here is the version that supports both case sensitive and insensitive, by RadixTree rtree = RadixTree.newTree(); RadixTree rtree_ci = RadixTree.newTreeCI(); The 20% slow down happens only in -client mode, does not impact the -server vmd. Who cares -client these days :-) http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java (http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/Main.java is the test) -Sherman On 12/24/2012 4:21 AM, Stephen Colebourne wrote: > I think a single class that can handle cases sensitive and insensitive > is probably best. Bytecode size and lack of duplication probably > trumps absolute performance. > > I'm happy for you to integrate this and push if you want. > > Stephen > > On 24 December 2012 05:34, Xueming Shen wrote: >> Here is the case insensitive version of the prefix tree. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTreeCI.java >> >> It holds performance relative good in -serve mode, about 2 x the case >> sensitive >> version (it's 6 x in -client vm) >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java >> >> I do have a combined version, but it slows down the case sensitive version >> about 20%. >> I'm not sure if we really case about this 20% in parsing. >> >> -Sherman From scolebourne at joda.org Thu Dec 27 02:10:50 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Dec 2012 10:10:50 +0000 Subject: [threeten-dev] CaseInsensitive parsing In-Reply-To: <50D921E0.30106@oracle.com> References: <50D7E94A.4020307@oracle.com> <50D921E0.30106@oracle.com> Message-ID: Is the plan to add these as package-scoped classes? Does it need the ? I assume it will always be a string. Stephen On 25 December 2012 03:47, Xueming Shen wrote: > Sure here is the version that supports both case sensitive and insensitive, > by > > RadixTree rtree = RadixTree.newTree(); > RadixTree rtree_ci = RadixTree.newTreeCI(); > > The 20% slow down happens only in -client mode, does not impact the -server > vmd. Who cares -client these days :-) > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java > (http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/Main.java is > the test) > > -Sherman > > > On 12/24/2012 4:21 AM, Stephen Colebourne wrote: >> >> I think a single class that can handle cases sensitive and insensitive >> is probably best. Bytecode size and lack of duplication probably >> trumps absolute performance. >> >> I'm happy for you to integrate this and push if you want. >> >> Stephen >> >> On 24 December 2012 05:34, Xueming Shen wrote: >>> >>> Here is the case insensitive version of the prefix tree. >>> >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTreeCI.java >>> >>> It holds performance relative good in -serve mode, about 2 x the case >>> sensitive >>> version (it's 6 x in -client vm) >>> >>> >>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java >>> >>> I do have a combined version, but it slows down the case sensitive >>> version >>> about 20%. >>> I'm not sure if we really case about this 20% in parsing. >>> >>> -Sherman From scolebourne at joda.org Thu Dec 27 02:30:43 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 27 Dec 2012 10:30:43 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121227103156.15802473CD@hg.openjdk.java.net> Changeset: 8eacf951ee66 Author: scolebourne Date: 2012-12-22 23:04 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8eacf951ee66 Enhance Clock Javadoc/spec ! src/share/classes/javax/time/Clock.java Changeset: 3559d34411f8 Author: scolebourne Date: 2012-12-25 22:03 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3559d34411f8 Enhance test ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java From scolebourne at joda.org Thu Dec 27 02:43:07 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 27 Dec 2012 10:43:07 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix Clock test Message-ID: <20121227104318.BCFA2473CE@hg.openjdk.java.net> Changeset: b2bd523eea31 Author: scolebourne Date: 2012-12-27 10:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b2bd523eea31 Fix Clock test ! test/javax/time/tck/javax/time/TCKClock.java From scolebourne at joda.org Thu Dec 27 06:53:27 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Dec 2012 14:53:27 +0000 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: <50D4C625.1050601@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> <50D4C625.1050601@oracle.com> Message-ID: On 21 December 2012 20:27, Xueming Shen wrote: > How to define TemporalPeriod is not my point here, the methods I'm > adding in are to fit it for the minus/plus operation, as the TemporalField/ > Unit interface does. We definitely add more "general" access method > into it, as you just suggested. Consider this, if we do introduce the > TemporalPeriod later, does that make the TemporalAdder/Subtractor a > redundant? at least for all the functionality it currently trying to > provide? > then make the TemporalPeriod subclass of both Adder and Subtractor? Were there to be a TemporalPeriod (since it isn't a temporal, it should really be called something else, like Perioral), then it would not extend Adder/Subtractor. However, all *implementations* would extend TemporalPeriod, Adder and Subtractor. This is exactly the same as how LocalDate extends both Temporal and TemporalAdjuster, but Temporal and TemporalAdjuster are independent of one another. Different layers for different purposes. > Bottom line is why you need an extra Adder and Subtractor to stand > in the middle of Temporal = Temporal +/- TemporalDuration, when > we have a clear defintion of plus/minus, and we have two abstractions > clearly should/could know how to handle this well-defined operation. There are other possible classes that might wish to only implement adder/subtractor, and not be an entire period. The example in the javadoc is a method returning business/working days date.plus(workingDays(6)); The concept of "6 working days" is not a period, but it is a mechanism of addition. That is why Adder is different to the currently non-existing TemporalPeriod. Stephen From scolebourne at joda.org Thu Dec 27 06:58:54 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Dec 2012 14:58:54 +0000 Subject: [threeten-dev] Move tzdb compiler out of j.t.z In-Reply-To: <50D6BE4D.1040008@oracle.com> References: <50D6BE4D.1040008@oracle.com> Message-ID: On 23 December 2012 08:18, Xueming Shen wrote: > Here is the webrev for moving the tzdb compiler out of j.t.z package. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzc/ > > The approach here appears to cause a slower startup compared to the > existing one, as it uses ObjectOutput/InputStream directly to write out and > read in zrules, instead of the DateOutput/InputStream, in which the existing > impl can take advantage of the direct access to Ser to write out/read in > "byte[]" of the zrules, so the TzdbZoneRuleProvider can do lazy-init. The > compiler can't do it now because the Ser is package private. Is the slow down due to ObjectInputStream, or the lack of access to Ser? My preference would be to duplicate the logic from Ser into the builder (or possibly move it to a sun package helper class). More like plan B. Performance reading large tzdb files has been a problem in the past, which is why the format is structured as it is, and the loader carefully caches byte arrays. (Used to take over 30 seconds to start). It is important to test and ensure that a tzdb file with a large number of versions of the database also loads quickly (I'm aware that Oracle may not like this scenario, but the API supports historic versions and the tool should provide a mechanism to create a file that has those historic versions). Stephen > The plan-B is to externalize the Ser.write/read to somewhere, so the byte[] > of the zrules' serialization form can be shared by the tzdb compiler (output > side) and the tzdb provider (input side). Given we are talking about 600+ > zone (the rules number is bigger) and a total < 40k data here, I took the > simple, but slow, approach. We can revisit the start-up issue later, if it > indeed > is a concern. Let me know if you have concern of this approach, we can go > Plan-B. > > I brought back the test for the ZoneRulesBuilder, as promised. But it > appears > there is a test failure at line#805. I have not looked into the detail yet. > Just > wonder if you have any idea. > > The changes in ZoneRulesBuilder are to workaround the > beforeOffset==afterOffset issue. The old implementation creates the trans > even two offsets are the same (use that package private constructor which > does not do sanity check), but then throw it away. The code now does the > sanity check before creating the trans. > > -Sherman From xueming.shen at oracle.com Thu Dec 27 07:11:37 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 27 Dec 2012 10:11:37 -0500 Subject: [threeten-dev] CaseInsensitive parsing In-Reply-To: References: <50D7E94A.4020307@oracle.com> <50D921E0.30106@oracle.com> Message-ID: <50DC6529.2040401@oracle.com> It can be just used to replace the substringtree, not necessary a package-scoped. It started with the mostly because I'm not sure if we really need this "T", or if we can use it for other type of parsing here. For zoneid/text, it does not really need the T. I'm away this week, only have limited hour/minutes on computer. so probably can't get this done this week. -Sherman On 12/27/2012 5:10 AM, Stephen Colebourne wrote: > Is the plan to add these as package-scoped classes? > Does it need the? I assume it will always be a string. > > Stephen > > > On 25 December 2012 03:47, Xueming Shen wrote: >> Sure here is the version that supports both case sensitive and insensitive, >> by >> >> RadixTree rtree = RadixTree.newTree(); >> RadixTree rtree_ci = RadixTree.newTreeCI(); >> >> The 20% slow down happens only in -client mode, does not impact the -server >> vmd. Who cares -client these days :-) >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java >> (http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/Main.java is >> the test) >> >> -Sherman >> >> >> On 12/24/2012 4:21 AM, Stephen Colebourne wrote: >>> I think a single class that can handle cases sensitive and insensitive >>> is probably best. Bytecode size and lack of duplication probably >>> trumps absolute performance. >>> >>> I'm happy for you to integrate this and push if you want. >>> >>> Stephen >>> >>> On 24 December 2012 05:34, Xueming Shen wrote: >>>> Here is the case insensitive version of the prefix tree. >>>> >>>> >>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTreeCI.java >>>> >>>> It holds performance relative good in -serve mode, about 2 x the case >>>> sensitive >>>> version (it's 6 x in -client vm) >>>> >>>> >>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/radixtree_ci/RadixTree.java >>>> >>>> I do have a combined version, but it slows down the case sensitive >>>> version >>>> about 20%. >>>> I'm not sure if we really case about this 20% in parsing. >>>> >>>> -Sherman From xueming.shen at oracle.com Thu Dec 27 07:27:28 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 27 Dec 2012 10:27:28 -0500 Subject: [threeten-dev] [threeten-develop] Move tzdb compiler out of j.t.z In-Reply-To: References: <50D6BE4D.1040008@oracle.com> Message-ID: <50DC68E0.2040200@oracle.com> Due to the lack of access to ZoneRules' serialization form directly. The "form" is actually inside ZoneRules now. Outsourcing (the plan B) is an alternative. I guess the performance will be indeed a concern, if you actually have all the historical zone date inside one tzdb.jar. But I still don't understand why you want to do that:-) Given the nature of how the tzdb database is organized, all the historical data are all included in the latest version. I can guess, it may be useful, if you want to recover from an invalid zdt (created early with an earlier version of "latest" rules" at certain point, but do you really need such an "infrastructure" to support such kind of "rare" case. And given the current spec and impl of zdt, most developer should be happy to be able to recover simply from the ldt and offset info (based on what they really mean of "zdt" in their use case). We will go with plan B. -Sherman On 12/27/2012 9:58 AM, Stephen Colebourne wrote: > On 23 December 2012 08:18, Xueming Shen wrote: >> Here is the webrev for moving the tzdb compiler out of j.t.z package. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzc/ >> >> The approach here appears to cause a slower startup compared to the >> existing one, as it uses ObjectOutput/InputStream directly to write out and >> read in zrules, instead of the DateOutput/InputStream, in which the existing >> impl can take advantage of the direct access to Ser to write out/read in >> "byte[]" of the zrules, so the TzdbZoneRuleProvider can do lazy-init. The >> compiler can't do it now because the Ser is package private. > Is the slow down due to ObjectInputStream, or the lack of access to Ser? > > My preference would be to duplicate the logic from Ser into the > builder (or possibly move it to a sun package helper class). More like > plan B. > > Performance reading large tzdb files has been a problem in the past, > which is why the format is structured as it is, and the loader > carefully caches byte arrays. (Used to take over 30 seconds to start). > > It is important to test and ensure that a tzdb file with a large > number of versions of the database also loads quickly (I'm aware that > Oracle may not like this scenario, but the API supports historic > versions and the tool should provide a mechanism to create a file that > has those historic versions). > > Stephen > > >> The plan-B is to externalize the Ser.write/read to somewhere, so the byte[] >> of the zrules' serialization form can be shared by the tzdb compiler (output >> side) and the tzdb provider (input side). Given we are talking about 600+ >> zone (the rules number is bigger) and a total< 40k data here, I took the >> simple, but slow, approach. We can revisit the start-up issue later, if it >> indeed >> is a concern. Let me know if you have concern of this approach, we can go >> Plan-B. >> >> I brought back the test for the ZoneRulesBuilder, as promised. But it >> appears >> there is a test failure at line#805. I have not looked into the detail yet. >> Just >> wonder if you have any idea. >> >> The changes in ZoneRulesBuilder are to workaround the >> beforeOffset==afterOffset issue. The old implementation creates the trans >> even two offsets are the same (use that package private constructor which >> does not do sanity check), but then throw it away. The code now does the >> sanity check before creating the trans. >> >> -Sherman > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Thu Dec 27 09:14:17 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 27 Dec 2012 17:14:17 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20121227171517.98787473D6@hg.openjdk.java.net> Changeset: 404307e93c7d Author: scolebourne Date: 2012-12-27 11:28 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/404307e93c7d Replace TIME_PRECISION query by PRECISION No good reason to restrict this to time-only ! src/share/classes/javax/time/DayOfWeek.java ! src/share/classes/javax/time/Instant.java ! src/share/classes/javax/time/LocalTime.java ! src/share/classes/javax/time/Month.java ! src/share/classes/javax/time/calendar/HijrahEra.java ! src/share/classes/javax/time/calendar/MinguoEra.java ! src/share/classes/javax/time/calendar/ThaiBuddhistEra.java ! src/share/classes/javax/time/format/DateTimeBuilder.java ! src/share/classes/javax/time/temporal/ChronoLocalDate.java ! src/share/classes/javax/time/temporal/ChronoLocalDateTime.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTime.java ! src/share/classes/javax/time/temporal/Era.java ! src/share/classes/javax/time/temporal/ISOEra.java ! src/share/classes/javax/time/temporal/OffsetDate.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! src/share/classes/javax/time/temporal/OffsetTime.java ! src/share/classes/javax/time/temporal/TemporalAccessor.java ! src/share/classes/javax/time/temporal/TemporalQuery.java ! src/share/classes/javax/time/temporal/Year.java ! src/share/classes/javax/time/temporal/YearMonth.java ! test/javax/time/tck/javax/time/TCKDayOfWeek.java ! test/javax/time/tck/javax/time/TCKLocalDate.java ! test/javax/time/tck/javax/time/TCKLocalDateTime.java ! test/javax/time/tck/javax/time/TCKLocalTime.java ! test/javax/time/tck/javax/time/TCKMonth.java ! test/javax/time/tck/javax/time/TCKZoneOffset.java ! test/javax/time/tck/javax/time/TCKZonedDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDate.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetDateTime.java ! test/javax/time/tck/javax/time/temporal/TCKOffsetTime.java ! test/javax/time/test/javax/time/TestInstant.java Changeset: 842e70f93abd Author: scolebourne Date: 2012-12-27 11:42 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/842e70f93abd Enhance ZonedDateTime Javadoc ! src/share/classes/javax/time/ZonedDateTime.java Changeset: 5e11ddfd97d5 Author: scolebourne Date: 2012-12-27 15:09 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5e11ddfd97d5 Enhance formatter Javadoc ! src/share/classes/javax/time/format/DateTimeFormatter.java Changeset: 2851ef8dc13a Author: scolebourne Date: 2012-12-27 16:44 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2851ef8dc13a Add Chrono zoned instant based factory ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ChronoZonedDateTimeImpl.java ! src/share/classes/javax/time/temporal/ISOChrono.java From xueming.shen at oracle.com Thu Dec 27 21:08:42 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 28 Dec 2012 00:08:42 -0500 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> <50D4C625.1050601@oracle.com> Message-ID: <50DD295A.8020403@oracle.com> On 12/27/2012 9:53 AM, Stephen Colebourne wrote: > On 21 December 2012 20:27, Xueming Shen wrote: >> How to define TemporalPeriod is not my point here, the methods I'm >> adding in are to fit it for the minus/plus operation, as the TemporalField/ >> Unit interface does. We definitely add more "general" access method >> into it, as you just suggested. Consider this, if we do introduce the >> TemporalPeriod later, does that make the TemporalAdder/Subtractor a >> redundant? at least for all the functionality it currently trying to >> provide? >> then make the TemporalPeriod subclass of both Adder and Subtractor? > Were there to be a TemporalPeriod (since it isn't a temporal, it > should really be called something else, like Perioral), then it would > not extend Adder/Subtractor. However, all *implementations* would > extend TemporalPeriod, Adder and Subtractor. > > This is exactly the same as how LocalDate extends both Temporal and > TemporalAdjuster, but Temporal and TemporalAdjuster are independent of > one another. Different layers for different purposes. > >> Bottom line is why you need an extra Adder and Subtractor to stand >> in the middle of Temporal = Temporal +/- TemporalDuration, when >> we have a clear defintion of plus/minus, and we have two abstractions >> clearly should/could know how to handle this well-defined operation. > There are other possible classes that might wish to only implement > adder/subtractor, and not be an entire period. The example in the > javadoc is a method returning business/working days > > date.plus(workingDays(6)); > > The concept of "6 working days" is not a period, but it is a mechanism > of addition. That is why Adder is different to the currently > non-existing TemporalPeriod. > date.plus(workingDays(6)) cat be perfectly implemented as date.with(workingDaysAfter(6)), with the temporalAdjuster interface. The name might not be perfect, but I don't think it's a big concern. If you take a step back and look at these interfaces again, Temporal.plus(TemporalAdder) + TemporalAdder Temporal.minus(TemporalSubtractor) + TemporalSubtractor Temporal.with(TemporalAdjuster) + TemporalAdjuster are three exactly the same mechanisms, the only difference is the "wording" (even the wordings are similar), with the TemporalAdjuster as the most "general purpose" interface, by its name. What I'm questioning here is exactly the "different layers for different purposes" design on a simple abstraction. Do we really need two/three layers of abstraction here for "different purpose"? While to provide two more specific add & minus adjustment interfaces may bring some benefits, but it also adds the complicity to the interface, developers will have to deal with three different abstractions and different interfaces and have to figure out which one is "best" for what, while the reality is these three are exactly the same. We are talking about a "base" interface with 7 methods, and 3 of them are the "same thing" (again, they are just the "adjustment", one general, two specific). Let me try it again. time = time +/- duration -> temporal = temporal +/- temporalduratin(perioral?) temporal = temporal +/- tempralAddor/Subtractor(perioral) simply makes thing complicated with an extra layer, it'd be better leave those "addor/subtractor" to the adjuster. -Sherman From roger.riggs at oracle.com Fri Dec 28 09:06:54 2012 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 28 Dec 2012 17:06:54 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets Message-ID: <20121228171048.3AB1147423@hg.openjdk.java.net> Changeset: edeb7f93729d Author: rriggs Date: 2012-12-20 15:06 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/edeb7f93729d refactor HijrahDate, HijrahChrono to allow multiple Hijrah Chronologies; factored out file reader ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDate.java + src/share/classes/javax/time/calendar/HijrahDeviationReader.java ! src/share/classes/javax/time/calendar/Ser.java Changeset: 45bba6d450f3 Author: rriggs Date: 2012-12-20 15:55 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/45bba6d450f3 Convert Integer arrays to int arrays ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDate.java Changeset: f25442d628b7 Author: rriggs Date: 2012-12-21 11:24 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f25442d628b7 cleanup manual array copies and unnecessary use of new Integer() ! src/share/classes/javax/time/calendar/HijrahChrono.java Changeset: 91d2c89b35e2 Author: rriggs Date: 2012-12-23 17:28 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/91d2c89b35e2 Refactored readDeviations to be per Hijrah calendar. The registration of each calendar must be the last action of the constructor to make sure even in a multi-thread race condition that the Chrono is completely initialized before it is visible to another thread. During the initialization of the Hijrah calendar a system property is consulted to see if additional Hijrah calendars are to be created. Deviation data is read for each Hijrah calendar is initialized found using a default location and system properties to override. ! src/share/classes/javax/time/calendar/HijrahChrono.java ! src/share/classes/javax/time/calendar/HijrahDeviationReader.java ! src/share/classes/javax/time/calendar/JapaneseChrono.java ! src/share/classes/javax/time/calendar/MinguoChrono.java ! src/share/classes/javax/time/calendar/ThaiBuddhistChrono.java ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ISOChrono.java Changeset: fb1347c963e3 Author: rriggs Date: 2012-12-28 11:56 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fb1347c963e3 Merge ! src/share/classes/javax/time/temporal/Chrono.java ! src/share/classes/javax/time/temporal/ISOChrono.java - src/share/classes/javax/time/temporal/JulianDayField.java - src/share/classes/javax/time/temporal/WeekDefinition.java - src/share/classes/javax/time/zone/StandardZoneRules.java - test/javax/time/tck/javax/time/temporal/TCKJulianDayField.java - test/javax/time/tck/javax/time/temporal/TCKWeekDefinition.java - test/javax/time/test/javax/time/zone/TestStandardZoneRules.java From scolebourne at joda.org Fri Dec 28 16:10:54 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sat, 29 Dec 2012 00:10:54 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20121229001151.76A594743A@hg.openjdk.java.net> Changeset: a810a4c37fec Author: scolebourne Date: 2012-12-27 23:24 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a810a4c37fec Add support to override chrono and zone for printing See #21 and #25 ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimePrintContext.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatter.java Changeset: 01ab8b644072 Author: scolebourne Date: 2012-12-28 23:27 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/01ab8b644072 Enhance formatter builder Javadoc ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java Changeset: 83bb087ddec1 Author: scolebourne Date: 2012-12-29 00:02 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/83bb087ddec1 Add appendZoneOrOffsetId() ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java Changeset: 9e782eceb0cb Author: scolebourne Date: 2012-12-29 00:08 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9e782eceb0cb Merge From scolebourne at joda.org Sat Dec 29 05:44:37 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sat, 29 Dec 2012 13:44:37 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20121229134534.A6A334744A@hg.openjdk.java.net> Changeset: 3373687943ac Author: scolebourne Date: 2012-12-29 12:07 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3373687943ac Enhance implementation of ZoneId output to only use query ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java Changeset: 4b2750a1b9ea Author: scolebourne Date: 2012-12-29 12:48 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4b2750a1b9ea Enhance offset ID implementation; Simplify parse context ! src/share/classes/javax/time/format/DateTimeFormatter.java ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java ! src/share/classes/javax/time/format/DateTimeParseContext.java ! test/javax/time/tck/javax/time/format/TCKDateTimeFormatterBuilder.java From Roger.Riggs at oracle.com Mon Dec 31 06:22:11 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 31 Dec 2012 09:22:11 -0500 Subject: [threeten-dev] [threeten-develop] Supported range for the Instant class In-Reply-To: References: Message-ID: <50E19F93.8060800@oracle.com> Makes sense to me. Fewer special cases and more consistent across the API. I don't think the JDK is designed/intended specifically to handle scientific computing and even the range of LocalDate is unnecessarily large. For serious scientific computations a full library would handle the larger range. On 12/31/2012 8:59 AM, Stephen Colebourne wrote: > All, > I am considering reducing the supported range of Instant > > The original plan and code supports a range for Instant of the number > of seconds that can be stored in a Java long. This was partly chosen > to exceed the estimated age of the universe. Whereas the maximum range > for LocalDate is just under 1bn years, controlled by the 2bn size of a > Java int. > > Maximum Instant = ~292bn years > Age of universe = ~13.6bn years > Maximum LocalDate = 1bn years (999,999,999 years) > > The change I am considering is to make the mximum range of an Instant > match that of LocalDate. > > The key negative is that it is no longer possible to represent all > instants within the age of the universe. But frankly, storing a far, > far point in the past to nanosecond precision from 1970-01-01 seems > wrong anyway. Astronomers would prefer to use some kind of BigYear > class I suspect. > > Positives include > - Duration.between never throws an exception (the duration between any > two instants will never exceed the range of a duration) > - No range errors when converting from an Instant to a ZonedDateTime > - Printing/parsing instants is much simpler (due to previous point) > - Fewer special/edge cases in general > - There is one less conceptual min/max in the API > > As a side note, this change makes more sense now than it used to as we > have fully integrated Instant into the Temporal hierarchy. > > thoughts/objections? > Stephen > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at oracle.com Mon Dec 31 09:01:45 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 31 Dec 2012 12:01:45 -0500 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: <50DD295A.8020403@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> <50D4C625.1050601@oracle.com> <50DD295A.8020403@oracle.com> Message-ID: <50E1C4F9.4030209@oracle.com> The nomenclature needs to be cleaned up and the types for Duration, Period, and SimplePeriod would benefit from a unifying type (class or interface). The Temporal type defines methods minus and plus whose arguments should be relative temporal values. But the current types and agument names are functional and are inconsistent with the method names plus and minus. Duration and Period are very similar, both are relative times and need to be to be applied to Temporal entities to be useful, they differ in the representation for times greater than 24 hours. A common (super) type defining methods would tie them together: - T addTo(T), - T subtractFrom(T), - isNegative, isPositive, isZero, - minus(n, Unit), plus(n, Unit) TemporalPeriod is a fine name, since we've established that temporal relates to anything about time. And perhaps to connect the operations between absolute temporal values and relative temporal values together better, the Temporal periodUntil(T, T) should return a SimplePeriod. (Though separately, SimplePeriod could be subsumed into Period). The api already has the Adjuster interface to encapsulate arbitrary functions on TA's; using it for computing offsets from TAs will avoid confusing definitions of Duration or Period/SimplePeriod which are fixed values derived from other periods. Roger On 12/28/2012 12:08 AM, Xueming Shen wrote: > On 12/27/2012 9:53 AM, Stephen Colebourne wrote: >> On 21 December 2012 20:27, Xueming Shen wrote: >>> How to define TemporalPeriod is not my point here, the methods I'm >>> adding in are to fit it for the minus/plus operation, as the >>> TemporalField/ >>> Unit interface does. We definitely add more "general" access method >>> into it, as you just suggested. Consider this, if we do introduce the >>> TemporalPeriod later, does that make the TemporalAdder/Subtractor a >>> redundant? at least for all the functionality it currently trying to >>> provide? >>> then make the TemporalPeriod subclass of both Adder and Subtractor? >> Were there to be a TemporalPeriod (since it isn't a temporal, it >> should really be called something else, like Perioral), then it would >> not extend Adder/Subtractor. However, all *implementations* would >> extend TemporalPeriod, Adder and Subtractor. >> >> This is exactly the same as how LocalDate extends both Temporal and >> TemporalAdjuster, but Temporal and TemporalAdjuster are independent of >> one another. Different layers for different purposes. >> >>> Bottom line is why you need an extra Adder and Subtractor to stand >>> in the middle of Temporal = Temporal +/- TemporalDuration, when >>> we have a clear defintion of plus/minus, and we have two abstractions >>> clearly should/could know how to handle this well-defined operation. >> There are other possible classes that might wish to only implement >> adder/subtractor, and not be an entire period. The example in the >> javadoc is a method returning business/working days >> >> date.plus(workingDays(6)); >> >> The concept of "6 working days" is not a period, but it is a mechanism >> of addition. That is why Adder is different to the currently >> non-existing TemporalPeriod. >> > > date.plus(workingDays(6)) cat be perfectly implemented as > date.with(workingDaysAfter(6)), with the temporalAdjuster interface. > The name > might not be perfect, but I don't think it's a big concern. > > If you take a step back and look at these interfaces again, > > Temporal.plus(TemporalAdder) + TemporalAdder > Temporal.minus(TemporalSubtractor) + TemporalSubtractor > Temporal.with(TemporalAdjuster) + TemporalAdjuster > > are three exactly the same mechanisms, the only difference is the > "wording" > (even the wordings are similar), with the TemporalAdjuster as the most > "general > purpose" interface, by its name. > > What I'm questioning here is exactly the "different layers for > different purposes" > design on a simple abstraction. Do we really need two/three layers of > abstraction > here for "different purpose"? While to provide two more specific add & > minus > adjustment interfaces may bring some benefits, but it also adds the > complicity > to the interface, developers will have to deal with three different > abstractions > and different interfaces and have to figure out which one is "best" > for what, > while the reality is these three are exactly the same. We are talking > about a > "base" interface with 7 methods, and 3 of them are the "same thing" > (again, > they are just the "adjustment", one general, two specific). > > Let me try it again. > > time = time +/- duration -> temporal = temporal +/- > temporalduratin(perioral?) > > temporal = temporal +/- tempralAddor/Subtractor(perioral) > > simply makes thing complicated with an extra layer, it'd be better > leave those > "addor/subtractor" to the adjuster. > > -Sherman > > > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From scolebourne at joda.org Mon Dec 31 13:21:16 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 31 Dec 2012 21:21:16 +0000 Subject: [threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor In-Reply-To: <50E1C4F9.4030209@oracle.com> References: <50D0F7D4.5010906@oracle.com> <50D113CC.3090806@oracle.com> <50D2205D.4040502@oracle.com> <50D415AC.4020209@oracle.com> <50D4C625.1050601@oracle.com> <50DD295A.8020403@oracle.com> <50E1C4F9.4030209@oracle.com> Message-ID: Ultimately, this is a question of what abstractions make sense vs what abstractions are needed. Everyone agrees that a TemporalPeriod abstraction over all period-like things makes sense. I haven't included this so far as there is no period formatting, thus no need for the interface. This also means that there is no code to test that the interface contains the right set of methods, something that I find concerning (unless someone is volunteering to write a period formatter). The Adder/Subtractor interfaces are simple concepts that extend a pattern we know works in adjuster. It makes a simple pattern complete - each of get/set/plus/minus has a dedicated "primitive" method and a dedicated "functional interface" method (Query/Adjuster/Adder/Subtractor). Breaking this simple pattern also has risks. Set against this is the element of duplication. The functionality of an Adder/Subtractor can be successfully provided by an adjuster. However, doing that results in (a) worse method names/fluency - with(workingDaysAdded(6)) - and (b) duplicated adjuster implementations - with(workingDaysAdded()) and with(workingDaysSubtracted()). Removing Adder/Subtractor in favour of adjusters also requires that we add a TemporalPeriod interface, so as to ensure that sensible code like date.plus(period) still works. At this point, I am willing to consider the change, however I am *very* concerned that we will not get the correct set of TemporalPeriod methods. I also note that if we make this change, then Adder/Subtractor will not be able to return in a future JDK (due to method overloading issues), so this is a one-shot deal. Proposals welcome on how we can prove the set of methods on TemporalPeriod. Are we willing to prototype a period formatter? Should the access be like Temporal (isSupported/get/getLong), or the return of a Map object? Are the isPositive/isNegative etc methods needed? Is the interface intended for users (more methods) or frameworks (less methods)? Stephen On 31 December 2012 17:01, Roger Riggs wrote: > The nomenclature needs to be cleaned up and the types for Duration, Period, > and SimplePeriod would benefit from a unifying type (class or interface). > > The Temporal type defines methods minus and plus whose arguments should > be relative temporal values. But the current types and agument names are > functional and are inconsistent with the method names plus and minus. > > Duration and Period are very similar, both are relative times and need to be > to be applied to Temporal entities to be useful, they differ in the > representation > for times greater than 24 hours. > > A common (super) type defining methods would tie them together: > - T addTo(T), > - T subtractFrom(T), > - isNegative, isPositive, isZero, > - minus(n, Unit), plus(n, Unit) > > TemporalPeriod is a fine name, since we've established that temporal > relates to anything about time. > > And perhaps to connect the operations between absolute temporal values > and relative temporal values together better, the Temporal periodUntil(T, T) > should return a SimplePeriod. (Though separately, SimplePeriod could be > subsumed into Period). > > The api already has the Adjuster interface to encapsulate arbitrary > functions on TA's; > using it for computing offsets from TAs will avoid confusing definitions of > Duration > or Period/SimplePeriod which are fixed values derived from other periods. > > Roger > > > > > > On 12/28/2012 12:08 AM, Xueming Shen wrote: >> >> On 12/27/2012 9:53 AM, Stephen Colebourne wrote: >>> >>> On 21 December 2012 20:27, Xueming Shen wrote: >>>> >>>> How to define TemporalPeriod is not my point here, the methods I'm >>>> adding in are to fit it for the minus/plus operation, as the >>>> TemporalField/ >>>> Unit interface does. We definitely add more "general" access method >>>> into it, as you just suggested. Consider this, if we do introduce the >>>> TemporalPeriod later, does that make the TemporalAdder/Subtractor a >>>> redundant? at least for all the functionality it currently trying to >>>> provide? >>>> then make the TemporalPeriod subclass of both Adder and Subtractor? >>> >>> Were there to be a TemporalPeriod (since it isn't a temporal, it >>> should really be called something else, like Perioral), then it would >>> not extend Adder/Subtractor. However, all *implementations* would >>> extend TemporalPeriod, Adder and Subtractor. >>> >>> This is exactly the same as how LocalDate extends both Temporal and >>> TemporalAdjuster, but Temporal and TemporalAdjuster are independent of >>> one another. Different layers for different purposes. >>> >>>> Bottom line is why you need an extra Adder and Subtractor to stand >>>> in the middle of Temporal = Temporal +/- TemporalDuration, when >>>> we have a clear defintion of plus/minus, and we have two abstractions >>>> clearly should/could know how to handle this well-defined operation. >>> >>> There are other possible classes that might wish to only implement >>> adder/subtractor, and not be an entire period. The example in the >>> javadoc is a method returning business/working days >>> >>> date.plus(workingDays(6)); >>> >>> The concept of "6 working days" is not a period, but it is a mechanism >>> of addition. That is why Adder is different to the currently >>> non-existing TemporalPeriod. >>> >> >> date.plus(workingDays(6)) cat be perfectly implemented as >> date.with(workingDaysAfter(6)), with the temporalAdjuster interface. The >> name >> might not be perfect, but I don't think it's a big concern. >> >> If you take a step back and look at these interfaces again, >> >> Temporal.plus(TemporalAdder) + TemporalAdder >> Temporal.minus(TemporalSubtractor) + TemporalSubtractor >> Temporal.with(TemporalAdjuster) + TemporalAdjuster >> >> are three exactly the same mechanisms, the only difference is the >> "wording" >> (even the wordings are similar), with the TemporalAdjuster as the most >> "general >> purpose" interface, by its name. >> >> What I'm questioning here is exactly the "different layers for different >> purposes" >> design on a simple abstraction. Do we really need two/three layers of >> abstraction >> here for "different purpose"? While to provide two more specific add & >> minus >> adjustment interfaces may bring some benefits, but it also adds the >> complicity >> to the interface, developers will have to deal with three different >> abstractions >> and different interfaces and have to figure out which one is "best" for >> what, >> while the reality is these three are exactly the same. We are talking >> about a >> "base" interface with 7 methods, and 3 of them are the "same thing" >> (again, >> they are just the "adjustment", one general, two specific). >> >> Let me try it again. >> >> time = time +/- duration -> temporal = temporal +/- >> temporalduratin(perioral?) >> >> temporal = temporal +/- tempralAddor/Subtractor(perioral) >> >> simply makes thing complicated with an extra layer, it'd be better leave >> those >> "addor/subtractor" to the adjuster. >> >> -Sherman >> >> >> > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From scolebourne at joda.org Mon Dec 31 14:45:13 2012 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 31 Dec 2012 22:45:13 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20121231224556.C205447483@hg.openjdk.java.net> Changeset: cdf0db2ca58c Author: scolebourne Date: 2012-12-31 21:46 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cdf0db2ca58c Remove unecessary checks in fraction formatter ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java Changeset: db38e7304051 Author: scolebourne Date: 2012-12-31 22:37 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/db38e7304051 Add TCK Instant test ! src/share/classes/javax/time/format/DateTimeFormatterBuilder.java + test/javax/time/tck/javax/time/TCKInstant.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java - test/javax/time/test/javax/time/TestInstant.java Changeset: 87e4dcd2f31c Author: scolebourne Date: 2012-12-31 22:44 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/87e4dcd2f31c Re-enable temporal tests and fix bugs ! src/share/classes/javax/time/ZonedDateTime.java ! src/share/classes/javax/time/temporal/OffsetDateTime.java ! test/javax/time/test/javax/time/AbstractDateTimeTest.java