Re: RFC: micro-libgcj merge proposal

[Mike Emmel <mike dot emmel at gmail dot com>]

On 13 Jan 2006 14:17:49 -0700, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:
>
> Bryce> As far as the class libraries are concerned, I'm really not sure that
> Bryce> the benefits of a single source base justify the maintenance overhead
> Bryce> of preprocessing. If we are talking about something along the lines of
> Bryce> CLDC vs J2SE, the differences are dramatic enough that attempting to
> Bryce> build one of the other though preprocessing would quickly become very
> Bryce> messy.
>
> I think there is an empirical question here -- which approach costs
> less in which development scenarios.  Not that we know the answer :-)
> But it doesn't strike me as a sure thing in either direction.
>
> Bryce> It also means, in the absence of a preprocessing standard for Java,
> Bryce> that the classpath source would become incomprehensible to 3rd-party
> Bryce> development tools.
>
> Per's solution neatly avoids this.  Though the question of
> comprehensibility to developers is still open :-)
>
>
> Another question I have in this area: what is the viability, or not,
> of post-processing instead of pre-processing?
>
> Tom
>

Just to add something here my experience has been that outside of the
core java-lang
subset thats supported which is vm dependent the implementation of
various classes diverges dramatically from the J2SE implementation
generally because of a move to native code in many cases which causes
radical cascading changes. So I expect the amount of code that
actually overlaps will be small and restricted mainly to the core
java/lang classes which don't change much anyway. The one exception I
can think of would be java/utils that could be preprocessed but in the
case of the micro lib how much of that is intresting is probably
highly variable and its not clear the design is the best for a
embedded problem. In any case on the java side I'd suggest start with
a new set of classes then if preprocessing is of interest introduce it
later. Finally since its up to the micro maintainer to fix breakage
its agian easier to keep a new set of classes and upgrade on a
different scheduale.

As a simple example consider something as simple as java.lang.String
in a embedded environment you probably need only consider utf8
encodings which massivly simplifies a lot of the infrastructure that
supports String conversions but the source could diverge significantly
from the J2SE.

Mike