RFC: micro-libgcj merge proposal

[David Daney]

Dalibor Topic wrote:
> 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?

The problem is to figure out what the semantics of code using Hashtable 
are and to modify the code so that it does the right thing without the 
Hashtable.

Writing a tool to do this is hard.  We highly skilled software 
professionals are abundant and could do the job at a much lower cost.

David Daney.