threeten-develop Mailing List for threeten (Page 4)
Status: Alpha
Brought to you by:
scolebourne
You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(15) |
Feb
|
Mar
(22) |
Apr
(4) |
May
(2) |
Jun
(6) |
Jul
(14) |
Aug
|
Sep
(18) |
Oct
(64) |
Nov
(10) |
Dec
(22) |
2012 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(38) |
May
(98) |
Jun
(71) |
Jul
(47) |
Aug
(33) |
Sep
(45) |
Oct
(77) |
Nov
(32) |
Dec
(251) |
2013 |
Jan
(112) |
Feb
(76) |
Mar
(41) |
Apr
(18) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(7) |
2014 |
Jan
(15) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(5) |
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: roger r. <rog...@or...> - 2013-03-08 18:34:54
|
Hi Stephen, The description of the default implementation is redundant with the requirements described in the exceptions and is unnecessary. Roger On 3/7/2013 5:11 AM, Stephen Colebourne wrote: > The Javadoc in TemporalAccessor still needs fixing: > > * Implementations must not alter either this object. > * <p> > * The default implementation must behave equivalent to this code: > * <pre> > * return range(field).checkValidIntValue(getLong(field), field); > > The first line is a typo. The second part describes the default > implementation, and thus needs adjusting to match the new > implementation. > > Stephen > > > > On 6 March 2013 21:27, roger riggs <rog...@or...> wrote: >> Reverted the javadoc for @inheritDoc; the overridden methods all have >> the same @throws clauses. >> >> Updated webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> >> Roger >> >> >> >> On 3/6/2013 3:58 AM, Stephen Colebourne wrote: >> >> I hate the inheritDoc change. Is it done this way anywhere else in the >> JDK (I don't think so). While I accept it may be easier for >> maintainers, it is far worse for most developers who are just reading >> the Javadoc as source code (having hit F3 in Eclipse to jump to the >> source code of the method they are working with). While the HTML tool >> can hunt down the inheritDoc, regular users cannot. >> >> The inlined code looks OK, however the Javadoc of the method is now >> wrong as it specifies the implementation. >> >> thanks >> Stephen >> >> >> On 5 March 2013 16:16, roger riggs <rog...@or...> wrote: >> >> Hi, >> >> Makes sense. >> >> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. >> The @throws clauses were slightly out of alignment with >> TemporalAccessor.get. >> To make it simplier to maintain the implementers now use {@inheritDoc}. >> The ValueRange.checkValidIntValue exception message is updated to more >> informative. >> >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ >> >> Thanks, Roger >> >> On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >> >> I don't think this change can go in. >> >> The checkValidValue methods are public, and so can be called by anyone >> at any time in any way. The UTTE is intended for use when the Field or >> Unit passed in is unsupported by the target object. In these methods, >> the field is optional, and supported/not-supported is not a quality of >> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >> >> A correct fix would be to inline the code change into TemporalAccesor >> and anywhere else that has a similar use of the check method. If it is >> widely used, a package scoped method (in an appropriate location) may >> be a solution. >> >> thanks >> Stephen >> >> >> >> On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: >> >> Hi, >> >> A simple fix for the exception and message when TemporalAccessor.get() >> is used (incorrectly) to retrieve Fields with long values. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> >> Thanks, Roger >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> >> ------------------------------------------------------------------------------ >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Oracle is committed to developing practices and products that help protect >> the environment >> >> >> >> ------------------------------------------------------------------------------ >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |
From: Stephen C. <sco...@jo...> - 2013-03-07 10:12:20
|
The Javadoc in TemporalAccessor still needs fixing: * Implementations must not alter either this object. * <p> * The default implementation must behave equivalent to this code: * <pre> * return range(field).checkValidIntValue(getLong(field), field); The first line is a typo. The second part describes the default implementation, and thus needs adjusting to match the new implementation. Stephen On 6 March 2013 21:27, roger riggs <rog...@or...> wrote: > Reverted the javadoc for @inheritDoc; the overridden methods all have > the same @throws clauses. > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > > Roger > > > > On 3/6/2013 3:58 AM, Stephen Colebourne wrote: > > I hate the inheritDoc change. Is it done this way anywhere else in the > JDK (I don't think so). While I accept it may be easier for > maintainers, it is far worse for most developers who are just reading > the Javadoc as source code (having hit F3 in Eclipse to jump to the > source code of the method they are working with). While the HTML tool > can hunt down the inheritDoc, regular users cannot. > > The inlined code looks OK, however the Javadoc of the method is now > wrong as it specifies the implementation. > > thanks > Stephen > > > On 5 March 2013 16:16, roger riggs <rog...@or...> wrote: > > Hi, > > Makes sense. > > I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. > The @throws clauses were slightly out of alignment with > TemporalAccessor.get. > To make it simplier to maintain the implementers now use {@inheritDoc}. > The ValueRange.checkValidIntValue exception message is updated to more > informative. > > Updated webrev: > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ > > Thanks, Roger > > On 3/5/2013 8:49 AM, Stephen Colebourne wrote: > > I don't think this change can go in. > > The checkValidValue methods are public, and so can be called by anyone > at any time in any way. The UTTE is intended for use when the Field or > Unit passed in is unsupported by the target object. In these methods, > the field is optional, and supported/not-supported is not a quality of > the ValueRange class. Thus UTTE is just plain wrong to be thrown here. > > A correct fix would be to inline the code change into TemporalAccesor > and anywhere else that has a similar use of the check method. If it is > widely used, a package scoped method (in an appropriate location) may > be a solution. > > thanks > Stephen > > > > On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: > > Hi, > > A simple fix for the exception and message when TemporalAccessor.get() > is used (incorrectly) to retrieve Fields with long values. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > > Thanks, Roger > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > -- > Thanks, Roger > > Oracle Java Platform Group > > Oracle is committed to developing practices and products that help protect > the environment > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: roger r. <rog...@or...> - 2013-03-06 21:28:09
|
Hi, Reverted the javadoc for @inheritDoc; the overridden methods all have the same @throws clauses. Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ Roger On 3/6/2013 3:58 AM, Stephen Colebourne wrote: > I hate the inheritDoc change. Is it done this way anywhere else in the > JDK (I don't think so). While I accept it may be easier for > maintainers, it is far worse for most developers who are just reading > the Javadoc as source code (having hit F3 in Eclipse to jump to the > source code of the method they are working with). While the HTML tool > can hunt down the inheritDoc, regular users cannot. > > The inlined code looks OK, however the Javadoc of the method is now > wrong as it specifies the implementation. > > thanks > Stephen > > > On 5 March 2013 16:16, roger riggs <rog...@or...> wrote: >> Hi, >> >> Makes sense. >> >> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. >> The @throws clauses were slightly out of alignment with >> TemporalAccessor.get. >> To make it simplier to maintain the implementers now use {@inheritDoc}. >> The ValueRange.checkValidIntValue exception message is updated to more >> informative. >> >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ >> >> Thanks, Roger >> >> On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >>> I don't think this change can go in. >>> >>> The checkValidValue methods are public, and so can be called by anyone >>> at any time in any way. The UTTE is intended for use when the Field or >>> Unit passed in is unsupported by the target object. In these methods, >>> the field is optional, and supported/not-supported is not a quality of >>> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >>> >>> A correct fix would be to inline the code change into TemporalAccesor >>> and anywhere else that has a similar use of the check method. If it is >>> widely used, a package scoped method (in an appropriate location) may >>> be a solution. >>> >>> thanks >>> Stephen >>> >>> >>> >>> On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: >>>> Hi, >>>> >>>> A simple fix for the exception and message when TemporalAccessor.get() >>>> is used (incorrectly) to retrieve Fields with long values. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>>> >>>> Thanks, Roger >>>> >>>> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |
From: roger r. <rog...@or...> - 2013-03-06 15:43:04
|
Hi Stephen, On 3/6/2013 3:58 AM, Stephen Colebourne wrote: > I hate the inheritDoc change. Is it done this way anywhere else in the > JDK (I don't think so). While I accept it may be easier for > maintainers, it is far worse for most developers who are just reading > the Javadoc as source code (having hit F3 in Eclipse to jump to the > source code of the method they are working with). While the HTML tool > can hunt down the inheritDoc, regular users cannot. I count 94 classes in src/share/classes/java that use {@inheridDoc}, mostly for exception text on @throws clauses. (mostly in AWT and in collections.) I don't usually develop with the JDK source (as an application developer), there is too much a chance of depending on an implementation, not the spec but I can see the point. We also have quite a number of subclass methods that just say @Override and have no source for the javadoc at all. I can put them back but to me it is more useful to know that the semantics of the exceptions are the unchanged (subclasses rarely change the exception semantics). > > The inlined code looks OK, however the Javadoc of the method is now > wrong as it specifies the implementation. I don't see the difference from the previous text. The conditions from separate @throws have been combined. Both new and old text define the conditions under which the exception is thrown and which exception. Roger > > thanks > Stephen > > > On 5 March 2013 16:16, roger riggs <rog...@or...> wrote: >> Hi, >> >> Makes sense. >> >> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. >> The @throws clauses were slightly out of alignment with >> TemporalAccessor.get. >> To make it simplier to maintain the implementers now use {@inheritDoc}. >> The ValueRange.checkValidIntValue exception message is updated to more >> informative. >> >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ >> >> Thanks, Roger >> >> On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >>> I don't think this change can go in. >>> >>> The checkValidValue methods are public, and so can be called by anyone >>> at any time in any way. The UTTE is intended for use when the Field or >>> Unit passed in is unsupported by the target object. In these methods, >>> the field is optional, and supported/not-supported is not a quality of >>> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >>> >>> A correct fix would be to inline the code change into TemporalAccesor >>> and anywhere else that has a similar use of the check method. If it is >>> widely used, a package scoped method (in an appropriate location) may >>> be a solution. >>> >>> thanks >>> Stephen >>> >>> >>> >>> On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: >>>> Hi, >>>> >>>> A simple fix for the exception and message when TemporalAccessor.get() >>>> is used (incorrectly) to retrieve Fields with long values. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>>> >>>> Thanks, Roger >>>> >>>> |
From: Stephen C. <sco...@jo...> - 2013-03-06 08:58:54
|
I hate the inheritDoc change. Is it done this way anywhere else in the JDK (I don't think so). While I accept it may be easier for maintainers, it is far worse for most developers who are just reading the Javadoc as source code (having hit F3 in Eclipse to jump to the source code of the method they are working with). While the HTML tool can hunt down the inheritDoc, regular users cannot. The inlined code looks OK, however the Javadoc of the method is now wrong as it specifies the implementation. thanks Stephen On 5 March 2013 16:16, roger riggs <rog...@or...> wrote: > Hi, > > Makes sense. > > I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. > The @throws clauses were slightly out of alignment with > TemporalAccessor.get. > To make it simplier to maintain the implementers now use {@inheritDoc}. > The ValueRange.checkValidIntValue exception message is updated to more > informative. > > Updated webrev: > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ > > Thanks, Roger > > On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >> I don't think this change can go in. >> >> The checkValidValue methods are public, and so can be called by anyone >> at any time in any way. The UTTE is intended for use when the Field or >> Unit passed in is unsupported by the target object. In these methods, >> the field is optional, and supported/not-supported is not a quality of >> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >> >> A correct fix would be to inline the code change into TemporalAccesor >> and anywhere else that has a similar use of the check method. If it is >> widely used, a package scoped method (in an appropriate location) may >> be a solution. >> >> thanks >> Stephen >> >> >> >> On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: >>> Hi, >>> >>> A simple fix for the exception and message when TemporalAccessor.get() >>> is used (incorrectly) to retrieve Fields with long values. >>> >>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>> >>> Thanks, Roger >>> >>> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2013-03-06 08:51:54
|
The default method in TemporalField still needs changing to check for null locale. Otherwise good to push. Stephen On 5 March 2013 22:50, roger riggs <rog...@or...> wrote: > Hi, > > > On 3/5/2013 8:42 AM, Stephen Colebourne wrote: > > Not sure that the aligned-week-of-year should be assigned the "week" key. > > Probably not best. For most fields CLDR does not have locale specific data. > > Corresponds to the CLDR 'w' week-of-year and would be appropriate > for IsoFields.WEEK_OF_WEEK_BASED_YEAR and WeekFields.weekOfYear(). > > Updated: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > > > Roger > > > The ChronoField implementation should throw NPE is loclae is null, which > requires an Objects.requireNotNull and a test. > > Otherwise good. > thanks > Stephen > > > On 2 March 2013 19:02, roger riggs <rog...@or...> wrote: >> >> Hi, >> >> Issue #103 requests locale based display names for field names. >> The data is available and it only needs a >> TemporalField/ChronoField.getDisplayName >> method plus a little plumbing. >> >> Please review and comment: >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ >> >> javadoc: TemporalField and ChronoField: >> http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ >> >> > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: Roger R. <Roger.Riggs@Oracle.com> - 2013-03-06 05:04:59
|
Hi, Thanks for the comments. On 03/05/2013 10:31 PM, Masayoshi Okutsu wrote: > Here are my comments. > > - LDML (UTS#35) calls non-stand-alone styles format styles (forms) > rather than normal styles. I prefer to follow the LDML naming. Updated to use CLDR friendly terminology. > > - I suspect that it's hard for most developers to understand the > differences between the "normal" and stand-alone constants from the > descriptions. The examples are the same ones, like "Monday". The explanation can be expanded with more examples. > > - It happens to work if you use DateFormat styles as an index to the > time zone names array. But it's not correct to use DateFormat styles. I could not checkin something that didn't work. I replaced the DateFormat references with literals. But it was quite unclear where the values were defined in the implementation. There was some very brittle code dependent on the enum values. > > - TBD part: Calendar defines both format and standalone styles to > which the TextStyles need to map. > > If you add the standalone constants to TextStyle, I can take care of > the rest. ok, I'll push, but there may still be some additional comments about the public API. Roger > > Masayoshi > > On 3/6/2013 6:32 AM, roger riggs wrote: >> Please review this addition to add TextStyle enum values for >> standalone versions >> of FULL, SHORT, NARROW to support CLDR defined patterns. >> >> http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ >> >> More work is needed after the public API is defined. >> >> Thanks, Roger >> > |
From: Roger R. <Roger.Riggs@Oracle.com> - 2013-03-06 03:40:06
|
Hi, On 03/05/2013 09:02 AM, Stephen Colebourne wrote: > I don't like the » as it makes it a lot harder to read as source > code (which is more common than reading HTML). Is there an alternative > arrow like symbol we could use, such a => or just a colon? The unbalanced ">" is flagged as an error, so something else is needed. I replaced the delimiter with "--"; the lines in Duration include the phrase "parses as" that can act as a delimiter. > > This phrase reads badly > "Pattern letter 'u' is the proleptic year which is the same as the > CLDR definition extended year, instead the SimpleDateFormat definition > for numeric day of week." Reworded to remove the reference to CLDR, its unneeded. We may want to separately describe differences the relationship to CLDR. > > In the example table for the public constants, it would be good to > have two examples when there is a choice: > ISO_DATE ... '2011-12-03'; '2011-12-03+01:00' Added examples. Thanks, Roger > > The description of the pattern letters needs more work to match > SimpleDateFormat (and that in builder altering to match letters to > methods), but that is a separate change. > > thanks > Stephen > > > On 2 March 2013 16:48, roger riggs <rog...@or...> wrote: >> Hi, >> >> This javadoc-only change raises the visiblity and enhances the >> descriptions of the DateTimeFormatter patterns and fixes a number >> of complaints that the javadoc tool has about the html markup. >> >> https://github.com/ThreeTen/threeten/issues/240 >> >> webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ >> >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to >> developing practices and products that help protect the environment >> |
From: Masayoshi O. <mas...@or...> - 2013-03-06 03:31:28
|
Here are my comments. - LDML (UTS#35) calls non-stand-alone styles format styles (forms) rather than normal styles. I prefer to follow the LDML naming. - I suspect that it's hard for most developers to understand the differences between the "normal" and stand-alone constants from the descriptions. The examples are the same ones, like "Monday". - It happens to work if you use DateFormat styles as an index to the time zone names array. But it's not correct to use DateFormat styles. - TBD part: Calendar defines both format and standalone styles to which the TextStyles need to map. If you add the standalone constants to TextStyle, I can take care of the rest. Masayoshi On 3/6/2013 6:32 AM, roger riggs wrote: > Please review this addition to add TextStyle enum values for > standalone versions > of FULL, SHORT, NARROW to support CLDR defined patterns. > > http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ > > More work is needed after the public API is defined. > > Thanks, Roger > |
From: roger r. <rog...@or...> - 2013-03-05 22:50:19
|
Hi, On 3/5/2013 8:42 AM, Stephen Colebourne wrote: > Not sure that the aligned-week-of-year should be assigned the "week" key. Probably not best. For most fields CLDR does not have locale specific data. Corresponds to the CLDR 'w' week-of-year and would be appropriate for IsoFields.WEEK_OF_WEEK_BASED_YEAR and WeekFields.weekOfYear(). Updated: webrev: http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ <http://cr.openjdk.java.net/%7Erriggs/webrev-field-displayname-103/> Roger > > The ChronoField implementation should throw NPE is loclae is null, > which requires an Objects.requireNotNull and a test. > > Otherwise good. > thanks > Stephen > > > On 2 March 2013 19:02, roger riggs <rog...@or... > <mailto:rog...@or...>> wrote: > > Hi, > > Issue#103 <https://github.com/ThreeTen/threeten/network> requests > locale based display names for field names. > The data is available and it only needs a > TemporalField/ChronoField.getDisplayName > method plus a little plumbing. > > Please review and comment: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > <http://cr.openjdk.java.net/%7Erriggs/webrev-field-displayname-103/> > > javadoc: TemporalField and ChronoField: > http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ > <http://cr.openjdk.java.net/%7Erriggs/javadoc-field-displayname-103/> > |
From: <jo...@gm...> - 2013-03-05 22:22:30
|
That's great news. Thanks. On Tue, Mar 5, 2013 at 5:09 PM, Douglas Surber <dou...@or...>wrote: > JDBC 4.2 fully supports JSR-310. > > Douglas > > At 01:59 PM 3/5/2013, jo...@gm... wrote: > >Hi all, I haven't been following the mailing list. I was just > >curious if we can expect the JDBC API to be updated to support 310 > >classes when this project is finally included as part of the > >official JDK. Also, are you guys working with DB vendors to ensure > >the implementations of these methods are consistent? > > > >Working with the JDBC api (directly or indirectly with hibernate) > >has been particularly frustrating for me and I'm sure everyone else > >in the world. Threeten might be the most beautiful date/time API > >ever created (and in the brief period I used it last year it was!), > >but if we're still forced to use the existing JDBC api, date/time > >issues will continue to plague developers. > > > >Jonathan > > >------------------------------------------------------------------------------ > >Symantec Endpoint Protection 12 positioned as A LEADER in The > >Forrester > >Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in > >the > >endpoint security space. For insight on selecting the right partner > >to > >tackle endpoint security challenges, access the full report. > >http://p.sf.net/sfu/symantec-dev2dev > > > >_______________________________________________ > >threeten-develop mailing list > >thr...@li... > >https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: Douglas S. <dou...@or...> - 2013-03-05 22:09:57
|
JDBC 4.2 fully supports JSR-310. Douglas At 01:59 PM 3/5/2013, jo...@gm... wrote: >Hi all, I haven't been following the mailing list. I was just >curious if we can expect the JDBC API to be updated to support 310 >classes when this project is finally included as part of the >official JDK. Also, are you guys working with DB vendors to ensure >the implementations of these methods are consistent? > >Working with the JDBC api (directly or indirectly with hibernate) >has been particularly frustrating for me and I'm sure everyone else >in the world. Threeten might be the most beautiful date/time API >ever created (and in the brief period I used it last year it was!), >but if we're still forced to use the existing JDBC api, date/time >issues will continue to plague developers. > >Jonathan >------------------------------------------------------------------------------ >Symantec Endpoint Protection 12 positioned as A LEADER in The >Forrester >Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in >the >endpoint security space. For insight on selecting the right partner >to >tackle endpoint security challenges, access the full report. >http://p.sf.net/sfu/symantec-dev2dev > >_______________________________________________ >threeten-develop mailing list >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: <jo...@gm...> - 2013-03-05 21:59:17
|
Hi all, I haven't been following the mailing list. I was just curious if we can expect the JDBC API to be updated to support 310 classes when this project is finally included as part of the official JDK. Also, are you guys working with DB vendors to ensure the implementations of these methods are consistent? Working with the JDBC api (directly or indirectly with hibernate) has been particularly frustrating for me and I'm sure everyone else in the world. Threeten might be the most beautiful date/time API ever created (and in the brief period I used it last year it was!), but if we're still forced to use the existing JDBC api, date/time issues will continue to plague developers. Jonathan |
From: roger r. <rog...@or...> - 2013-03-05 21:32:42
|
Please review this addition to add TextStyle enum values for standalone versions of FULL, SHORT, NARROW to support CLDR defined patterns. http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ More work is needed after the public API is defined. Thanks, Roger |
From: roger r. <rog...@or...> - 2013-03-05 16:16:54
|
Hi, Makes sense. I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. The @throws clauses were slightly out of alignment with TemporalAccessor.get. To make it simplier to maintain the implementers now use {@inheritDoc}. The ValueRange.checkValidIntValue exception message is updated to more informative. Updated webrev: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ Thanks, Roger On 3/5/2013 8:49 AM, Stephen Colebourne wrote: > I don't think this change can go in. > > The checkValidValue methods are public, and so can be called by anyone > at any time in any way. The UTTE is intended for use when the Field or > Unit passed in is unsupported by the target object. In these methods, > the field is optional, and supported/not-supported is not a quality of > the ValueRange class. Thus UTTE is just plain wrong to be thrown here. > > A correct fix would be to inline the code change into TemporalAccesor > and anywhere else that has a similar use of the check method. If it is > widely used, a package scoped method (in an appropriate location) may > be a solution. > > thanks > Stephen > > > > On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: >> Hi, >> >> A simple fix for the exception and message when TemporalAccessor.get() >> is used (incorrectly) to retrieve Fields with long values. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> >> Thanks, Roger >> >> |
From: Stephen C. <sco...@jo...> - 2013-03-05 14:02:28
|
I don't like the » as it makes it a lot harder to read as source code (which is more common than reading HTML). Is there an alternative arrow like symbol we could use, such a => or just a colon? This phrase reads badly "Pattern letter 'u' is the proleptic year which is the same as the CLDR definition extended year, instead the SimpleDateFormat definition for numeric day of week." In the example table for the public constants, it would be good to have two examples when there is a choice: ISO_DATE ... '2011-12-03'; '2011-12-03+01:00' The description of the pattern letters needs more work to match SimpleDateFormat (and that in builder altering to match letters to methods), but that is a separate change. thanks Stephen On 2 March 2013 16:48, roger riggs <rog...@or...> wrote: > Hi, > > This javadoc-only change raises the visiblity and enhances the > descriptions of the DateTimeFormatter patterns and fixes a number > of complaints that the javadoc tool has about the html markup. > > https://github.com/ThreeTen/threeten/issues/240 > > webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ > > javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle <http://www.oracle.com/commitment> Oracle is committed to > developing practices and products that help protect the environment > |
From: Stephen C. <sco...@jo...> - 2013-03-05 13:49:37
|
I don't think this change can go in. The checkValidValue methods are public, and so can be called by anyone at any time in any way. The UTTE is intended for use when the Field or Unit passed in is unsupported by the target object. In these methods, the field is optional, and supported/not-supported is not a quality of the ValueRange class. Thus UTTE is just plain wrong to be thrown here. A correct fix would be to inline the code change into TemporalAccesor and anywhere else that has a similar use of the check method. If it is widely used, a package scoped method (in an appropriate location) may be a solution. thanks Stephen On 4 March 2013 17:53, roger riggs <rog...@or...> wrote: > Hi, > > A simple fix for the exception and message when TemporalAccessor.get() > is used (incorrectly) to retrieve Fields with long values. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > > Thanks, Roger > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: Masayoshi O. <mas...@or...> - 2013-03-05 03:25:13
|
I wonder if TemporalField.getDisplayName should describe the default behavior, returning the getName() value. Should the getDisplayName implementations check null locale? Masayoshi On 3/3/2013 4:02 AM, roger riggs wrote: > Hi, > > Issue#103 <https://github.com/ThreeTen/threeten/network> requests > locale based display names for field names. > The data is available and it only needs a > TemporalField/ChronoField.getDisplayName > method plus a little plumbing. > > Please review and comment: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > > javadoc: TemporalField and ChronoField: > http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ > |
From: roger r. <rog...@or...> - 2013-03-04 17:53:52
|
Hi, A simple fix for the exception and message when TemporalAccessor.get() is used (incorrectly) to retrieve Fields with long values. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ Thanks, Roger |
From: roger r. <rog...@or...> - 2013-03-02 19:03:02
|
Hi, Issue#103 <https://github.com/ThreeTen/threeten/network> requests locale based display names for field names. The data is available and it only needs a TemporalField/ChronoField.getDisplayName method plus a little plumbing. Please review and comment: webrev: http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ javadoc: TemporalField and ChronoField: http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |
From: roger r. <rog...@or...> - 2013-03-02 18:04:06
|
Hi, This javadoc-only change raises the visiblity and enhances the descriptions of the DateTimeFormatter patterns and fixes a number of complaints that the javadoc tool has about the html markup. https://github.com/ThreeTen/threeten/issues/240 webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |
From: Xueming S. <xue...@or...> - 2013-03-01 19:33:22
|
-ChronoDateImple.periodUntil(t, u) The "convention" is to align the "case" to the "switch" in jdk source code? - Understood it is kinda of 310 convention to have "... == false", but I would suggest to use the the normal (! X) instead. -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed using the chronology of this date. If necessary, the input date will be converted to match" (btw, there are two "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle "same type" of CLD now, (their java doc currently simply is inherited from the super class). Is it possible to have a better alternative? at least they all have a isodate. -Sherman On 2/28/13 8:43 AM, roger riggs wrote: > Please review bug fix/improvements for: > > PeriodUntil throws exception: unable to calculate period between > objects of different types > http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ > > > The periodUntil methods do not correctly compute the period > for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. > ChronoDateImpl is enhanced to support 12 month based calendars. > > The ValueRange.getIntValue method should throw similar exceptions > when the field is not an int field. Provides better feedback for > the generic Temporal.get access to fields that are not int field. > > Added simple tests to TestHijrahChronology, TestJapaneseChronology, > TestMinguoChronology, and TestHijrahChronology > > Thanks, Roger > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Xueming S. <xue...@or...> - 2013-03-01 19:20:51
|
On 3/1/13 9:41 AM, Xueming Shen wrote: > -ChronoDateImple.periodUntil(t, u) > The "convention" is to align the "case" to the "switch" in jdk > source code? > > - Understood it is kinda of 310 convention to have "... == false", but > I would suggest to > use the the normal (! X) instead. > > -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed > using the chronology > of this date. If necessary, the input date will be converted to > match" (btw, there are two > "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle > "same type" of CLD I meant to say 3. > now, (their java doc currently simply is inherited from the super > class). Is it possible to have > a better alternative? at least they all have a isodate. > > -Sherman > > > On 2/28/13 8:43 AM, roger riggs wrote: >> Please review bug fix/improvements for: >> >> PeriodUntil throws exception: unable to calculate period between >> objects of different types >> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ >> >> >> The periodUntil methods do not correctly compute the period >> for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. >> ChronoDateImpl is enhanced to support 12 month based calendars. >> >> The ValueRange.getIntValue method should throw similar exceptions >> when the field is not an int field. Provides better feedback for >> the generic Temporal.get access to fields that are not int field. >> >> Added simple tests to TestHijrahChronology, TestJapaneseChronology, >> TestMinguoChronology, and TestHijrahChronology >> >> Thanks, Roger >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> >> >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: roger r. <rog...@or...> - 2013-02-28 23:37:39
|
Please review bug fix/improvements for: PeriodUntil throws exception: unable to calculate period between objects of different types http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ The periodUntil methods do not correctly compute the period for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. ChronoDateImpl is enhanced to support 12 month based calendars. The ValueRange.getIntValue method should throw similar exceptions when the field is not an int field. Provides better feedback for the generic Temporal.get access to fields that are not int field. Added simple tests to TestHijrahChronology, TestJapaneseChronology, TestMinguoChronology, and TestHijrahChronology Thanks, Roger |
From: Stephen C. <sco...@jo...> - 2013-02-27 16:37:46
|
Issue: #268 Patch: https://gist.github.com/jodastephen/5049319 This can then be extended to "fix" the stricter Japanese era requirements, and add lenient/strict resolving in general. Stephen |