On Wed, Mar 16, 2005 at 05:40:22PM +0100, Wolfgang Baer wrote: > > From: Robert Lougher <[EMAIL PROTECTED]> > To: Wolfgang Baer <[EMAIL PROTECTED]> > Date: Wed, 16 Mar 2005 16:08:49 +0000 > Subject: Re: libbsf-java > > Hi again, > > > The statement of better choice is here maybe a bit out of context. gij, > > kaffe or sablevm are in the case of using the vm to BUILD a package for > > DEBIAN the (normally) only choice. But that has nothing to do with > > the quality or fitness for a given task of jamvm at all. > > > > That is just because of the debian policy which states that a package > > must be buildable from source on all debian arches. As jamvm is > > currently not available on all arches the consequence is that if > > I use jamvm for BUILDING my package on i386 and a user / other developer > > tries to build it from source on arches without jamvm it will fail and > > therefore we get a release critical bug for it. > > > > Yes, sorry, I understand this, and I know I'm going to get flamed for > my reply now. I've seen rumours that Debian may drop support for the > more "obscure" architectures. If this goes ahead I'll only have to do > a version for AMD64 and IA64 :)
Dont believe any rumors and make no decisions based on them. It will be no real *DROP* and we will still need to support them all. > The difficulty (once 64-bit support is done) with porting JamVM to > these architectures is the calling convention. Other VMs (e.g. > SableVM) rely on libffi to do this portably. I prefer to instead use > hand-coded routines for each architecture/platform (using assembler), > to make calling JNI methods as efficient as possible -- JNI is > notoriously inefficient as it is. > > Would you mind forwarding this to the list? I replied via gmane last > time, as I'm not subscribed. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
