Re: gcj executable size reduction?

[Michael Koch <konqueror at gmx dot de>]

Am Donnerstag, 15. April 2004 18:41 schrieb David Daney:
> David Daney wrote:
> > David Daney wrote:
> >> Per Bothner wrote:
> >>> Another (complementary) approach is reducing the
> >>> interdependencies between classes, so a static linker would not
> >>> link in quite as much junk.    This might be to be a confiuration
> >>> option, or we could support various "profiles" like J2ME.  Any
> >>> experience in untangling dependencies?
> >>>
> >>> Comments?  Where should I start?
> >>
> >> One thing I have been thinking about (but not acting on), is the
> >> interdependency problem.
> >>
> >> For some environments, security is not important, but I think
> >> there is quite a large overhead with security related classes. 
> >> Off the top of my head I would do something like this:
> >>
> >> Create a new java.lang.SecurityManager implementation where all
> >> checks just return.  This should prevent all the *Permission
> >> classes and related cruft from being linked in.
> >
> > Thinking about it more, this would not work.  We really need a
> > preprocessor for java...
> >
> > What would also be required would be to also go through all the
> > runtime's classes and hack out all AccessController usage. 
> > Although a quick grep of the sources shows that AccessController is
> > probably not used nearly as often as it should be in a standards
> > complient implementation.
>
> Nix that.  I should probably think these things out before I post. 
> Just use a dummy AccessController, and leave everything that uses it
> alone. But it looks like AccessContoller already does nothing.  So
> what you would want is the option to keep the current version if a
> working version is ever written...

Notice that by default no SecurityManager exists and now security checks 
are done. A security manager needs explicitely be set to force security 
checks. This is even true for the default sandbox.


Michael