Re: Compiling "static" applications with SWT/GTK

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Dec 4, 2003, at 7:44 AM, Andrew Haley wrote:

> > Andrew wrote:
> > > Not a bad idea, but this seems very fragile.  How would anyone know
> > > for sure which classes an application needed?  A few test runs
> > > wouldn't do it.
> >
> > It depends on the application.  Many embedded systems, for example, 
> > have a
> > limited and well-defined feature set, so you don't need very many 
> > runs to
> > exercise everything.
>
> Sure, and it's not a bad solution for some specialized application
> areas.  However, it's not any kind of a general solution to the
> problem -- all you need to make it fail is to open a menu that hadn't
> been opened during testing, and boom.  This is not an argument against
> having such a facility in libgcj, but it's not sufficient.

Yeah. It would still require human interaction to some degree. I 
envisage something like a build profile optimizer in eclipse that tells 
you which classes are statically reachable, and which were actually 
used by a test run of your program. By default it would include 
everything reachable, as well as perhaps a set of rules like "if 
java.util.Date is used, include all the locales for Calendar/Date". But 
the developer could go through and uncheck packages and classes in 
order to create a space-optimized build.

> Sun's J2ME (TM) approach, that of modularizing the library and
> creating a number of profiles, is sound.  But we might well be able to
> do better.

With J2ME/CLDC etc, this problem is much easier, because there is no 
reflection and far less interdependence within the class libraries.

Regards

Bryce.