There are many good points in this thread. My input is to try and
outline where I have seen te boundaries.
[lang] vs [math] - [lang] doesn't require a maths degree. [math] does.
[lang] vs [functor] - [lang] doesn't require FP knowledge or religion.
[functor] does.
[io] - handles Stream, Reader and Writer - the java.io package
[collections] - handles those interfaces defined by Sun as the Java
Collections Framework
[beanutils] - handles code that adheres to Sun's defined Java Bean framewok
[lang] - the remaining parts of java.lang and java.util
Oh, and as per the original commons charter, DUPLICATION IS FINE!
There is nothing fundamentally wrong with small amounts of duplication
in low level commons classes, and this is far preferable to te
unacceptable idea of dependencies.
Thus, Fraction can happily live in [lang] and [math] - no great harm
comes fom it ([math] targets a smaller group of developers than [lang]).
ArrayUtils? Well arrays are not part of the Java Collections Framework.
So, its fair for array handling code to be in [lang].
And splitting [collections]? Definitely a good idea. I would remove all
the Predicate/Closure/Transformer code (if you believe in FP, use
[functor]). Then split the rest by implementations of JDK collections,
and extended JDK collections - BidiMap, Bag, Trie.
Stephen
Henri Yandell wrote:
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.
ComparableComparator made its way (privately) over for the new Range
class. Fair enough - Comparable and Comparator also overlap between
lang.* and util.*.
I have a JIRA issue threat to consider moving Collections code over to
Lang if Collections becomes dead [LANG-532] :)
---
One thought I have for Collections is splitting it up into two parts.
The first would be items that add to collections in the JDK, the
second would be additional collections. The former could conceivably
merge with Lang, the latter could also be split up into an SPI style
approach with an API jar and an Impl jar. The latter would most likely
depend on the former.
It would then be tempting to also merge Functors for example into the
latter, plus I think we could get back on the bandwagon of adding new
things, like the long standing Trie JIRA issue.
Biased note: Part of this is that I'm interested in the JDK enhancing
parts, but not all the implementations of weird and whacky
collections; however I think this is likely not just me and that the
separation would do wonders for the release cycle.
Thoughts?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
