From: "Sean Russell" <ser / germane-software.com>
> Nat Pryce wrote:
>
> > It is a completely fair comparison, and has nothing to do with defining
> > multiple Java classes in a single Java source file.  This is about
> > packaging code for *deployment*.
>
> I'm sorry?  Why would the client ever care about the deployment??

I'm talking about *packaging* classes for deployment.  Client code doesn't
care about how classes are deployed (e.g. which directory are JAR or Ruby
files put in, how does the administrator put them there, etc.) .However,
Ruby code does care about the name of the Ruby file in which a class is
deployed, while Java code it does not care about the name of the JAR file in
which a class is deployed.

> > In Java you can move classes between JAR files without changing client
>
> And this happens... how often?  Never?
>
> I've never moved a class from one jar to another without having to change
> the package name.  If I move something from client.jar to common.jar, I'm
> also invariably changing includes from *.client to *.common.

This is important when deploying components, especially if they are
downloaded across the network.  I have done this fpr an application that
dynamically loads Java components that implement network protocols.  Network
protocols are composed from components that implement pieces of protocol
functionality -- virtual connections, reliability, compression, encryption,
multiplexing, fragmentation/reassembly and so forth.  The reference of a
service contains a description of the protocol by which the service is
accessible.  When an application binds to a service, it dynamically loads
and composes protocol components to implement a compatible protocol.
Protocol components are defined by Java classes bundled in JAR files, and
are downloaded from repository as required.

There is a speed trade off between bundling lots of components in a single
JAR file and bundling components in different JAR files.  Bundling multiple
components in one JAR file increases startup time for applications that use
only a few of those components because they have to download code for
components they do not use.  On the other hand, bundling components in
several JAR files decreases startup time for applications that only use a
few components, because they download less data across the network, but
increases startup time for applications that use all the components, because
they have to make more network requests (e.g. via HTTP), and so there is
greater overhead due to connection establishment, HTTP headers, TCP slow
start, and so forth.

Therefore, we had to tune the packaging of classes into JAR files to
decrease startup time for different client applications.  In Java you can
easily do this because client code does not depend on the file in which a
class is packaged. But if you tried to do this in Ruby, you would have to
change clients of a class whenever you moved it from one Ruby file to
another.

> > code. In Ruby you have to change require statements in client code if
you
> > move a class from one Ruby file to another.
>
> Same with Java.  It is *much*, *much* more common for people to have to
> change the package names than it is for them to move classes from one Jar
> to another.

During refactoring, yes.  But not after deployment.

Cheers,
            Nat.