[lang] release plans

[Henri Yandell <ba...@generationjava.com>]

Going over the lists from the last week and trying to identify what is
done and what is not yet. Am sure more things will become apparant.

-------------------------------------------------------------------------


1)  rename method in Objects
- change isNull() to defaultIfNull()

[DONE]

2) add hashCode building methods to Objects, or its own class based on
best hashCode practice. See [Lang] Add hashcode generating methods from
Stephen Colebourne.

3) add CharUtils and UStringBuffer and refactor all the Strings code to be
shared

4) add low level reflection code in reflect subpackage as was discussed a
few weeks ago. (needs further discussion)

5) Avalon system utilities. Not in initial Lang release.

6) Numbers has a lot of comments about future things. Plus
containsDigits() has question marks against the null handling

7) Classes clashes badly with the reflection stuff. Either we include
reflection or we don't.

8) Naming conventions. It seems that every other Commons project is using
XxxUtils for their utility names (Collections, BeanUtils, IO, Pattern). It
seems that we should at least consider renaming the classes for
consistency.

9)
Remove Constant. Consider adding an Enum sub-package.

10) Strings - some methods are very specific (too specific) and could be
removed

i)
- parseObjectKey
- removeUnderscores
- reverseDottedName, reverseDelimitedString will do this so is dot a valid
  special case
- interpolate - this seems to be very specific to a particular syntax
[DONE scolebourne]

ii)
Some methods have misleading names
- isValid() - should be isNotEmpty(), a not empty string is not
necessarily valid

[DONE scolebourne]

iii)
Some methods could be optimised:
- capitalise
- uncapitalise
- overlayString

[DONE rmcneely]

iv)
Some methods may be wrong:
- chomp/chompLast  hard codes \n rather than uses System.LINE_SEPARATOR
- wordWrap  hard codes \n rather than uses System.LINE_SEPARATOR

v)
The class seems too big. Maybe some smaller associated utility classes
would be appropriate?
CharSet methods seem to be a group. Could they be in their own class? Also
why is evaluateSet public when a CharSet cannot be passed in anywhere.
(PatternStringUtils)
Maybe the casing methods could be broken out?    (CaseStringUtils)
Maybe the random methods could be broken out?   (RandomStringUtils)

[Random: DONE - scolebourne]

vi)
Add
- left(String, int len), right(String, int len) and mid(String, int from,
int len) to Strings, no exceptions  (as per BASIC)
- isAlphanumericSpace/isNumericSpace, for specifically space and not
whitespace
- contains(String, String), does the first string contain the second

[DONE - scolebourne]

11) Apply the patch to the NestedException classes.

12)
 Create website. XDoc or generate by a tool such as Maven.
 [Maven exammple:
  http://www.generationjava.com/maven/jakarta-commons-sandbox/lang/
 ]

13) Unit Tests. More unit tests are needed. Numbers, Classes, Constant
need unit tests and Strings could do with more tests in its unit test.

14) Check Commons.Lang is in whichever bug tool is in use currently,
scarab or bugzilla.

15) Check what Commons.Lang/Gump status is.







--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>