Java Threads mailing list archive

Re: Thread.stop, suspend and resume deprecation in 1.2

Peter etc.

> If you have the JDK 1.2 documentation, what does it tell you to use
> instead of  Thread.suspend etc.?

1. I signed up on the list
   rt-j@nist.com (by sending an e-mail to lisa.carnahan@nist.com)
   It seems like some big guys (+me:-) participate there.

2. That is where the url was issued that has an example of how to =

   do it:
   =

http://java.sun.com/products/jdk/1.2/docs/guide/misc/threadPrimitiveDepreca=
ti
on.html

3. Anyone registering is allowed to raise their voices (I checked it, =

   however I haven't had anything useful to add yet..)
   It needs our experience, they are wrestling with necessary(?) low-
   level things.

Here is a summary of last days' letters receiced today:

---------------------------------------------------------------------------=
--

OK, the discussion on this thread seems to have
died down, so I thought I'd summarize for the list(s).

Initially, Franklin Reynolds expressed concern that Thread.stop() (and
friends) had been deprecated in the Java Platform (specifically in JDK 1.2)=
,
but that no satisfying alternative had been proposed.  I responded, saying =

that
Thread.stop() is inherantly problematic, and that it never really did
what it claimed.  I stated that I know of no acceptable alternative.

Several people (Ted Baker, Simon Waddington, and Kevin Nilsen) suggested
mechanisms that were all variants on some kind of scoped "atomic" block,
where code executing within the block cannot receive asynchronous
exceptions.  Kevin's post included details like checks to ensure that
the atomic block can only execute for a fixed, maximum amount of time.

This is goodness.  It has certainly given me some issues to ponder!

Thanks,
--
Bill Foote                                  bill.foote@eng.sun.com
Real-Time Java VM Group, Sun Microsystems   http://java.sun.com/people/bill=
f/

---------------------------------------------------------------------------=
--


Oyvind