Re: statically linked executable size

[Tom Tromey <tromey at redhat dot com>]

Ranjit> What seems to happen is that we have java.lang.SecurityManager
Ranjit> that directly uses java.awt.AWTPermission.

Yeah, this is an odd special case in there.

Andrew> Now comes the question: how shall we fix this?  We can either 
[...]
Andrew> * or we can compile AWTPermission separately from the rest of AWT

I lean toward this.

We've talked about splitting libgcj.so into a few libraries before.
I think we ought to do it.  I was thinking of having 4 pieces, at
least to start with:

* AWT + Swing (and BC compiled)
* CORBA
* XML provider bits
* The rest

To make this work we have to special-case AWTPermission... there's
already a comment in makemake.tcl about this class :-)


The plus side to doing this is that we can have better startup and
lower overhead for programs which only rely on the core -- and this is
a fair number of programs.

The drawbacks that I know of are:

* Performance hit for AWT/Swing code (though we don't know if it is
  important or large enough to be noticed)
* CNI messiness with BC code
* Users would have to know to link in these libraries if they wanted
  to use them from CNI-style compiled program (or statically linked
  program)

Andrew> I've appended the fix for SecurityManager, but that doesn't help at
Andrew> all because java.text.Bidi uses java.awt.font.NumericShaper.  However,
Andrew> nothing actually _refers_ to java.text.Bidi.

I didn't know about this one... we could BC-compile Bidi.

Tom