
Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
>> Seems that you refer to this article:
>> http://java.sun.com/developer/technicalArticles/Programming/TurningAnApplet/
>
> I really don't remember :-) But that one looks indeed like a good start.
For hosting an existing applet (with no source) in an application,
I agree, but the OP has the means to go a much easier route.
Since they control the code, they can implement it this GUI as a
Container/(J)Panel which can then be used in whatever it is needed.
Note that article ends with..
"The AppletStub technique is easier to do than rearchitecting, "
*
"...but may still not work completely if your applet depends on the
AppletContext for anything. "
Implementing an applet context that is even half way reasonable
is no easy matter. I wrote one that went slightly further than
the applet context provided for the applet viewer (mine hooked in
to BrowserLauncher to implement showDocument(URL)), but that took
some time to get right, and did not go to the more complex
abilities such as getting an enumeration of all applets (only one
could be opened at a time anyway), getting the stream keys, etc..
When you consider how tricky it is to reimplement some of
the aspects of the applet context that are commonly used by applets,
it becomes clear that it is easier to do the GUI as a Container
and use it as and when necessary, whether that usage is in a
(J)Applet, (J)Frame, (J)Window, (J)Dialog, another Container or
(J)Panel *or* JOptionPane.
* And I disagree with '..easier to do than rearchitecting,'
(unless you lack the source to the applet) because most applets
_do_ depend on the applet context.

Signature
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane