Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [beanutils] PROPOSAL: eliminate core dependency on collections
From: Simon Kitching <simon@ecnetwork.co.nz>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <409B2183.4040200@apache.org>
References: <B789CA10-9F91-11D8-85CD-003065DC754C@blueyonder.co.uk>
	 <LAEMKBGKGGDLCMAKICOPCECEEJAA.martinc@apache.org>
	 <409B2183.4040200@apache.org>
Content-Type: text/plain
Message-Id: <1083911825.2118.40.camel@pcsimon>
Mime-Version: 1.0
Date: Fri, 07 May 2004 18:37:05 +1200
Content-Transfer-Encoding: 7bit

On Fri, 2004-05-07 at 17:41, matthew.hawthorne wrote:
> Martin Cooper wrote:
> > I'm not going to -1 this, because it seems clear that there is support for
> > it, but frankly I just don't understand the mentality that says it's a good
> > thing to *not* share components that were designed from the get-go to be
> > shared. Bizarre.
> 
> 
> I agree with you.  I think that a primary motivation behind these types of
> efforts is a similar complaint from users:
> "you commons guys just produce too many jars".
> 
> If Maven had a clever way of automatically picking up runtime 
> dependencies, then
> I don't think this would be so much of a problem.   In general I think 
> people are sick
> of, for example, wanting to check out [digester], but then getting a 
> NoClassDef and
> needing to grab [beanutils], then [collections], then [logging], etc.
> 
> One part of me wants to disregard this philosophy as a guise for 
> laziness and
> misplaced focus (due to obsessing over jar file sizes instead of solving 
> what I
> consider to be 'real' problems).  But, people do seem to care about this 
> -- I'm
> just still struggling to understand why.

I see the following types of motivation:

1.
The tomcat team want to avoid the situation where (for example)
BeanUtils depends upon collections-3.0, and some other library they use
depends upon collections-2.1. This is a valid requirement, and one that
is also biting me. 

One solution is for libraries like BeanUtils and Digester to break the
dependency on libs like collections by copying a few classes and
renaming them. Obviously this carries its own dangers, but done
carefully (only a few classes, only very stable classes) can help this
problem. And even more unfortunately, BeanUtils can't do this just now
because a direct reference to a collections class slipped into the
public API. I considered breaking the Digester->BeanUtils link by
copying/renaming classes and decided against it because the dependencies
were more than a few stable classes; I'm sure any such proposal would
have been shot down by others anyway, for exactly these reasons.
Moderation in all things applies to software development too :-)

Another alternative would be to use .NET instead, which allows multiple
versions of libraries to be loaded in parallel. Yes, java classloaders
can do this in *some special circumstances* (eg allowing libraries in
different webapps to be loaded in parallel) but it isn't useful in the
general case, because classes are loaded using classpaths not library
"signatures".

2.
People wanting to build applets and webstart apps want to minimise the
amount of library code bundled with their app. This is a reasonable
requirement.

I think the general solution is for them to build their own jars with
just the classes they desire. Unfortunately this is can be tricky to do
without leaving out something important. A tool like GenJar which
computes class dependencies can help enormously, but has the issue that
dynamically-loaded classes and concrete implementations of interfaces
can be important but aren't explicit dependencies of their using
classes. I suggest that Jakarta can resolve this by providing sets of
GenJar configuration files for various purposes. [See the discussion on
"pruners" recently].

3.
People wanting a large "all-in-one" jar because they value convenience
over disk space. While this has *some* relevance, I don't think it
scales either for the development teams or the users. Jakarta will have
troubles producing internally consistent "all-in-one" distributions, and
internally inconsistent bundles won't help the users. The issues in (1)
re inter-library-dependencies apply to any attempt to create an
all-in-one jar.

I think maven's dependency downloader helps here a little; I would like
to see a standalone tool that could be run to autodownload all
dependencies for project X (eg tomcat or digester or geronimo) into a
local directory, from the ibiblio repository or similar. Hmmm.. sounds
like apt-get for java??

4.
The Geronimo team who appear to be concerned about a few mbytes of disk
space usage when building a j2ee server. I'm still struggling to
understand why this is an issue too. But if they really want to behave
like category (2) above, then I suggest that the best way forward is to
apply the same solution recommended for (2).


I guess the recent proposal to bundle the (un-renamed) ArrayStack class
from collections with BeanUtils falls into (2) or (4). I initially voted
+1 on this, but have to admit I'm starting to rethink this. This
particular case does have some redeeming features, in that ArrayStack is
a very stable class and so bypasses *in this case* the concerns
expressed by Martin Cooper. And it's only a temporary solution until
BeanUtils 2.0 which will remove the dependency on this class from the
public API. But I would agree it's not a good precedent.


Ok, feel free to tear into my arguments :-)

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org