Re: applets, applications and static declarations
LC's No-Spam Newsreading account wrote:
If I understand correctly (from my point of view of a Fortran
programmer), a "static" variable is something global to all instances of
a class.
Not how I would describe it. It's more like the "global" property is
one consequence of the way Java implements these static variables. In
other words, just because it works this way doesn't mean you have to use
it like that.
This makes sense for classes which are real objects, of which a
plurality of instances exist.
This is exactly how I would describe static (class) variables. They are
bound to the class object. Which happens to make them "global" to all
instances of that class (but doesn't mean you should use statics).
But what about classes which do exist in a
single instance ? It is something like COMMON ...
I assume you mean objects (instances) not classes. In other words,
singleton objects. In this case, both static class variables and
instance variables work very similar, since you only have one copy of
each. I'd use instance variables instead of static, just on general
principles, because I find statics harder to test and work with.
So prefer instance variables to static variables.
I recently wanted to convert a working applblank et into a standalone
application. Both of them are things which do exist in a single instance.
Incorrect. It's possible, even normal, to have multiple copies of the
same application running at the same time. You have to do extra work to
prevent that and only have one.
And of course it's possible to have multiple copies of an applet running
too. The most common case would be applets running on separate client
machines. But it's perfectly valid to have more than one <applet> tag
on a single page refer to the same code base.
The applet has (should have ? shall have ? must have ?) among others an
init method and a start method. According to SWING standards (ok?), the
init method has a construct
"Has." You have to inherit from JApplet (for Swing) and so the applet
will inherit the init(), start(), stop() and destroy() methods.
try {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
realMain() ;
}
});
} catch (Exception e) { ...
where realMain() instantiates the (single) instance of the applet GUI,
while start() in my case establishes communication with a servlet.
With the new plug-in start() and init() are pretty much equivalent. I'd
just use init() and leave start() alone, it's just redundant now.
A SWING application has in the main a construct of the form
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
where createAndShowGUI instantiates the single instance of the
overarching GUI.
I don't always think of my GUIs as single instances. Some objects
are... the top level JFrame for example. But most other things can have
multiple copies running. It's easier to add views of the same object
that way, if you need to do so later.
This goes for applets too.
And either way I'd store my GUI references in an instance variable.
Again, just easier to test the app that way.
I assumed the application alone26 did not need a constructor (as the
applet didn't, and as it will by definition exist in a single instance)
This is wrong. Nothing prevents you from instantiating multiple copies
of the same applet. So not by definition. Maybe by your design, but
that's something you have to work out.
When compiling I found complaints about lots of class variables not
being static, so I declared them static. There were also complaints on
I think you went the wrong way. Make an instance of the applet instead.
Don't convert everything to static, it's just more work.
This makes the standalone application compile and work as expected, but
I'm not sure about why what I did works, whether it was the correct and
simplest thing to do, or whether it was somehow redundant instead.
Like I said, I think you chose the wrong direction to make everything
static. Instead, you should have made an instance of your applet inside
the application and not had to bother with changing everything around.
I think you would have encountered a different set of problems, but the
result would have been better. For example:
public class Main {
public static void main( String... args ) {
SwingUtilities.invokeLater( new Runnable() {
public void run() {
createAndShowGui();
}
} );
}
// package-private
void createAndShowGui() {
JApplet myApplet = new MyApplet();
...
}
}
I do this for testing regularily, it works fine. Eg. from some of my
code laying around on disc:
public class AppletBootstrapForDI
extends JApplet implements Bootstrap {
... }
public class AppletBootstrapForDITest {
@Test
public void testInitConfigTestBoot() {
System.out.println("init--test-boot.properties");
TestAppletBootstrapForDI instance =
new TestAppletBootstrapForDI();
instance.setParameter(AppletBootstrapForDI.PARAM_KEY_BOOT,
"test-boot.properties");
instance.init();
}
}
where
static class TestAppletBootstrapForDI
extends AppletBootstrapForDI {
HashMap<String, String> parameters =
new HashMap<String, String>();
Object setParameter(String key, String value) {
return parameters.put(key, value);
}
@Override
public String getParameter(String key) {
return parameters.get(key);
}
}
Thus I don't have problems with stuff being declare static, because I'm
not working with a static context, I've to a real live object (the
applet) to work with.