Compiling "static" applications with SWT/GTK

Andrew Haley aph@redhat.com
Wed Dec 3 18:46:00 GMT 2003


Scott Gilbertson writes:
 > Bryce wrote:
 > > My idea for static applications is to have a
 > > runtime option that dumps out a list of classes that are actually
 > > initialized/used by the application, which is then fed back into the
 > > compiler (and maybe combined with some static analysis) to generate an
 > > optimized static executable that contains only the required bits of the
 > > runtime. JET has a deployment/control panel application that does
 > > something like this.
 > 
 > 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.

We already know that people are creating interactive systems that make
heavy use of reflection.  We can't statically compile these programs
without either jumping through some hoops or using whole-archive.
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.

Andrew.



More information about the Java mailing list