RE: Size problem

[Jeff Sturm <jsturm at one-point dot com>]

Wow, I had no idea this was such a controversial topic!  Out of
curiosity I did a google search for "dll hell"... interesting reading,
much of it from Microsoft, even.

There are some technical differences between Window's implementation of
DLLs and traditional ELF shared libraries that may make the latter more
useful, though there's no doubt that much of the trouble starts with rogue
application installers.

Though this is becoming clearly off-topic for java, so I'll be brief...

On Mon, 13 Jan 2003, Erik Poupaert wrote:
> Passing information between executables is a bit more difficult than passing
> references (or primitives) within the same process; especially when they are
> tightly coupled. You'd either have to pass things over the command line (cum
> file system), or else you need to introduce a network protocol.

You didn't mention one of the most common way to couple applications:
through a RDBMS.  A set of applications might share data through, for
instance, a common Oracle backend database system.  This used to be the
norm for enterprise software.  I'd guess it still is.

The application we deliver to our clients depends on a shared jar file
from Oracle.  After compiling this with gcj, it is quite large:

$ size liboracle.so.8.1.7
   text    data     bss     dec     hex filename
4491364 1017388    2224 5510976  541740 liboracle.so

We could link this statically into each executable.  Like Adam says,
disk space is cheap.  However this library rarely changes, whereas we may
push out application updates to our customer once a month, over the
Internet.  Bandwidth still isn't quite as cheap as disk space.

An interesting data point for GNU/Linux users is that libgcj.so is likely
to be provided by the OS distributor eventually, as is done for libc.so
and libstdc++.so now.  That won't be very useful until libgcj is more
stable than it is today, and probably not before the binary compatibility
patches are complete.

Jeff