trouble building libgcj on FreeBSD 2.2.7

[Jeff Sturm]

Godmar Back wrote:
> > Can't do this.  Even though Thread.stop() is deprecated, removing it is
> > an API change, and the runtime will fail java compatability tests.
> 
> I'm sometimes wondering what these tests would look like, and if they
> can be backed up by the spec.

Me too... but I suspect Sun has tests to hunt down API changes. 
Microsoft's VM failed 1.1 compatibility, although their changes were
subtle.

> The behavior of Thread.stop() is completely weird.  Take, for instance,
> the fact that a thread that was stopped once will keep running if it
> catches its death, but Thread.isAlive() will return false from then on.

That's likely part of the reason Thread.stop() is now deprecated.

> >
> > 1) sounds fine to me.  Or just make it a no-op... my tests show it
> > doesn't always work anyway (e.g. you can't stop() a thread waiting for a
> > monitor).
> >
> 
> You mean you can't in libgcj or you can't in Java?
> You can in Java, and you should be able to in libgcj.

sorry... I mean that Thread.stop() can't kill a deadlocked thread in
Java.  A thread must reacquire the monitor before it can respond to
stop(), interrupt() or anything else.

-- 
Jeff Sturm
jsturm@sigma6.com