(no subject)

[cbj]

Sender: address@hidden
To: Bryce McKinlay <address@hidden>
Cc: address@hidden,  Artur Biesiadowski <address@hidden>,
          ClassPath List <address@hidden>
Subject: Re: Classpath <-> gcj integration
References: <address@hidden> <address@hidden> <address@hidden>
From: Brian Jones <address@hidden>
Date: 03 Jan 2001 18:32:24 -0500
In-Reply-To: Bryce McKinlay's message of "Thu, 04 Jan 2001 11:34:51 +1300"
Message-ID: <address@hidden>
Lines: 23
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Bryce McKinlay <address@hidden> writes:

> Tom Tromey wrote:
> 
> > Some classes probably can't be merged.  For instance, we aren't going
> > to give up our String class, which is very dependent on libgcj (but
> > also very efficient).  Sometimes other changes touch on this sort of
> > thing.
> 
> It would be desirable for the set of classes which are "VM dependent" in
> classpath to be changable on a per-VM basis rather than being an all or
> nothing thing. So when doing a gcj build of classpath, the fast
> CNI String implementation would be used, but there'd still be a default,
> pure-java implementation in the base java/lang directory.

Funny, I had the same thought floating in my head this morning.  So
yes, we need to make it easy for VMs to provide their own
implementations of anything... I'd probably suggest some approach
similar to how tests are defined in a file or variable that should or
should not be included in mauve.

-- 
Brian Jones <address@hidden>