Re: Classpath future?

[Jeff Sturm]

On Thu, 12 Jul 2001, Etienne M. Gagnon wrote:
> > For one thing, the gcj runtime doesn't distinguish native (CNI) and java
> > code.  At the object level, they are the same.
> 
> OK.  Your point of view is really GCJ specific. My original point was 
> effectively that CNI is not a "universal" native interface that could 
> reasonably be expected from every "Classpath" compatible VM.

I don't recall anyone ever asserting that it was.  Mentioning precise
collection had strayed off topic a bit.  But I don't think you needed to
argue that CNI isn't for everyone.  It wasn't designed as a
one-size-fits-all native interface.

I understand perfectly the reasons SableVM et al cannot use CNI.

> So, you're back suggesting to scan "conservatively" and pinning.  So, 
> you agree that CNI is incompatible with precise collectors (at least, 
> moving ones).

That's not what I said.  Unless you don't consider a most-copying GC
precise or moving... but I digress (again).

> I have nothing against CNI, or GCJ.  I am just trying to discuss the 
> "real" goals of Classpath, and maybe put some pressure to resolve this 
> important yet unresolved CNI/JNI issue.

Like anything else in free software, it'll likely be resolved by patches,
not discussion... the debates are quickly lost and forgotten if not
reinforced by contributed code.

IMHO Classpath should continue to adopt both CNI and JNI implementations
as they are submitted... JNI because it is the industry standard and CNI
because it is part of GCC, a GNU project, which seems appropriate for
"GNU" Classpath after all.  But imposing any artificial requirements on
this would be awkward... not everyone who submits JNI code may have any
convenient way to test a CNI version, for instance.

Jeff