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.
Interesting idea and forces us to really think about the scopes of both [lang] and [collections]. Both started as really extensions of the JDK and both have had large parts obsoleted by advances in the JDK. I guess it still makes sense to consider [lang] as simple extensions of the JDK and [collections] as data structures. What I have a little trouble with is where to draw the line within [collections]. I think functors is a bad example, as one could argue that this belongs in neither [collections] nor [lang] - oh wait, we did that and created [functors] (lets not divert down that rabbit hole ;). Better examples of what might be peeled off into [lang] could be the iterators or decorators. Can you get a little more specific on what parts of [collections] you see as in scope for merging into [lang]? I am +1 on publishing the collections test jar as a separate maven artifact. We don't have to create a separate subproject for that, IMO. Note that lots of other commons components - [math], [net], [functors], [configuration], [beanutils] all come to mind immediately - have elements that amount to extensions of the JDK. Like [collections], they all have a more specialized domain that is their primary focus. So the natural question is, if this makes sense for [collections], why not everywhere else? Answering that question might help clarify intent here. One final comment is that a logical alternative is to just split [collections] internally into multiple pieces with separate release cycles. Managing dependencies among the subcomponents and user documentation might be tricky. IIRC, that is what has prevented us from actually ever doing this up to now. Phil > > 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
