This is a FAQ (or FFB - Frequently Fought Battle): I don't know you guys, but personally I think the scope of lang is clear:
Javaprograms normally handles numbers, exceptions, strings, objects, arrays, casting etc. This is what java.lang is for. Then there is a java.math and a java.text etc too, but not all text handling goes into java.text. Basic text handling is incorporated into java.lang.String. In the java.* classes there is this distinction between basic things and advanced stuff (and even more when you look at the relation between fx java.sql and javax.sql). Which is a good distinction to make. Time has shown that there are some things you want to do to your objects in order to make them nice. You often want to embed exceptions, but you don't want to hide the original exception's stack trace, you want to return hash values that reflect the content of your objects, you want to generate informative toString values, you want to validate input data etc. Time has also shown that these things and other common wannahaves is either awkward and/or boring and/or error prone to do using the java.* classes. Hence the need for reusable, well tested components. We all do these things, so let us do them using the same library. Time (and java.lang) has also shown that there are some useful mechanisms that you would like to add as a possibility (or aspect) to some of your classes. java.lang.* has for example Comparable. By making your entity class implementing Comparable, you magically has access to the predefined sorting algorithms. And you or a third party can create sorting algorithms that sorts anything Comparable. Now, we know of a couple of similar interfaces that make any object supporting a commonly asked for mechanism (like sorting). Those we have identified and labeled "functors". Now that we all know this, let us identify the scope of [lang]. One way of determining scope for a component is to ask: what problem domain is it useful in? Is it about handling and generating SQL statements? Does it perform integral calculus? Does it generate fancy pictures? Sounds? So, what problem domain does [lang] apply to? Well, given that it handles primitive types, it handles things you want to do to objects of any domain, and it handles basic java language elements, I would conclude that it belongs in the domain of java programming in general, as opposed to java programming in astrophysics or writing games or web apps in java. Is this a broad scope? Yes, if you think of a scope as a problem domain and observes that the classes can be used in any problem domain. No, if you consider the fact that a class or mechanism is only within scope for [lang] if it actually is suitable for any problem domain (or at least many problem domains). This is a criterion that narrows the number of candidates dramatically. Is it an unclear scope? No, we all know what the language elements are, and you don't have to be a genius to identify methods that operate on Object, Exception, String, Number etc. In fact, even a stupid compiler could tell you that a method doesn't operate on DOMDocument, SqlStatement or Button. There are some border line cases where we should ask ourselves whether this fits or not, but that is what we have the list and our collective judgement for. After all, there is no precise definition of expressions like "generally useful" or even "many". Is it a big scope? Maybe even too big? No. It can turn out to be if one expands all mechanisms into something fullblown (all thinkable Predicates plus advanced input validation framework plus every text handling function you need to implement MS Word etc). Left unattended, [lang] could (but shouldn't) swell into the monolithic catch-all jar of 300 Megs that none of us want to download and install (or distribute or manage). It could be easy to add feature after feature to for instance o.a.c.lang.math until we have something that calculates the distance to Shangri-La. So how should we, members of the list, who watch over [lang] prevent that from happen? By focusing on the scope, on the problem domain. The key words are "any java program", "any basic language element", "regardless of implementation" and the like. It isn't enough if a math professor claims that he uses this FrobnitzCalculation object in all his programs, it is good if me and you and Random J. Hacker also can see use cases for it in our web-apps or game applets or whatever. So this is I believe the scope of [lang], and what the mind set should be for both maintainers and users of it. Now, what if you say "OK, it is good to have the basics, the commons of commons, somewhere. Often you want the basics and not everything plus the lot. Don't buy me a FrobnitzCalculator if I only need some NumberRanges. But is it really good to keep such unrelated things as Predicates and RangeUtils in the same jar?" There are several answers to this question. One reasonable sized jar is easier to handle (not the best argument, I know, but still valid in RealLife(tm)). Dependencies within [lang] are always solved within the releases. One can argue that since number ranges and predicates and input validation share the property of being basic, they are in fact not unrelated, but related in their lowness. But my main argument in favor of keeping them together is that they per definition are, and in reality are and will be even more so, interdependent. And that it by definition is good. Why? Dependencies and tight coupling is something that you normally want to avoid. Almost any OO design pattern is about loosening up the couplings. Answer: Because since the criterion for a class or mechanism to end up in [lang] is that it is good for any java program, and [lang] is java, using [lang] helps in implementing [lang]. [lang] makes [lang] better. In order to avoid circular dependencies between small jars containing parts of today's [lang], lumping them together is the solution. And since [lang] only (should) contain the basics, there are just a few classes per aspect or mechanism. Not so many Kb:s to fuzz about. The only reasonable outfactoring from [lang] I can see would be useful, would be the pure abstractions, the very interfaces. They are seldom dependent of anything (and normally shouldn't be). But as soon as there are implementations, blocks of code, we have the situation where we could very well make use of a [lang] thing in order to increase quality/productivity, and so creating the depency. It has been said against this, that its "broadness" in scope will slow down [lang]'s release cycle. I agree that a component like [lang] probably will have a slower release cycle than more specialized "fix just this" component. But I don't think that the proposed smaller basic components will make their releases that much more often. First, the things in [lang] are normally simple, so they mature quickly. Hence there are less demands for frequent releases. Second, since the scope is about being good for more than one arena, more than one group of stakeholders, there are per definition more stakeholders that will be affected by a release, and thus more things to take into consideration. Things at the bottom (where [lang] belongs) move slowly. (If the proposed smaller components do start to release very often, I would suspect that it is due to a feature rally, so I see the danger of them becoming the math-package with FrobnitzCalulator or text-package with built in MS Word. The fundamental idea of being basic will be lost.) So [lang] has scope, [lang] has focus, [lang] is not about being a waste basket, a shopping mall, _The_JavaToolBox, or a shelter for orphan classes, but is about solving the problem of java programming. Despite my bald statements on what is and what isn't above, remember that this as usual are about two cents of worth from a simple and common non committer, and maybe reflects more of what I think that [lang] should be than what it is in the eyes of the maintainers Correct me if I am wrong, or comment on it if you have the time. Happy New Year everyone! /O -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
