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 exactly.
A 'static' member belongs to the class itself, which is an object in its own
right. It isn't "global to all instances of a class", it's global to all
instances of all classes and to all classes themselves that have access to the
static member's owning class. Actually, Java doesn't have global elements in
the usual sense - it has instance-scoped elements, class-scoped elements and
block-scoped elements.
This makes sense for classes which are real objects, of which a
All classes are real objects.
plurality of instances exist. But what about classes which do exist in a
single instance ? It is something like blank COMMON ...
No, it isn't. The question of how many, or even if any instances of a class
exist is orthogonal to the matter of 'static' members. Abstract classes and
interfaces can have static members (the latter in a limited way), but neither
can have direct instances.
I recently wanted to convert a working applet into a standalone
application. Both of them are things which do exist in a single instance.
From the rest of your description you imply that you have a mess of static
variables in the applet. That's a no-no.
And would it kill you to provide an SSCCE?
...
A SWING [sic] 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.
Why don't you call 'realMain()' in there?
To convert the applet into an application what I did was essentially to
move the code from the applet init and start methods into the
application main method (actually init and main were already very
similar as shown above) and rename realMain as createAndShowGUI. Of
course I also changed the name of the top class and the related
statement from
public class myApplet26 extends JApplet implements ListSelectionListener
to
public class alone26 extends JPanel implements ListSelectionListener
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)
All instances have a constructor, always. Therefore the applet had one.
When compiling I found complaints about lots of class variables not
being static, so I declared them static. There were also complaints on
That statement makes no sense. If they were class variables, they were
declared 'static'. The compiler couldn't have complained that "class
variables [were] not ... static" because if they weren't 'static', they
weren't class variables.
Would it kill you to provide copied-and-pasted error messages with your SSCCE?
These paraphrases and indirect, information-free paraphrases are useless.
How is anyone supposed to help if you don't provide data?
some the inner classes I used (all in the same source file) not being
static, so I declared them static as well.
By definition in Java, "inner" classes are non-static nested classes.
Randomly turning your inner classes into static nested classes was almost
certainly the wrong approach, but absent an SSCCE we can't tell if that's so.
At the end I was left with a single error message on a statement in one
of the methods
table.getSelectionModel().addListSelectionListener(this);
complaining that "this" was not static
Well, of course not. The invoking method shouldn't have been, either.
If I commented out such statement, the application compiled and ran. Of
course one of the components of the GUI, a JTable (table) showing some
results, had lost the interactivity associated to the commented statement.
To overcome this I replaced the offending statement with
table.getSelectionModel().addListSelectionListener(myGui.fake);
where in the prologue of the topmost class among the static variables I
define
static myGui myGui;
and in createAndShowGUI() I instantiate it
myGui = new myGui();
(all these things I did already before)
Thus isolating the listener from the rest of the logic, which somehow I doubt
is what you need.
In the myGui class prologue I added a class variable
alone26 fake;
and in the constructor myGui(), I added as first statement this
fake = new alone26();
I also added a dummy explicit constructor to the topmost class
public alone26() {
}
Class names should start with an upper-case letter. Please follow the coding
conventions.
The explicit constructor contributes nothing.
You're just throwing hamburger at the wall hoping some will stick.
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.
You should get rid of the static variables and use instance variables.
We can't help you because you didn't provide any useful information.
<http://sscce.org/>
and copy and paste your error messages; don't paraphrase.
--
Lew