commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [pattern][lang] Cross dependecy
Date Sat, 10 Aug 2002 05:12:04 GMT

On Fri, 9 Aug 2002, Stephen Colebourne wrote:

> So I've had a look at this dependency, and here's my new opinion:
> NestableExceptions are a pattern (class, not interface based)

The pattern being a part of java.lang in JDK 1.4.

> Enum is a pattern (class, not interface based)

This does fit the pattern structure. It's an abstract specification that
[patterns] provides and the user has to inherit to get any functionality.
Also not in [lang] yet.

> Serialization utilities are to do with a pattern interface (Serializable) -
> (not quite sure why I didn't see this earlier...)

But it's a pattern that is in java.lang, not in org.apache.commons.patterns.

> If you do a hypothetical move of Nested Exceptions and Serailization to
> [pattern], you end up with two completely independent projects. [lang] is
> also neater - it only has static method classes plus String and Number
> ranges.

When a reflect component is added to [lang], will [patterns] refactor
to use this?

> 2) Merge [pattern] into [lang], using c.a.c.lang.pattern-name packages
> 3) Leave as is, [pattern] dependent on [lang]

I don't know if this is bad currently. We don't have a circular dependency
as yet and no classes I'm aware of which would cause such a thing.

> After much thought, I _really_ do prefer #2:
> - it makes [lang] more compelling
> - it follows what Java does (Serializable/Comparable are in java.lang)
> - it avoids this argument occurring each time we have something new to add
> - [pattern] would remain in the sandbox as a staging ground for trying out
> new patterns
> I've tried to think of some possible downsides:
> - [pattern] is immature - well I would suggest only Predicate, Transformer,
> Command and Factory for [lang] 1.0. These are long established from
> [collections] and fairly uncontroversial patterns
> - [lang] becomes diluted - I actually think it strengthens [lang] with
> broader appeal. Only a single Utils class must be allowed for each pattern
> though, this will control bloat.
> So, can we move for #2 - merge appropriate parts of [pattern] into [lang] ??

* It complicates things. To get functionality you have to understand the
  concepts of each pattern and implement it etc.

* It has the danger of getting the problem that Avalon kinda suffers from,
  that of being a framework of rules rather than just some helpers. This
  seems to create a barrier to using it as it has a steeper learning

On the other hand though....

* It does help to grow the scope of Lang, which helps in that Lang is more
  interesting to consumers and it has more supporters using it.

* I'm mentally tired and easily swayable at the moment :) S'been a tough

What I would like to suggest is that we continue with our plans for Lang
v1.0, with the Enum class in there, with reflect code and hashcode stuff.

Patterns continues to grow and mature. Whether patterns should release an
internal jar as such for collections or io or somesuch to be dependent on
I don't know. It would be nice. Possibly IO could be depentdent on it.

IO is worked on, made dependent on [lang] and [patterns] towards the aim
of a 1.0 release.

Lang 2.0 to include all mature components of [patterns].

IO 1.0 released, dependent on Lang 2.0.

Collections n.0 released, depending on the patterns in Lang 2.0.


In other news... [util] is figured out and either released as is or merged
into lang at 2.0.


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

View raw message