-
Bug
-
Resolution: Fixed
-
P4
-
1.1.7, 1.2.2, 1.3.0
-
b55
-
generic, x86
-
generic, windows_98, windows_nt
Name: mc57594 Date: 07/15/99
This may be related to a jdk 1.1 Bug Id: 4031323
[chamness]
===================================================
In JDK 1.2, an applet was permitted to interrupt a thread that was no longer alive, but in JDK 1.2.1 and now in JDK 1.2.2, this raises a security exception. Perhaps this is an unintended side effect of the applet security bug-fix introduced in JDK 1.2.1?
I'm appending a simple test applet. The test is implemented in the button action: a 'waiter' thread first waits for a 'sleeper' thread to finish and then interrupts the sleeper thread. join() is used to wait for the sleeper to finish. Sure, ordinarily one wouldn't wait for a thread to finish and then interrupt it, but the test does this to demonstrate the problem:
C:\JOEB\JAVA\InterruptTest>appletviewer Test.html
java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread )
at java.security.AccessControlContext.checkPermission(AccessControlContext.java, Compiled Code)
at java.security.AccessController.checkPermission(AccessController.java, Compiled Code)
at java.lang.SecurityManager.checkPermission(SecurityManager.java, Compiled Code)
at sun.applet.AppletSecurity.checkAccess(AppletSecurity.java:113)
at java.lang.Thread.checkAccess(Thread.java:1043)
at java.lang.Thread.interrupt(Thread.java:660)
at Test$3.run(Test.java:35)
at java.lang.Thread.run(Thread.java:479)
Note: If the join() is changed to join(1000), or removed entirely, there is no security exception because the sleeper thread will still be sleeping when it is interrupted. (But if the thread is already dead, then the attempt to interrupt throws a security exception..)
[Test.java]
import javax.swing.SwingUtilities;
public class Test extends javax.swing.JApplet {
public Test() {
getContentPane ().setLayout (new java.awt.BorderLayout ());
jButton = new javax.swing.JButton ();
jButton.setText ("Start");
jButton.addActionListener (new java.awt.event.ActionListener () {
public void actionPerformed (java.awt.event.ActionEvent evt) {
jButtonActionPerformed (evt);
}
});
getContentPane ().add (jButton, "Center");
}
private void jButtonActionPerformed (java.awt.event.ActionEvent evt) {
final Thread sleeper = new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(3000);
}
catch (InterruptedException ex) { }
}
});
Thread waiter = new Thread(new Runnable() {
public void run() {
try {
sleeper.join();
}
catch (InterruptedException ex) { }
sleeper.interrupt(); /* EXCEPTION */
SwingUtilities.invokeLater(new Runnable() {
public void run() {
jButton.setEnabled(true);
}
});
}
});
jButton.setEnabled(false);
sleeper.start();
waiter.start();
}
private javax.swing.JButton jButton;
}
[Test.html]
<HTML>
<HEAD><TITLE>Interrupt Test</TITLE></HEAD>
<BODY>
<APPLET code="Test.class" width=350 height=200></APPLET>
</BODY>
</HTML>
(Review ID: 85455)
======================================================================
This may be related to a jdk 1.1 Bug Id: 4031323
[chamness]
===================================================
In JDK 1.2, an applet was permitted to interrupt a thread that was no longer alive, but in JDK 1.2.1 and now in JDK 1.2.2, this raises a security exception. Perhaps this is an unintended side effect of the applet security bug-fix introduced in JDK 1.2.1?
I'm appending a simple test applet. The test is implemented in the button action: a 'waiter' thread first waits for a 'sleeper' thread to finish and then interrupts the sleeper thread. join() is used to wait for the sleeper to finish. Sure, ordinarily one wouldn't wait for a thread to finish and then interrupt it, but the test does this to demonstrate the problem:
C:\JOEB\JAVA\InterruptTest>appletviewer Test.html
java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread )
at java.security.AccessControlContext.checkPermission(AccessControlContext.java, Compiled Code)
at java.security.AccessController.checkPermission(AccessController.java, Compiled Code)
at java.lang.SecurityManager.checkPermission(SecurityManager.java, Compiled Code)
at sun.applet.AppletSecurity.checkAccess(AppletSecurity.java:113)
at java.lang.Thread.checkAccess(Thread.java:1043)
at java.lang.Thread.interrupt(Thread.java:660)
at Test$3.run(Test.java:35)
at java.lang.Thread.run(Thread.java:479)
Note: If the join() is changed to join(1000), or removed entirely, there is no security exception because the sleeper thread will still be sleeping when it is interrupted. (But if the thread is already dead, then the attempt to interrupt throws a security exception..)
[Test.java]
import javax.swing.SwingUtilities;
public class Test extends javax.swing.JApplet {
public Test() {
getContentPane ().setLayout (new java.awt.BorderLayout ());
jButton = new javax.swing.JButton ();
jButton.setText ("Start");
jButton.addActionListener (new java.awt.event.ActionListener () {
public void actionPerformed (java.awt.event.ActionEvent evt) {
jButtonActionPerformed (evt);
}
});
getContentPane ().add (jButton, "Center");
}
private void jButtonActionPerformed (java.awt.event.ActionEvent evt) {
final Thread sleeper = new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(3000);
}
catch (InterruptedException ex) { }
}
});
Thread waiter = new Thread(new Runnable() {
public void run() {
try {
sleeper.join();
}
catch (InterruptedException ex) { }
sleeper.interrupt(); /* EXCEPTION */
SwingUtilities.invokeLater(new Runnable() {
public void run() {
jButton.setEnabled(true);
}
});
}
});
jButton.setEnabled(false);
sleeper.start();
waiter.start();
}
private javax.swing.JButton jButton;
}
[Test.html]
<HTML>
<HEAD><TITLE>Interrupt Test</TITLE></HEAD>
<BODY>
<APPLET code="Test.class" width=350 height=200></APPLET>
</BODY>
</HTML>
(Review ID: 85455)
======================================================================
- duplicates
-
-
- Closed
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-