[threeten-dev] Fwd: Re: [threeten-develop] Review fix for periodUntil issue 273

roger riggs roger.riggs at oracle.com
Fri Mar 1 11:54:08 PST 2013


Hi Sherman,

Thanks for the comments.

On 3/1/2013 2:40 PM, Xueming Shen wrote:
> while we are on this, it appears two ChronoLocalDate.periodUntil() 
> methods
> are declared as "public abstract ...", any particular reason to do 
> that? or just
> a "leftover" of the previous life of CLD as an abstract class, instead 
> of an interface
> now?
Will fix, it is a left over from the before the transition to interface.
>
> On 03/01/2013 10:25 AM, Xueming Shen wrote:
>>
>> ...

>>
>> 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?
Netbeans doesn't see it that way and for now I'd stay consistent with 
the rest of
310.  If we decide to make a pass and update to JDK conventions, i'd 
rather do that separately.
>>>
>>> - Understood it is kinda of 310 convention to have "... == false", 
>>> but I would suggest to
>>>    use the the normal (! X) instead.
Same
>>>
>>> -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.
True, though this is odd, the two periodUntil methods have different
assertions for whether the date is converted or only handle the same type.
I'll wait to commit until I can understand why.
>>
>>
>>>   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.
If they are all to be converted, the javadoc would be consistent.

Thanks, Roger

>>>
>>> -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
>>>> threeten-develop at lists.sourceforge.net
>>>> 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



More information about the threeten-dev mailing list