Improve Java 5 support

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Improve Java 5 support

Jörg Schaible
Hi Stephen,

while I know that joda-time requires Java 5 since version 2.0, I can see
still some stuff (only from a first look), where Java 5 is not yet used in
its full breadth. While this all seems to be nit-picking, I'd actually like
to address them nevertheless especially with the perspective to get this API
into the JDK.

1/ copy method

MutableDateTime, MutableInterval and MutablePeriod define a superfluous copy
method. The clone method can now return the appropriate type directly, so a
type cast is no longer necessary.

2/ Chronology.withUTC, Chronology.withZone

According to documentation an implementation should return an instance of
the same type with different zone i.e. all implementations can return now
the appropriate type directly.

3/ PeriodPrinter.printTo, DateTimePrinter.printTo

Both interfaces define printTo methods that use a StringBuffer as argument.
It is be better to use an AbstractStringBuilder now instead.


Is such input valuable for you?

Cheers,
Jörg


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improve Java 5 support

jodastephen
On 22 March 2012 10:05, Jörg Schaible <[hidden email]> wrote:
> while I know that joda-time requires Java 5 since version 2.0, I can see
> still some stuff (only from a first look), where Java 5 is not yet used in
> its full breadth. While this all seems to be nit-picking, I'd actually like
> to address them nevertheless especially with the perspective to get this API
> into the JDK.

Joda-Time isn't going into the JDK, JSR-310 might be, but thats a different API.

> 1/ copy method
>
> MutableDateTime, MutableInterval and MutablePeriod define a superfluous copy
> method. The clone method can now return the appropriate type directly, so a
> type cast is no longer necessary.

True. The clone methods could be added, but i wouldn't remove the copy
methods for backwards compatibilty.

> 2/ Chronology.withUTC, Chronology.withZone
>
> According to documentation an implementation should return an instance of
> the same type with different zone i.e. all implementations can return now
> the appropriate type directly.

True, and probably worth doing.

> 3/ PeriodPrinter.printTo, DateTimePrinter.printTo
>
> Both interfaces define printTo methods that use a StringBuffer as argument.
> It is be better to use an AbstractStringBuilder now instead.

That would be backwards incompatible.


Feel free to fork on GitHub and send pull requests with tests!
Stephen

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improve Java 5 support

Matthew Adams
On Thu, Mar 22, 2012 at 6:06 AM, Stephen Colebourne
<[hidden email]> wrote:
>> 3/ PeriodPrinter.printTo, DateTimePrinter.printTo
>>
>> Both interfaces define printTo methods that use a StringBuffer as argument.
>> It is be better to use an AbstractStringBuilder now instead.
>
> That would be backwards incompatible.

First, I'd recommend the use of interface CharSequence instead.

Second, I don't see how that would that be backward incompatible.
StringBuilder & StringBuffer both implement CharSequence.  By changing
the signatures to take a CharSequence, you'd be effectively relaxing
the restriction of using StringBuilder and allowing a larger range of
types.  Can you please elaborate?

-matthew

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improve Java 5 support

jodastephen
On 22 March 2012 12:34, Matthew Adams <[hidden email]> wrote:

> On Thu, Mar 22, 2012 at 6:06 AM, Stephen Colebourne
> <[hidden email]> wrote:
>>> 3/ PeriodPrinter.printTo, DateTimePrinter.printTo
>>>
>>> Both interfaces define printTo methods that use a StringBuffer as argument.
>>> It is be better to use an AbstractStringBuilder now instead.
>>
>> That would be backwards incompatible.
>
> First, I'd recommend the use of interface CharSequence instead.
>
> Second, I don't see how that would that be backward incompatible.
> StringBuilder & StringBuffer both implement CharSequence.  By changing
> the signatures to take a CharSequence, you'd be effectively relaxing
> the restriction of using StringBuilder and allowing a larger range of
> types.  Can you please elaborate?

Binary compatibiilty. The change of signature would be source
compatible, but not binary compatible. Existing code compiled against
the old API would fail if it was changed. Adding a second parallel
method (which would be compatible) is just bloat.

Stephen

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...