Re: RFC: micro-libgcj merge proposal

[Dalibor Topic <robilad at kaffe dot org>]

David Daney wrote:
> Per Bothner wrote:
>
> > David Daney wrote:
> >
> > > Q: Who gets to decide what is in micro-libgcj?
> > > ...
> > > I cannot use micro-libgcj if it contains too small a sub-set of 
> > > libgcj.  Likewise I don't want it to be too big.  My requirements do 
> > > not cleanly fit into any of Sun's J2ME profiles so I don't want that 
> > > either.
> >
> >
> >
> > That is why we need pre-processing.  At configure time you select a
> > "profile" - either a "standard" named profile or a custom profile.
> > Each profile sets set of pre-processor flags, such as
> > "+java.lang.ClassLoader" (if the profile includes ClassLoader support)
> > or "-java.lang.ClassLoader" (if it doesn't).  Then at 'make' time
> > (though it could be 'configure' time, I guess) we run a pre-processing
> > filter and the normal .java files to give the modified files in a
> > separate directory, before compiling the latter.
>
>
> Well I like Per's proposal.  I think something like this would be 
> extremely useful.  However it does not seem like that is what is being 
> proposed.

On the face of possibly being unrealistic, but wouldn't what Per 
proposes be implementable at the bytecode level, without requiring 
preprocessing at all? I'd imagine a switch like '-java.util.Hashtable' 
to go and purge all fields & methods using java.util.Hashtable 
recursively, until a 'slice' of the classes without any hashtable 
invocation is left over.

Or is that too weird an idea to be useful?

cheers,
dalibor topic