Thread: [threeten-develop] JSR 310 Final Release Materials and Review
Status: Alpha
Brought to you by:
scolebourne
From: Roger R. <Roger.Riggs@Oracle.com> - 2014-01-17 21:42:49
|
Hi, Please review the Final Release Specification <http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip> (zip)[1] and materials. Updates to the specification since PFD: * 8031103 <https://bugs.openjdk.java.net/browse/JDK-8031103>: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() * The SE 8 javadoc has been used to generate the specification so its appearance is a bit different The code coverage is ~93% using jcov and is considered adequate. The RI and TCK are the same as for SE 8; since the development of the APIs and tests has been done via OpenJDK and earlier open source projects their contents are will known. The RI and TCK are being made available to official Expert Group members for review under a separate email. The FAB submission to the PMO is planned for 1/29. Please give your approval to proceed with the Final Release or raise any issues by Friday Jan 24th. Thanks, Roger [1] http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip |
From: Michel G. <mic...@gm...> - 2014-01-18 17:42:46
|
Roger, looks like to me there is a typo for j.u.Date related to JSR 310. Method: http://download.java.net/jdk8/docs/api/java/util/Date.html#from-java.time.Instant- Typo: "The conversion will *trancate* any excess" looks to me here should be 'truncate'. Hope it helps. On Fri, Jan 17, 2014 at 7:42 PM, Roger Riggs <Rog...@or...> wrote: > Hi, > > Please review the Final Release Specification<http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>(zip)[1] and materials. > > Updates to the specification since PFD: > > - 8031103 <https://bugs.openjdk.java.net/browse/JDK-8031103>: > java.time.Duration has wrong Javadoc Comments in toDays() and toHours() > - The SE 8 javadoc has been used to generate the specification so its > appearance is a bit different > > > The code coverage is ~93% using jcov and is considered adequate. > > The RI and TCK are the same as for SE 8; since the development of the APIs > and tests has been done via OpenJDK and earlier open source projects > their contents are will known. > > The RI and TCK are being made available to official Expert Group members > for review > under a separate email. > > The FAB submission to the PMO is planned for 1/29. > > Please give your approval to proceed with the Final Release or raise any > issues > by Friday Jan 24th. > > Thanks, Roger > > [1] http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > -- Michel Graciano http://www.michelgraciano.com.br http://java.net/projects/genesis http://java.net/projects/copypastehistory |
From: roger r. <rog...@or...> - 2014-01-18 18:50:58
|
Thanks, Filed a bug 8032221 <https://bugs.openjdk.java.net/browse/JDK-8032221>to track it. Roger On 1/18/2014 12:42 PM, Michel Graciano wrote: > Roger, > looks like to me there is a typo for j.u.Date related to JSR 310. > > Method: > http://download.java.net/jdk8/docs/api/java/util/Date.html#from-java.time.Instant- > > Typo: > "The conversion will *trancate* any excess" looks to me here should be > 'truncate'. > > Hope it helps. > |
From: Douglas S. <dou...@or...> - 2014-01-22 21:25:02
|
The JavaDoc for Instant.MAX says >The maximum supported Instant, >'1000000000-12-31T23:59:59.999999999Z'. and for Instant.MIN says >The minimum supported Instant, '-1000000000-01-01T00:00Z'. This is +/- 1 * 10^9 years which conflicts with the Instant class description which says: >The measurable time-line is restricted to the number of seconds that >can be held in a long. This is greater than the current estimated >age of the universe. Long.MAX_VALUE number of seconds is more than +/- 292 * 10^9 years and the universe is 13.7 * 10^9 years old. Given the class description it seems incorrect that Instant.MAX.compareTo(Instant.ofEpochSeconds(Long.MAX_VALUE)) returns -1. As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? Douglas At 01:42 PM 1/17/2014, Roger Riggs wrote: >Hi, > >Please review the ><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >Release Specification (zip)[1] and materials. > >Updates to the specification since PFD: > * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: > java.time.Duration has wrong Javadoc Comments in toDays() and > toHours() > * The SE 8 javadoc has been used to generate the specification > so its appearance is a bit different > >The code coverage is ~93% using jcov and is considered adequate. > >The RI and TCK are the same as for SE 8; since the development of >the APIs >and tests has been done via OpenJDK and earlier open source projects >their contents are will known. > >The RI and TCK are being made available to official Expert Group >members for review >under a separate email. > >The FAB submission to the PMO is planned for 1/29. > >Please give your approval to proceed with the Final Release or raise >any issues >by Friday Jan 24th. > >Thanks, Roger > >[1] ><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip > >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In >Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > >_______________________________________________ >threeten-develop mailing list >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2014-01-23 07:03:41
|
On 22 January 2014 21:24, Douglas Surber <dou...@or...> wrote: > The JavaDoc for Instant.MAX says >>The maximum supported Instant, >>'1000000000-12-31T23:59:59.999999999Z'. > and for Instant.MIN says >>The minimum supported Instant, '-1000000000-01-01T00:00Z'. > This is +/- 1 * 10^9 years which conflicts with the Instant class > description which says: > >>The measurable time-line is restricted to the number of seconds that >>can be held in a long. This is greater than the current estimated >>age of the universe. The size of Instant was reduced to ensure that calculations returned correct numbers. This occurred when Instant was integrated with ZDT etc under the common Temporal interfaces. The two paragraphs above are now a spec error and should be removed. > Long.MAX_VALUE number of seconds is more than +/- 292 * 10^9 years > and the universe is 13.7 * 10^9 years old. > > Given the class description it seems incorrect that > > Instant.MAX.compareTo(Instant.ofEpochSeconds(Long.MAX_VALUE)) > returns -1. Instant.ofEpochSeconds(Long.MAX_VALUE) should throw an exception. Bug if it doesn't. > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? The java.lang.Integer class uses MAX_VALUE to return the equivalent primitive value. ie. Integer.MAX_VALUE returns an int not an Integer. With 310, there is no separate value type, so I used MAX. Stephen > Douglas > > At 01:42 PM 1/17/2014, Roger Riggs wrote: >>Hi, >> >>Please review the >><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >>Release Specification (zip)[1] and materials. >> >>Updates to the specification since PFD: >> * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: >> java.time.Duration has wrong Javadoc Comments in toDays() and >> toHours() >> * The SE 8 javadoc has been used to generate the specification >> so its appearance is a bit different >> >>The code coverage is ~93% using jcov and is considered adequate. >> >>The RI and TCK are the same as for SE 8; since the development of >>the APIs >>and tests has been done via OpenJDK and earlier open source projects >>their contents are will known. >> >>The RI and TCK are being made available to official Expert Group >>members for review >>under a separate email. >> >>The FAB submission to the PMO is planned for 1/29. >> >>Please give your approval to proceed with the Final Release or raise >>any issues >>by Friday Jan 24th. >> >>Thanks, Roger >> >>[1] >><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip >> >>------------------------------------------------------------------------------ >>CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>Learn Why More Businesses Are Choosing CenturyLink Cloud For >>Critical Workloads, Development Environments & Everything In >>Between. >>Get a Quote or Start a Free Trial Today. >>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> >>_______________________________________________ >>threeten-develop mailing list >>thr...@li... >>https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Douglas S. <dou...@or...> - 2014-01-22 22:25:59
|
Duration.dividedBy(Duration) is missing. This is needed to determine the number of times a Duration occurs within another Duration, such has how many 12 minute periods in 4 hours. Stephen agreed that this was a good thing Jan 10, 2009. Douglas At 01:42 PM 1/17/2014, Roger Riggs wrote: >Hi, > >Please review the ><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >Release Specification (zip)[1] and materials. > >Updates to the specification since PFD: > * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: > java.time.Duration has wrong Javadoc Comments in toDays() and > toHours() > * The SE 8 javadoc has been used to generate the specification > so its appearance is a bit different > >The code coverage is ~93% using jcov and is considered adequate. > >The RI and TCK are the same as for SE 8; since the development of >the APIs >and tests has been done via OpenJDK and earlier open source projects >their contents are will known. > >The RI and TCK are being made available to official Expert Group >members for review >under a separate email. > >The FAB submission to the PMO is planned for 1/29. > >Please give your approval to proceed with the Final Release or raise >any issues >by Friday Jan 24th. > >Thanks, Roger > >[1] ><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip > >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In >Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > >_______________________________________________ >threeten-develop mailing list >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: roger r. <rog...@or...> - 2014-01-22 22:55:22
|
Hi Douglas, I filed https://bugs.openjdk.java.net/browse/JDK-8032510 to keep track of this for a future version. Thanks, Roger On 1/22/2014 5:25 PM, Douglas Surber wrote: > Duration.dividedBy(Duration) is missing. This is needed to determine > the number of times a Duration occurs within another Duration, such > has how many 12 minute periods in 4 hours. Stephen agreed that this > was a good thing Jan 10, 2009. > > Douglas > |
From: Douglas S. <dou...@or...> - 2014-01-23 15:59:51
|
At 11:03 PM 1/22/2014, Stephen Colebourne wrote: > > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used > elsewhere? > >The java.lang.Integer class uses MAX_VALUE to return the equivalent >primitive value. ie. Integer.MAX_VALUE returns an int not an >Integer. >With 310, there is no separate value type, so I used MAX. java.time.Year uses MAX_VALUE and MIN_VALUE. I think the distinction is too subtle for me. I would just type MAX_VALUE because that is the name of the constant that defines the largest element in the range, regardless of Object or primitive. Douglas |
From: Stephen C. <sco...@jo...> - 2014-01-23 16:18:49
|
On 23 January 2014 15:59, Douglas Surber <dou...@or...> wrote: > At 11:03 PM 1/22/2014, Stephen Colebourne wrote: >> >> > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? >> >> The java.lang.Integer class uses MAX_VALUE to return the equivalent >> primitive value. ie. Integer.MAX_VALUE returns an int not an Integer. >> With 310, there is no separate value type, so I used MAX. > > java.time.Year uses MAX_VALUE and MIN_VALUE. Because it returns int, not Year. > I think the distinction is too subtle for me. I would just type MAX_VALUE > because that is the name of the constant that defines the largest element in > the range, regardless of Object or primitive. I'm happy with the choice I made here. Its up to Roger/Sherman to comment otherwise. Stephen |