RFC: micro-libgcj merge proposal

[Dalibor Topic]

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