Reply in-line, not terribly elegant as its after midnight here ;-) From: "Rodney Waldhoff" <[EMAIL PROTECTED]> > It may seem that I'm picking on [lang] here, but that's not my intention. > I just feel like I'm watching an impending train-wreck, and intend to > throw the switch while there's still time. Or cause a fork to sourceforge.
> The arguments in favor of monolithic components I've seen seem to boil > down to concerns about minimizing dependencies and preventing > circularities. Partly, but I see it more about having a viable community. [lang] has that community, I don't believe 10 separate components would. > 1) Monolithic components introduce false dependencies. Adding any dependency to your application adds a risk, and you need to get a reward for that risk. I would argue that adding more dependencies (more smaller jars, each with their own dependencies) makes the overall situation worse not better. > 2) Monolithic components encourage superfluous dependencies and > inappropriate coupling. > <snip> > But when used infrequently in an otherwise unrelated class, the price paid > for this trivial reuse is fairly high, coupling this code with a 1700+ > line class to reuse 33 characters of code. (And StringUtils uses > CharSetUtils, which uses CharSet, which uses various java collection > classes, etc.) This is actually a key point for the defence. If this argument is followed through, the logical conclusion is not to use StringUtils, not to share code, not to reuse. It is only if an application uses a sufficient amount of the functionality from any component that it will choose to add the dependency, rather than recode. If a component only contains a couple of classes people simply won't use it. > 3) Monolithic components slow the pace of development. > > When components are small and single purpose, changes are small, > well-contained, readily tested and easily understood. New releases can be > performed more readily, more easily and hence more frequently. I totally disagree with this. [util] languished for over a year with no action. No one took responsibility to promote, fix, manage, look after or release the code. This has now been noted on the recent Jakarta PMC report Releases take a significant amount of time. And thats time away from coding, bug fixing etc. 10 components means 10 times the effort on releases, and I simply do not accept that is viable. > Bundling unrelated code into a monolithic component means I need to > synchronize development of that unrelated code: Maybe I'd like to do a new > release of sub-component X, but I can't since sub-component Y is in the > midst of a major refactoring. Maybe I'd like to do a major refactoring of > sub-component A but I can't since sub-component B is preparing for a > release. Virtually all the [lang] classes are fundamentally independent, so refactoring isn't an issue. And this actually highlights that to be proper about this would require a component for virtually each class. > 4) Monolithic components make it more difficult for clients to track and > communicate their dependencies. Maybe you place more store in version numbers than I do. If I pickup any new jar, I'd test it whatever the version number difference. > 5) Monolithic components only hide circularities, and may even encourage > them. Perhaps it does. But it allows us to actually develop code without arguing about which should depend on which all the time, and that is terribly wasteful. > 6) Monolithic components only get bigger, making all of these problems > worse. > > For instance, the [lang] proposal that was approved describes its scope > as: > > "[A] package of Java utility classes for the classes that are in > java.lang's hierarchy, or are considered to be so standard as to justify > existence in java.lang. The Lang Package also applies to primitives and > arrays." [6] I agree that the proposal does not fully define [lang] anymore. Nor does the name. "A component of Java utility classes to supplement those provided in the JDK java.lang and java.util package hierarchies. The component also applies to primitives and arrays. The component shall depend only on the JDK." > In the five months since that proposal was accepted, the scope of lang has > expanded significantly ([7], [8], [9], [10], [11]) and now includes or is > proposed to include: > > * math utilities [12] > * serialization utilities [13] > * currency and unit classes [14] > * date and time utilities [15] > * reflection and introspection utilities [16] > * functors [17] > * and much more [18], [19], [20], [21], [22] > > And the more the scope expands, the more the scope expands--the existence > of the [lang] monolith has encouraged a reduction in ([23], [24], others) > and discouraged the growth of ([25], [26], others) other components, and > has discouraged the introduction of new components ([27], [28], others). Or viewed alternately, [lang] has had the community to grow and stay active while other components have not. Not all of the ideas presented in the list above will end up in [lang] (some get rejected). Many should though, as they provide functionality that the JDK should provide - and thats what [lang] is about. > As above and before, if classes aren't commonly used, changed, and > released together, or mutually dependant on each other, they should be in > distinct components. If we want a catch-all JAR, we've got one [3]. > Given the principles enumerated in the commons guidelines and detrimental > effects enumerated here, I'm not sure why we'd follow any other course. Because open source is about community first, code second. As a group of functions, [lang] has ideas, momentum, growth and life. As a small isolated component (in line with commons guidelines), [util] and [pattern] have both died through lack of interest. Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
