[lang] The scope of lang

[Ola Berg <ol...@arkitema.se>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] The scope of lang

[Ola Berg <ol...@arkitema.se>]

> Despite my bald statements

Ooops. Should be "bold statements". Or maybe "hairy 
statements" :-p

/O

(sorry for the duplication of the previous postings)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] The scope of lang

[Stephen Colebourne <sc...@btopenworld.com>]

I pretty much agree with Hen and Ola's comments below. Here's how I see
[lang] fitting into the bigger scheme of things, and why it has the
subpackages it does.

StringUtils, BooleanUtils, NumberUtils, ArrayUtils, ClassUtils, ObjectUtils.
These do form a coherent group at the heart of [lang].

The enum package contains three classes. Two abstract and a utility class.
It is very hard to see this growing or changing. Its very basic (witness
addition to JDK1.5). It fits well with [lang].

The builder package contains four main classes for building hashcodes,
equals, tostrings and compareTos. Its pretty basic, unlilkely to grow (there
are only four common methods) and would be great in the JDK. It fits well
with [lang].

The exception package contains wrapping exceptions (for pre JDK1.4) and a
utility class. This package has fulfilled its scope. Any additions would
probably be to the utility class. It fits well with [lang].

The math package is basically a breakout of the NumberRange class from the
first release (a bug fix). It should not be, nor seek to be, a fully fledged
maths package. Thus matrices and compex numbers should be excluded for
example. This package should do the very basic maths things that the JDK
doesn't. Mathematicians should find their own maths component, or
[advanced-math]. Thus, simple-math fits well with [lang].

The time package exists to wrap Date and Calendar with utilities, and to fix
a serious bug with the DateFormatter. It should not be, nor seek to be, a
fully fledged time package. Joda time fulfils that goal (as a complete
rewrite of Java dates) and maybe one day might become [advanced-time]. Thus
simple-time fits well with [lang].

The reflect package exists to fix the bugs in the JDK reflection code. It
should not, nor seek to, impose any rules related to beans or alternative
class-like things. [beanutil] and [clazz] exist separately as they involve a
higher level of religion/buy-in. [clazz] could also be called
[advanced-reflect] and will build upon simple-reflect. Thus simple-reflect
fits well with [lang].

The functor package exists to fill a gap in very simple
functors/hooks/callbacks in the JDK. The absence of these classes has lead
to FileFilter not being a Predicate, thus requiring a duplicate set of code
to enable the use of common And, Or etc. Recent discussions have indicated a
possible desire for an [advanced-functor] based on ideas from the JGL,
Smalltalk and others. I have indicated that I believe that this should be
separate from, but built upon, simple-functor. Thus simple-functor fits well
with [lang].

The util package exists to provide a home for classes that are useful, but
would never be released otherwise. There will never be a good place for
these classes to go. [lang] is the best option available, so long as very
tight control is kept over the package.


And in terms of size, a quick check showed:
lang 27%
builder 21%
functor 15%
math 12%
reflect 9%
exception 6%
util 5%
time 4%
enum 3%
(OK, so it adds up to 102%!!)
ie. no one part of [lang] is dominant.

So, simple message.
[lang] does the basic stuff.
[advanced-xxx] exists when required for
- more complex stuff, eg Joda-time, mathematicians packages
- more religious stuff, eg Joda-time, [clazz]
- where there is a choice of implementation, eg [beanutil], [clazz]

Stephen


----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<ol...@arkitema.se>
Sent: Friday, January 03, 2003 1:12 AM
Subject: Re: [lang] The scope of lang


>
>
> On Thu, 2 Jan 2003, Ola Berg wrote:
>
> > 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:
>
> Your view of [lang] seems spot on to me.
>
> > ....
> > Now that we all know this, let us identify the scope of [lang].
> > ....
> > 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.
> >
> > 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.
>
> +1. When org.apache.commons.lang.math reaches this stage, it ought to be
> org.apache.commons.math [and tbh, I don't think any of the current
> committers spend enough time in numerical analysis in Java to be able to
> do that math properly. I know I don't, and my degree was 3 years of
> nothing but maths].
>
> > 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.
>
> +1. I think you've described the meme perfectly.
>
> > 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.
>
> Some subpackages in Lang will grow too big for their commonness-booties.
> At that point they need to enter discussion like this to find out if it's
> time to leave home, or whether to make an extension project etc. ie)
> java.lang.Math is in [lang], but java.math.Xxx is in [math].
>
> [functor] is already near that point, so I can see reasons for it to be in
> and/or out. Nothing else described in previous emails is near to leaving
> home [I reckon].
>
> > First, the things in [lang] are normally simple, so they mature quickly.
> > Hence there are less demands for frequent releases.
>
> Good point. Some of it gets rocket-sciencey [to me] due to class-loaders
> and stuff, but generally the code is simple.
>
> > 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.
>
> You've contributed a lot to Lang (and should be a committer probably).
> Your opinions have complete weight I think.
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] The scope of lang

[Henri Yandell <ba...@generationjava.com>]

On Thu, 2 Jan 2003, Ola Berg wrote:

> 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:

Your view of [lang] seems spot on to me.

> ....
> Now that we all know this, let us identify the scope of [lang].
> ....
> 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.
>
> 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.

+1. When org.apache.commons.lang.math reaches this stage, it ought to be
org.apache.commons.math [and tbh, I don't think any of the current
committers spend enough time in numerical analysis in Java to be able to
do that math properly. I know I don't, and my degree was 3 years of
nothing but maths].

> 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.

+1. I think you've described the meme perfectly.

> 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.

Some subpackages in Lang will grow too big for their commonness-booties.
At that point they need to enter discussion like this to find out if it's
time to leave home, or whether to make an extension project etc. ie)
java.lang.Math is in [lang], but java.math.Xxx is in [math].

[functor] is already near that point, so I can see reasons for it to be in
and/or out. Nothing else described in previous emails is near to leaving
home [I reckon].

> First, the things in [lang] are normally simple, so they mature quickly.
> Hence there are less demands for frequent releases.

Good point. Some of it gets rocket-sciencey [to me] due to class-loaders
and stuff, but generally the code is simple.

> 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.

You've contributed a lot to Lang (and should be a committer probably).
Your opinions have complete weight I think.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>