🚀 go-pugleaf

Here's a snippit from : <http://java.sun.com/products/jfc/tsc/swingdoc-current/911.html>



Q: Why does my applet cause a warning message to be printed  on the browser's
"Java Console?"

A: Most browsers unconditionally print a console message when  Swing makes its on-
time AWT system event queue check; IE4 prints a backtrace,  and Navigator prints a
short message.

If you're deploying an applet that does not serve double duty as part  of an application,
you can short-circuit the event-queue check by setting  a special property on the
 JApplet's root pane, using a technique similar  to this:

                /* This will prevent the "SystemEventQueue"
                * access message from appearing in the Java console
                * when this applet is run in a browser. */
                applet.getRootPane().putClientProperty
                   ("defeatSystemEventQueueCheck", Boolean.TRUE);


ken wrote:

> I know I'm wrong, I just want someone to TELL me I'm wrong - and to show
> me why.
>
> I'm having trouble getting a response to the following observation that
> I've posted about a few times.
> It appears to me that if you write APPLETS  in Swing, then even if you
> DON'T attempt to escape the sandbox, you still have to take on all the
> painful, browser-specific security measures (such as applet-signing and
> the inclusion of calls to various incompatible security packages.) And I
> find
> this outrageous, if it's really true.
>
> I'm forced to this conclusion by the fact that I decided some time ago
> that the whole security thing was a mess, and I decided to take every
> measure necessary to avoid it for as long as I could. Functionally, my
> applet did not require me to escape the sandbox to do its job.
>
> Because I had a background in Swing application development, I decided
> to implement my applets in Swing. I discovered that the architecture of
> Swing is such that ANY applet (that fires an event - and what
> non-trivial applets don't?) MUST exceed the constraints normally placed
> on applets, and therefore, you cannot deploy applets written in Swing
> without having to take these extra security measures.
>
> I posted the following angry  rant to JDC's GroupReader/Toolbar. To date
> it has generated (0) responses. There are two short messages, followed
> by my (probably erroneous) reasons for
> stating the above.
>
> kbarclay
> kebarcla@hotmail.com
>
> Path: developer.java.sun.com!unseng
> From: unseng
> Newsgroups: swing
> Subject: Swing: checked access to system event queue.
> Date: Mon Aug 03 13:41:15 PDT 1998
> Organization: Java Developers Connection
> Message-ID: <289024973$815@developer.java.sun.com>
> JDC-state: closed
> JDC-points: 1
> JDC-notify: true
> NNTP-Posting-Host: developer.java.sun.com
>
> Hi:
>
> Does Anyone know that what is that means? "Swing: checked access to
> system event queue."
> That is generated by initialization of my JApplet. Is that related to
> signed and unsigned applet?
> My program also threw a AppletSecurityException as
> "checkawteventqueueaccess". This exception is
> thrown when the program tried to pop-up a dialog box.
>
> The Dialog box is created by below code:
>
>  int userAnswer = JOptionPane.showInternalConfirmDialog(
>     this,
>     "Save the changes to this window?",
>                            "Save Changes",
>                            JOptionPane.YES_NO_CANCEL_OPTION,
>     JOptionPane.WARNING_MESSAGE);
>
> Is anyone known how to work around with it???
>
> Thanks in Advance
>
> Seng
>
> Answers
> ======
>
> ** From: heyhey
> Replied: Tue Aug 04 00:04:08 PDT 1998
>
> This is known behaviour.
> Read swing's file
>
>   CHANGES.TXT
>
>  section
>
> ==============
>  Applet Changes
> ==============
>
> ** From: kbarclay
> Replied: Tue Aug 04 09:56:36 PDT 1998
>
> heyhey suggests the old "hack" of putting
>
> applet.getRootPane().putClientProperty("defeatSystemEventQueueCheck",
> Boolean.TRUE);
>
> in your applet code to subdue the security exceptions. I found this 100%
> ineffective in solving the
> security problems; in fact, it doesn't even quiet the salacious little
> warning that says:
>
> "Swing: checked access to system event queue."
>
> Maybe I'm not placing it in the correct location? I tried the init
> method, and ...and  the little test applet
> I put this in is only a dozen lines long, so there aren't many other
> places to put it.
>
> This applet comes with the Swing release: it's called SwingApplet.java.
> I pared it down to a bare
> minimum and pasted it below so you can see that this applet really does
> almost nothing except
> put a button onto the page. Yet when you put the little applet on a
> webserver and deploy it, when
> you stab the little button, you get (in IE4.0) the stack trace that I've
> pasted below the code.
>  (It runs fine in NS4.05/preview release.)
>
> Since IE4 was written by the Evil Empire I looked in The Java Class
> Libraries Vol 1 by Chan and Lee
> to see what behavior is specified in these circumstances. From what Sun
> says should be happening,
> it appears that Microsoft's VM is doing what it should, and Netscape's
> is failing to throw an
> exception. On page 1485 it says:
>
> "Gaining a reference to the system event queue has security
> implications. This is because with
> the reference, you can read the queue's contents or post events to it."
>
> That makes sense. You obviously can't have any old applet posting events
> to your event queue.
>
> Let me see if I understand correctly the implications of this.
>
> 1) Swing is written in such a way that, as a matter of fact, when an
> event is fired, it needs to get a
> reference to the event queue.
> 2) Getting such a reference is a *privileged* operation - like making a
> socket connection to a
> computer other than the applet's host, or reading/writing files on the
> user's computer.
> 3) Therefore, any applet written in Swing, no matter how trivial,
> requires that one go through all
> the contortions that are necessary when you're trying to produce an
> applet that can "break out of
> the sandbox."
>
> Because this is insane, I KNOW I must be wrong.
>
> I just know that any day now, someone  at the forefront of Swing
> development is going to tell me that
>  I can write applets in Swing that don't try to escape the sandbox
> without having to go through the
> SOLID NIGHTMARE of having to sign my applets using two (or is it three?)
> incompatible applet
> signing tools, and/or download two incompatible sets of security classes
> (Microsoft's
> com.ms.Security classes from SDK 3.0, or Netscape's security classes)
> and then keep two
> completely separate sets of code for each of the two predominant
> browsers.
>
> It doesn't seem reasonable to me that my users can't just hit a page
> with an applet embedded
> in it and have it download and run. It's not reasonable that I have to
> go through Security Hell in
> my applet development process if I'm not trying to escape the sandbox.
>
> My users should not have to download a five-meg plugin to run my applet.
> They shouldn't have
> to copy jar files to some directory that's visible to their browser, or
> tweak security settings in
> various dialogs in their browser. And they are, as a matter of fact,
> evenly divided between
> IE4 and Netscape! To me that means avoiding RMI and any other package
> Microsoft doesn't
> want to support. Users don't care if you use sockets and streams or if
> you use RMI. They DO
> care if they have to download a giant plugin before running your applet.
>
> I'm running Swing 1.0.3/jdk 1.1.6 on an NT Box.
> If anyone knows how to run the following 12 lines of code in IE4 without
> throwing security
> exceptions, please email me or post.
>
> Thanks,
>
> Ken
> kebarcla@hotmail.com
>
> /*
>  * @(#)SwingApplet.java 1.9 98/02/23
>  */
>
> import java.awt.*;
> import java.awt.event.*;
> import java.net.*;
> import java.applet.*;
> import com.sun.java.swing.*;
>
> /**
>  * A very simple applet.
>  */
> public class SwingApplet extends JApplet {
>
>     JButton button;
>
>     public void init() {
>
>         getRootPane().putClientProperty("defeatSystemEventQueueCheck",
> Boolean.TRUE);
>
>         getContentPane().setLayout(new FlowLayout());
>         button = new JButton("Hello, I'm a Swing Button!");
>         getContentPane().add(button);
>     }
>
>     public void stop() {
>         if (button != null) {
>             getContentPane().remove(button);
>             button = null;
>         }
>     }
> }
>
> The stack trace is:
>
> com.ms.security.SecurityExceptionEx[com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue]:
>
>  Event queue access denied.
>  at com/ms/security/permissions/UIPermission.check
>  at com/ms/security/PolicyEngine.deepCheck
>  at com/ms/security/PolicyEngine.checkPermission
>  at com/ms/security/StandardSecurityManager.chk
>  at com/ms/security/StandardSecurityManager.checkAwtEventQueueAccess
>  at java/awt/Toolkit.getSystemEventQueue
>  at com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue
>  at com/sun/java/swing/SystemEventQueueUtilities.postRunnable
>  at com/sun/java/swing/SwingUtilities.invokeLater
>  at com/sun/java/swing/RepaintManager.queueWorkRequest
>  at com/sun/java/swing/RepaintManager.addDirtyRegion
>  at com/sun/java/swing/JComponent.repaint
>  at java/awt/Component.repaint
>  at java/awt/Component.repaint
>  at com/sun/java/swing/plaf/basic/BasicButtonListener.stateChanged
>  at com/sun/java/swing/AbstractButton.fireStateChanged
>  at com/sun/java/swing/AbstractButton$ButtonChangeListener.stateChanged
>  at com/sun/java/swing/DefaultButtonModel.fireStateChanged
>  at com/sun/java/swing/DefaultButtonModel.setRollover
>  at com/sun/java/swing/plaf/windows/WindowsButtonListener.mouseEntered
>  at java/awt/Component.processMouseEvent
>  at java/awt/Component.processEvent
>  at java/awt/Container.processEvent
>  at java/awt/Component.dispatchEventImpl
>  at java/awt/Container.dispatchEventImpl
>  at java/awt/Component.dispatchEvent
>  at java/awt/LightweightDispatcher.retargetMouseEvent
>  at java/awt/LightweightDispatcher.setMouseTarget
>  at java/awt/LightweightDispatcher.processMouseEvent
>  at java/awt/LightweightDispatcher.dispatchEvent
>  at java/awt/Container.dispatchEventImpl
>  at java/awt/Component.dispatchEvent
>  at java/awt/EventDispatchThread.run
> Swing: checked access to system event queue.
> Microsoft (R) VM for Java (tm), 4.0 Release 4.79.0.2339
>
> POSTSCRIPT:
>
> In the readme.txt file that comes with SwingApplet.java, it says:
>
> "When you successfully run the applet, you might see a message about a
> security exception.  It starts like this:
>
>    sun.applet.AppletSecurityException: checkawteventqueueaccess
>
> Please ignore this exception."
>
> And I most willingly DO ignore the exception when it's put out by the
> appletviewer. When I actually
> try to do stuff in a more sophisticated applet, though, and try to run
> it off my webserver, it throws
> the exception above and chokes.