mmm,
not really. the util package for instance has StreamUtils,
ComponentUtils oder LocaleUtils.
But nothing related to numbers...
Anyone else know a better place?
Otherwise, I move the IntegerUtils up.
-M
On 10/18/06, Adam Winer [EMAIL PROTECTED] wrote:
Definitely +1 to removing
I'm partly -1 on this. We should just be using autoboxing for int -
Integer, which is required to already cache the same object for integers
from -128 to 127 inclusive. The part of IntegerUtils that is still useful
is the cache of toString()'d versions of the integers, but I'm not
sure how
Oops, I meant getString(int) and getString(long). Those
are useful. It's getInteger() that is not useful anymore.
-- Adam
On 10/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
toString() ? no in there.
I use getString(long) for my stuff.
-M
On 10/17/06, Adam Winer [EMAIL PROTECTED]
Definitely +1 to removing getInteger(). Is there
anywhere better in the API to move the IntegerUtils
methods other than having a bonus class?
-- Adam
On 10/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
so, should I remove that one and *refactor* the calls ?
so I can make it public,
Hey,
any one care to make IntegerUtils from trinidad-impl part of the public API?
I like to use it in the api, when working on the validator/converter
*overhaul* issue(s).
the javadoc says:
Class containing various integer utilities. It caches commonly
used Integer objects and String
+1
On 10/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hey,
any one care to make IntegerUtils from trinidad-impl part of the public API?
I like to use it in the api, when working on the validator/converter
*overhaul* issue(s).
the javadoc says:
Class containing various integer
+1
Matthias Wessendorf wrote:
+1
On 10/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hey,
any one care to make IntegerUtils from trinidad-impl part of the
public API?
I like to use it in the api, when working on the validator/converter
*overhaul* issue(s).
the javadoc says:
Class
