On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > 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].
Agreed - both in terms of what we consider a simple extension of the JDK and what we consider a data structure/algorithm. > 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 ;). I was thinking more that a smaller [collections] might have room for the functor code again - not that [lang] would :) Agreed that it's better out than in though. > 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]? https://issues.apache.org/jira/browse/LANG-532 has a bit. The various XxxUtils classes - but not the factory builder parts that supply various aspects. A slice of the iterators and the comparators. Possibly some basic 'missing' implementations such as ArrayStack, ArraySet, FastVector etc. Not in scope - bag, buffer, transformer, > 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. [io] and [codec] are the ones that jump to mind for me, but I think they're both still tight enough in scope that a) the committer style is not different and b) it's not a big brain import for the users to grok the component. Again though there's a similar style of FooUtils classes on top of the JDK mixed with SPI type implementations. [beanutils] always feels like it needs replacing - something smaller and tighter in [lang] could be a successor. > 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. Yup. We've already been doing it with BeanUtils - some of the code moved/copied over in 3.0. What it would possibly mean in your commons wide suggestion is a bunch of components having a dependency on [lang], which as you say below has often been a blocker. Then again - all java.* code depends on java.lang.* :) > 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. Yup. Effectively this is both a split into 'Collections JDK' and 'Collections Structures', and a merge of Collections JDK to Lang. To Paul's email - I think a wholesale merge of Collections and Lang would be too much. It would slow down releases when we need to release more often (that being part of my justification for splitting Collections - the two halves would be quicker to release). I think that similarity of scope within a component makes it more releasable - the hardest part of Lang 3.0 is the builder subpackage, and I think that's because it's a different style of code than much of the rest. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
