trouble building libgcj on FreeBSD 2.2.7
Mon May 17 09:43:00 GMT 1999
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
> 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.
More information about the Java