RE: Size problem, compilation performance and dll hell

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

> > Here is one advantage with .so/.dlls: reduced compilation time with 
> > many .exe files.
> 
> I've always been a proponent of using a (late-binding) 
> interpreter for development and then using a compiler for the 
> final release.  Not caring about how long compiles take 
> allows compiler writers to implement a *lot* more 
> optimizations (for example, whole-program optimizations).  I 
> really don't think that "it increases compile time" is ever a 
> very compelling argument -- you should only need to invoke 
> the compiler once per release of your software.

I don't particularly like to use one mode of the compiler for development
and another for release. I'd like to put as much testing milage as
possible on the final form of the product, e.g. the gcj -Os option 
causes my program to crash. www.excelsior-usa.com made the decision
not to have as few optimisation options as possible for this reason. 
They want there to as few code paths as possible for their Java 
native compiler. 

In our development we're using Java Web Start to distribute internal
daily builds, but we're compiling to native builds for betas. The
downside of not using native builds internally is that we discover
new bugs during beta, that really should have been caught during
development. We may ditch Java Web Start for this reason for anything
but testing.

Øyvind