applets, applications and static declarations

[Guest]

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.

This makes sense for classes which are real objects, of which a
plurality of instances exist. But what about classes which do exist in
a single instance ? It is something like blank COMMON ...

I recently wanted to convert a working applet into a standalone
application. Both of them are things which do exist in a single
instance.

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

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.

An application (whatever it is) shall have a public static void
main(String[] args) method, which does whatever it should do (could be a
traditional computation reading/writing from stdin/stdout or from
files).

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.

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)

When compiling I found complaints about lots of class variables not
being static, so I declared them static. There were also complaints on
some the inner classes I used (all in the same source file) not being
static, so I declared them static as well.

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

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)

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() {
}

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.

 

[Lew]

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.

 

[John B. Matthews]

[...]

I recently wanted to convert a working applet into a standalone
application. Both of them are things which do exist in a single
instance.

[...]

JApplet, JFrame & JDialog are top-level containers:

<http://java.sun.com/docs/books/tutorial/uiswing/components/toplevel.html>

To create an application, you should be able to add your applet to a
suitable container, as discussed here:

<http://mindprod.com/jgloss/applet.html#SWITCHHITTER>

In this related example, I factored out some initialization into a
common method, initContainer():

<http://sites.google.com/site/drjohnbmatthews/subway>

 

[markspace]

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

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.

 

[Arne Vajhøj]

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.
Yes.

This makes sense for classes which are real objects, of which a
plurality of instances exist. But what about classes which do exist in a
single instance ?

1 is also all, so ...

I recently wanted to convert a working applet into a standalone
application. Both of them are things which do exist in a single instance.

It is not given that only one instance of a sub class of JFrame will
exist.

Many applications is coded that way though. But that is logic not
language.

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

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.

An application (whatever it is) shall have a public static void
main(String[] args) method, which does whatever it should do (could be a
traditional computation reading/writing from stdin/stdout or from files).

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.

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)

When compiling I found complaints about lots of class variables not
being static, so I declared them static. There were also complaints on
some the inner classes I used (all in the same source file) not being
static, so I declared them static as well.

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

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)

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() {
}

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.

I think you will be a lot better of by moving the content of
the init method to the constructor of the class extending
JFrame.

I must admit that I am somewhat assuming that you code
applets and GUI apps like I do, but you have not posted
a full example, so I have to guess.

Arne

 

[Arne Vajhøj]

In this related example, I factored out some initialization into a
common method, initContainer():

<http://sites.google.com/site/drjohnbmatthews/subway>

The code is nice.

But "Distributed under the terms of the GPL" - do you
really need to put demo code under GPL??

Arne

 

[John B. Matthews]

The code is nice.

Thanks. It's my "Hello, world" signed-applet/JWS-application:

But "Distributed under the terms of the GPL" - do you
really need to put demo code under GPL??

Overkill? It's just one with which I'm most familiar. I also, use LGPL
and modified GPL. I should probably consider others:

<http://www.opensource.org/licenses/category>
<http://creativecommons.org/licenses/by/2.5/>

 

[Roedy Green]

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.

I would not say "global" but rather "common". There is only one copy
of the variable accessed by all objects of that class.

In theory you could have a static variable known only to one method.
Java does not permit that, though the JVM could support it. A static
variable is not necessarily public, global or widely known.

see http://mindprod.com/jglosss/static.html

 

[Roedy Green]

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

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.

that does not make sense. If your init method has been called, the
Browser has already allocated your extended Applet/JApplet object. Why
would you create another one. That sort of code I use for hybrids --
programs you can run standalone or as Applets. See
http://mindprod.com/jgloss/applet.html#SWITCHHITTER

 

[Roedy Green]

In theory you could have a static variable known only to one method.
Java does not permit that, though the JVM could support it. A static
variable is not necessarily public, global or widely known.

see http://mindprod.com/jglosss/static.html

oops. That should read
http://mindprod.com/jgloss/static.html

 

[Lew]

Thanks. It's my "Hello, world" signed-applet/JWS-application:



Overkill? It's just one with which I'm most familiar. I also, use LGPL
and modified GPL. I should probably consider others:

<http://www.opensource.org/licenses/category>
<http://creativecommons.org/licenses/by/2.5/>

And why shouldn't he enforce copyright on demo code? Why is that inadvisable?
Is it not his original work? Might he not want to retain ownership in case
he wants to reuse it, say in another work or for an article?

It's not like it's difficult to add a license notice to demo code. Seems to
me the default should be to include license terms, not try to decide if this
or that code "really" needs it.

 

[Arne Vajhøj]

And why shouldn't he enforce copyright on demo code? Why is that
inadvisable? Is it not his original work? Might he not want to retain
ownership in case he wants to reuse it, say in another work or for an
article?

It's not like it's difficult to add a license notice to demo code. Seems
to me the default should be to include license terms, not try to decide
if this or that code "really" needs it.

I don't have a problem with GPL as such. Whoever write the code has
the privilege of determining the license. Releasing code under GPL
makes some rules for both modifications to the code and applications
using the code. If the author likes those rules, then it is fine.
Users know the license and if they are fine with GPL then they
can use the code and if they do not like GPL, then they will have
to find some other code.

But this is examples/demo code. The two main impacts of demo code
is that:
- modified versions of the demo code has to be released under GPL
if distributed
- the code of entire app being "linked" with the demo code has to be
released under GPL if distributed

I am not convinced that those make much sense for demo code.

And they will impose certain problems for some potential users.

It is obvious still the authors right to pick whatever license
he choose.

But for demo code I will strongly suggest something "do whatever
you want": BSD license, "THE BEER-WARE LICENSE" or maybe
simply put it in the public domain.

Arne

 

[Andrew Thompson]

...I recently wanted to convert a working applet into a standalone
application. Both of them are things which do exist in a single
instance. ...

Launch them both using JWS, and implement the
SingleInstanceService/Listener. I have a demo
at <http://pscode.org/jws/api.html#sis>

 

[Roedy Green]

Launch them both using JWS, and implement the
SingleInstanceService/Listener. I have a demo
at <http://pscode.org/jws/api.html#sis>

I have not explored JWS for Applets yet. What does it buy you?
I would guess the biggie would be automatic access to the proper jar
containing the JNI code for the particular platform. That is very
difficult to do with a raw Applet.
--
Roedy Green Canadian Mind Products
http://mindprod.com
GØD is REAL untess declared INTEGER.
~ Anonymous

In FØRTRAN, variables beginning I..N are implicitly INTEGER, the rest REAL.

 

[John B. Matthews]

I don't have a problem with GPL as such. Whoever write the code has
the privilege of determining the license. Releasing code under GPL
makes some rules for both modifications to the code and applications
using the code. If the author likes those rules, then it is fine.
Users know the license and if they are fine with GPL then they can
use the code and if they do not like GPL, then they will have to find
some other code.

But this is examples/demo code. The two main impacts of demo code is
that:
- modified versions of the demo code has to be released under GPL
if distributed
- the code of entire app being "linked" with the demo code has to be
released under GPL if distributed

I am not convinced that those make much sense for demo code.

And they will impose certain problems for some potential users.

I appreciate this perspective. My understanding is that copyright
applies to the work as a whole. Just abstracting a method named
initContainer() or simulating mass transit isn't covered.

It is obvious still the authors right to pick whatever license he
choose.

But for demo code I will strongly suggest something "do whatever
you want": BSD license, "THE BEER-WARE LICENSE" or maybe
simply put it in the public domain.

I must demur. Public domain lacks a critical element common to the open
source licenses cited: a disclaimer of warranty.

<http://en.wikipedia.org/wiki/Uniform_Commercial_Code>

 

[Andrew Thompson]

...

I have not explored JWS for Applets yet.  What does it buy you?

Are you referring to free-floating or embedded?
As a 'for instance' of the differences, the JNLP
SingleInstanceService would work well with
free-floating applets, but I do not know what it
would do with embedded applets should the user
choose to open two browser tabs showing the
exact same applet page.

I would guess the biggie would be automatic access to the proper jar
containing the JNI code for the particular platform.  That is very
difficult to do with a raw Applet.

Is it possible to add a binary to an embedded
applet at run-time? I understand that an applet
can use a native if it is already on the system
path for natives, but that would require a trusted
applet to unpack the native, put it in the right
binary path, then restart the VM (somehow) to
refresh the JREs knowledge of the natives available.
(Wouldn't it? I really have little experience
deploying embedded applets with natives.)

 

[Arne Vajhøj]

I appreciate this perspective. My understanding is that copyright
applies to the work as a whole. Just abstracting a method named
initContainer() or simulating mass transit isn't covered.

Your copyright protects the whole work, but that protection includes
protection against copying part of it.

Obviously a single line is difficult to claim to have been copied.

But 10 or 20 identical lines could easily be considered evidence of
copying if they are non trivial.

If someone takes you GPL demo, tries it and modifies it, then your
GPL license applies to the modified version. That is not a problem.
But if that someone then takes some of the modified demo code and copy
paste into the real app, then your GPL license applies to the entire
app. If your code was something real - let us say that it was a tax
calculation app - then you may indeed be very interested in that
freeloaders can not take your code and use in their commercial
closed source offering. But for code demoing Swing, then I don't
think that was your intention.

I must demur. Public domain lacks a critical element common to the open
source licenses cited: a disclaimer of warranty.

<http://en.wikipedia.org/wiki/Uniform_Commercial_Code>

Lots of code is put in the public domain. So not everyone is
afraid of warranty obligations by doing that.

But if you are, then just go for one of the open source license
that are "do whatever you want".

Arne

 

[Roedy Green]

I must demur. Public domain lacks a critical element common to the open
source licenses cited: a disclaimer of warranty.

<http://en.wikipedia.org/wiki/Uniform_Commercial_Code>

What about copyright? We have seen many people stealing material fro
websites and reposting presumably to steal some of the ad revenue.
--
Roedy Green Canadian Mind Products
http://mindprod.com
GØD is REAL untess declared INTEGER.
~ Anonymous

In FØRTRAN, variables beginning I..N are implicitly INTEGER, the rest REAL.

 

[John B. Matthews]

If your code was something real - let us say that it was a tax
calculation app - then you may indeed be very interested in that
freeloaders can not take your code and use in their commercial
closed source offering.

That doesn't bother me. Indeed, much of my useful code is LGPL or
modified GPL.

But if you are, then just go for one of the open source license
that are "do whatever you want".

I was looking at <http://creativecommons.org/licenses/by/3.0/>, but I
find the attribution requirement unseemly.

Certainly, the matter deserves more study.

 

[Arne Vajhøj]

What about copyright? We have seen many people stealing material fro
websites and reposting presumably to steal some of the ad revenue.

What about it?

Any of the options discussed allow anyone to repost the code.

Arne