Jeroen Frijters wrote: >>>Clearly a broken app ;-) It's easy to think up patterns to avoid >>>creating the actual thread until the point where you know >>you're going to run it. >> >>There could be a marginal justification for creating Thread objects at >>initialisation, way before they're scheduled to be started >>and that's on embedded or other resource constrained systems. > > Yeah, but that'll always be a fixed number so leaking them shouldn't be > a huge problem either.
Interesting discussion, but really beside the (my) point. If "it's broken but it doesn't really mostly matter" then it's still broken in my opinion. I don't presume to know how or why other programmers may want to do or not do some particular sequence of actions that trigger the bug. Of course, since the bug in in the API spec there's nothing to actually do about this unless we're willing to rewrite the spec. Perhaps we should add a comment to the Javadoc for Thread.java like "instances of Thread are not garbage collected until either they run and terminate or their ThreadGroup and all contained Threads are no longer referenced." -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
