🚀 go-pugleaf

I've gotten it to work. You just need to make sure you are using the newest
version of SWING. 1.0 DIDNT work with applets, but 1.0.1 and later will.

In my latest applet, I've been using the Java plugin and that works quite
well in both browsers...

--Jason Cwik

ken wrote in message <35C76F4B.EEC8C141@hotmail.com>...
>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/SystemEventQueueUtil
ities.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.
>
>
>
>