Sender: [EMAIL PROTECTED]
To: Bryce McKinlay <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Artur Biesiadowski <[EMAIL PROTECTED]>,
ClassPath List <[EMAIL PROTECTED]>
Subject: Re: Classpath <-> gcj integration
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
From: Brian Jones <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
