RFC: micro-libgcj merge proposal

[David Daney]

Joel Dice wrote:
> Hi all.
> 
> The following is a brief proposal for merging micro-libgcj into the GCC
> source tree.  Comments and suggestions are welcome.
> 
>  - Joel
> 
> 
> Proposed Changes
> ----------------
> 
> * Add two new build options:
>     --[enable|disable]-micro-libgcj
>            Enable/disable lightweight libgcj build.
> 
>     --[enable|disable]-micro-synchronization
>            Enable/disable lightweight, nonstandard synchronization based
>            on java.lang.Syncronizable interface.  This option is enabled
>            by default when --enable-micro-libgcj is specified, but may
>            be enabled or disabled independent of that option.
> 
> * Add preprocessor directives to various native source files (*.cc) under
>   the libjava directory of the following forms:
> 
>     #ifndef ULIBGCJ
>       ... // code that should not be included in the micro-libgcj build
>     #endif
> 
>     #ifdef ULIBGCJ
>       ... // simplified version of code for micro-libgcj build
>     #else
>       ... // full-featured and/or high-performance version for normal
>           // build
>     #endif
> 
>   Note that these directives would not need to appear in any Java source
>   files, nor in any files not included in the micro-libgcj build at all.
>   Also, few if any header files should require any such directives.  I'm
>   afraid I can't provide an exact list of files affected until I've
>   actually done the merge.
> 
> * Add a new subdirectory under libgjava called micro-libgcj which will
>   contain a separately-maintained set of Java files representing
>   micro-libgcj's classpath (a subset of java.lang.* and java.util.*).
> 

Q: Who gets to decide what is in micro-libgcj?

For libgcj it is clear:  We try to duplicate the Sun runtime APIs.

For micro-libgcj, I already have a preliminary set of patches.  Should I 
be the one who decides?

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.

Before adding this to GCC, I think there should be some consensus as to 
exactly what we are trying to do.

David Daney