Access Restriction Methods in ThreadGroup

The ThreadGroup class itself does not impose any access restrictions, such as allowing threads from one group to inspect or modify threads in a different group. Rather the Thread and ThreadGroup classes cooperate with security managers (subclasses of the SecurityManager class), which can impose access restrictions based on thread group membership.

The Thread and ThreadGroup class both have a method, checkAccess, which calls the current security manager's checkAccess method. The security manager decides whether to allow the access based on the group membership of the threads involved. If access is not allowed, the checkAccess method throws a SecurityException. Otherwise, checkAccess simply returns.

The following is a list of ThreadGroup methods that call ThreadGroup's checkAccess before performing the action of the method. These are what are known as regulated accesses, that is, accesses that must be approved by the security manager before they can be completed.

• ThreadGroup(ThreadGroup parent, String name)
• setDaemon(boolean isDaemon)
• setMaxPriority(int maxPriority)
• stop
• suspend
• resume
• destroy

This is a list of the methods in the Thread class that call checkAccess before proceeding:

• constructors that specify a thread group
• stop
• suspend
• resume
• setPriority(int priority)
• setName(String name)
• setDaemon(boolean isDaemon)

A stand-alone Java application does not have a security manager by default; no restrictions are imposed and any thread can inspect or modify any other thread, regardless of the group they are in. You can define and implement your own access restrictions for thread groups by subclassing SecurityManager, overriding the appropriate methods, and installing the SecurityManager as the current security manager in your application. For information about implementing a security manager, see the lesson Providing Your Own Security Manager.

The HotJava Web browser is an example of an application that implements its own security manager. HotJava needs to ensure that applets are well-behaved and don't do nasty things to other applets running at the same time (such as lowering the priority of another applet's threads). HotJava's security manager does not allow threads in different groups to modify one another. Please note that access restrictions based on thread groups may vary from browser to browser and thus applets may behave differently in different browsers.