commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject [lang] The scope of lang
Date Thu, 02 Jan 2003 22:53:50 GMT
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 

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!


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message