[threeten-dev] Public Eras changes

[roger riggs]

Hi,

Updated the Artifacts:

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-public-enum-eras/ 
Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-public-enum-eras/


On 2/22/2013 5:38 AM, Stephen Colebourne wrote:
> - In HijrahEra, I'd prefer to see the of(int) method test for 1 using
> if rather than switch. And the getValue() method return 1, rather than
> ordinal+1.
fixed
>
> - The import "import java.time.chrono.IsoEra" in IsoChronology looks wrong.
fixed
>
> - The diff in ThaiBuddhistChronology looks all wrong around imports
> and full class names.
oops, left overs from an experiment inlining the enum in the Chronology.
(not an improvement.)
>
> Otherwise, the actual change itself looks good.

One ugly spot is are the return type from Chronology.eras; List<Era>;
the subclasses would prefer to use List<JapaneseEra> but it is not 
compatible.
Changing the signature to return List<? extends Era> is a possibility
but propagates the ugliness to application code.

Converting the return type to Era[] works also.  Its not clear the use 
of List
adds much value to these short and static values.
>
>
> As separate changes:
> - We should add JapaneseEra.values() and valueOf(String) so they match enums.
Added.
>
> - We could/should add from(TemporalAccessor) static methods to each
> era class. This would/could allow the removal of
> ChronoLocalDate.getEra().
getEra is still needed on ChronoLocalDate for the calendar neutral API.

Thanks, Roger

>
> thanks
> Stephen
>
>
> On 21 February 2013 23:21, roger riggs <roger.riggs at oracle.com> wrote:
>> Hi,
>>
>> Combining a number of issues related to  Eras:
>>    - The methods on Era that created a date based on the Era are
>>      problematic for the HijrahChronology were the Era was unaware
>>      of the variants.  The methods Era.date(y,m,d) and Era.dateYearDay(y,d)
>>      are removed.
>>   - The Era.getChronology method is no longer necessary and has the
>>      same problem for HijrahChronology of being unaware of the variants.
>>   - Issue #261 proposed to expose the Eras as public enums and remove
>>     the public static fields from the Chronologies.
>>     (The JapaneseEra remains a class because of the unique need to be
>>     able to define new Eras from supplied configuration data).
>>
>> Please review and comment:
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-public-enum-eras/
>>
>> Javadoc:
>>    http://cr.openjdk.java.net/~rriggs/javadoc-public-enum-eras/
>>
>> --
>> Thanks, Roger
>>
>> Oracle Java Platform Group
>>
>> Oracle is committed to developing practices and products that help protect the environment
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
> ------------------------------------------------------------------------------
> 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