cleanup: remove deprecated TheadGroup methods

[BradWalker]

desc: The ThreadGroup class is an artifact of by-gone days. The ability to destroy a thread group and the concept of a destroyed thread group no longer exists. Several of the methods are null functions as well as marked for removal. This cleans up the usage of these methods.

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[BradWalker]

Unsure.. Why the system created a new pull request over this..

Background can be found in #9091

[matthiasblaesing]

Thank you for the update. I still think this is a behavioral difference. I notice, that there is already synchronization in place in the addExecutionListener and removeExecutionListener methods. The fireExecutionStarted and fireExecutionFinished methods now have synchronization. If one of the execution listeners runs slow, it might now block another thread that tries to register or remove an execution listener.

[BradWalker]

Thank you for the update. I still think this is a behavioral difference. I notice, that there is already synchronization in place in the addExecutionListener and removeExecutionListener methods. The fireExecutionStarted and fireExecutionFinished methods now have synchronization. If one of the execution listeners runs slow, it might now block another thread that tries to register or remove an execution listener.

Hey Matthias, I think that I understand what you're saying. And I mostly agree. Yes, you are correct. This is probably a behavioral difference. My opinion would be that other behavior impacted should account for this as that would be proper s/w design.

Having said that, the use of the clone() method is general disfavored. So what I changed it to do is make a shallow copy of the Set and iterate on that. Same behavior as before, yet removes the SuppressedWarnings message and cleans up the code some.

[matthiasblaesing]

I'm not sure whether I agree, that clone should be replaced with the copy constructor, but I assume, that it will perform similarly.

The copy constructor call though also needs to be protected by a synchronized block, as it will read the source set. (the same would be true if the clone would stay, the current situation is broken).

[mbien]

Unsure.. Why the system created a new pull request over this..

because you pushed the branch into the netbeans repo instead of your clone?

[matthiasblaesing]

Looks sane to me. Thank you.