"Global" variables using static class

[Mike Smith]

I have an AWT applet (no Swing) which passes around an instance of
applet-wide "global" variables as we called them in a past life. It
occurred to me I could simply make it a static class with all static
variables and avoid passing around this instance everywhere. For
example instead of this:

public class MyGlobals {
public int myGlobal1;
public int myGlobal2;
public String myGlobal3;
<etc>
public MyGlobals {
<intit code goes here>
}
}

I would do this instead:

public class MyGlobals {
public static int myGlobal1;
public static int myGlobal2;
public static String myGlobal3;
<etc>
static{
<intit code goes here>
}
}

The advantage is that I would not have to make an instance of MyGlobal
and pass it as a parameter to every God-forsaken method that needs it.
Instead I would simply reference it as MyGlobals.<var name> and let
the class loader deal with it. Please, no lectures on "thinking in
Java vs thinking in whatever", application-wide variables exist and
you have to deal with them. The question is what is the disadvantage
with regard to efficiency. Is invoking the class loader each time you
access a non-final static var a big hit?

Mike Smith

 

[Steve Horsley]

Mike Smith wrote:

The advantage is that I would not have to make an instance of MyGlobal
and pass it as a parameter to every God-forsaken method that needs it.
Instead I would simply reference it as MyGlobals.<var name> and let
the class loader deal with it. Please, no lectures on "thinking in
Java vs thinking in whatever", application-wide variables exist and
you have to deal with them. The question is what is the disadvantage
with regard to efficiency. Is invoking the class loader each time you
access a non-final static var a big hit?

I don't think this would hit the calssloader repeatedly, but just the
once, the first time you refer to the class.

The only disadvantage I can think of is that you might one day want to
make this thing you are writing just a component of a larger system,
or run multiple instances of it in the same VM, in which case the
global values may no longer be quite so global. That has happened
to me just once, where I decided to incorporate several disparate
utility services into one glorious multi-service program.

Steve

 

[Bryce]

The question is what is the disadvantage
with regard to efficiency. Is invoking the class loader each time you
access a non-final static var a big hit?

Static variables are loaded when the class is first loaded. Just once,
so I doubt its any hit...

 

[Mike Smith]

The only disadvantage I can think of is that you might one day want to
make this thing you are writing just a component of a larger system,
or run multiple instances of it in the same VM, in which case the
global values may no longer be quite so global. That has happened
to me just once, where I decided to incorporate several disparate
utility services into one glorious multi-service program.

Hmmm, in a perfect world I could access the static vars via getters and
setters and the compiler would inline the calls. That would minimize the
hit should I decide to go the multiple instance route down the road. Any
idea if the compiler (any) does this? I'm such a wimp anymore, in my C++
days I always knew exactly what machine code was produced by which compiler
for which target.

Mike

 

[Tony Morris]

I have an AWT applet (no Swing) which passes around an instance of
applet-wide "global" variables as we called them in a past life. It
occurred to me I could simply make it a static class with all static
variables and avoid passing around this instance everywhere. For
example instead of this:

public class MyGlobals {
public int myGlobal1;
public int myGlobal2;
public String myGlobal3;
<etc>
public MyGlobals {
<intit code goes here>
}
}

I would do this instead:

public class MyGlobals {
public static int myGlobal1;
public static int myGlobal2;
public static String myGlobal3;
<etc>
static{
<intit code goes here>
}
}

The advantage is that I would not have to make an instance of MyGlobal
and pass it as a parameter to every God-forsaken method that needs it.
Instead I would simply reference it as MyGlobals.<var name> and let
the class loader deal with it. Please, no lectures on "thinking in
Java vs thinking in whatever", application-wide variables exist and
you have to deal with them.

I'm not going to but I'm inclined to suggest you seriously rethink what you
are doing.
There are much nicer ways of achieving what you are trying to do.
In fact, I'd be inclined to suggest that what you are trying to do is never
justified (not even
in an extreme circumstance).

(lecture omitted for brevity).

The question is what is the disadvantage
with regard to efficiency. Is invoking the class loader each time you
access a non-final static var a big hit?

eh?
This misunderstanding undermines your reasoning for the pros and cons of
your (clearly flawed) approach - since you seem to be misunderstanding what
the class loader is doing for you when a static member is accessed.

Side note: A static final does not imply a compile-time constant - there are
other requirements (JLS 15.28).

Suggest you:
a) read up on what a Java class loader is and how it works
b) read up on general software development techniques
c) reconsider your approach.
in that order

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Mike Smith]

----- Original Message -----

From: "Tony Morris" <[email protected]>
I'm not going to but I'm inclined to suggest you seriously rethink what you
are doing.
There are much nicer ways of achieving what you are trying to do.
In fact, I'd be inclined to suggest that what you are trying to do is never
justified (not even
in an extreme circumstance).

(lecture omitted for brevity).

Thanks for ommiting the lecture but I really am interested in your solution.
I have a class 1 which calls a method in class 2 which call a method in
class 3 on to a method in say, class 20. In an extreme case none of the
classes in between require the "globals" class. But they all have to pass
it along just so class 20 has access. There are System-wide static classes
in Java which can be accesed anywhere, why not application-wide static
classes?

Mike Smith

 

[Shane Mingins]

Thanks for ommiting the lecture but I really am interested in your solution.
I have a class 1 which calls a method in class 2 which call a method in
class 3 on to a method in say, class 20. In an extreme case none of the
classes in between require the "globals" class. But they all have to pass
it along just so class 20 has access. There are System-wide static classes
in Java which can be accesed anywhere, why not application-wide static
classes?

Mike Smith

Is another option to use a type of Registry
http://martinfowler.com/eaaCatalog/registry.html object?

Shane

 

[Tony Morris]

Thanks for ommiting the lecture but I really am interested in your solution.
I have a class 1 which calls a method in class 2 which call a method in
class 3 on to a method in say, class 20. In an extreme case none of the
classes in between require the "globals" class. But they all have to pass
it along just so class 20 has access. There are System-wide static classes
in Java which can be accesed anywhere, why not application-wide static
classes?

Even so, this is not a justification for declaring "application-wide" [sic]
data.
You might consider passing a callback, so that there is only one parameter
which is passed.
You might consider have a singleton that contains your "application-wide"
context.
There are many possibilities, but without a better context, I'm apprehensive
to suggest any.
If your methods need this context, it should be passed, regardless of
whether or not the intervening methods "require" it i.e. explicitly use it
(they do, in fact, require it to call the methods that perform the intended
task).

Be aware that a static is not "system-wide", nor "application-wide", not
even "JVM-wide".
It is, in fact, "class-loader wide".

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Mike Smith]

Even so, this is not a justification for declaring "application-wide" [sic]
data.
You might consider passing a callback, so that there is only one parameter
which is passed.
You might consider have a singleton that contains your "application-wide"
context.
There are many possibilities, but without a better context, I'm apprehensive
to suggest any.
If your methods need this context, it should be passed, regardless of
whether or not the intervening methods "require" it i.e. explicitly use it
(they do, in fact, require it to call the methods that perform the intended
task).

The context is that of a very graphics oriented app. The global variables
are things like a boolean called "isApplet" for doing things differently if
running as an applet, or "hostWindow" for centering dialogs and alerts on
the main window and such. I think the singleton idea is good, especially
since it lifts the restriction of initializing everything when the class
loads. Thanks,

Mike

 

[Stefan Poehn]

"Steve Horsley" <[email protected]> wrote

[...]
idea if the compiler (any) does this? I'm such a wimp anymore, in my C++
days I always knew exactly what machine code was produced by which compiler
for which target.

What is it good for to know the machine code? Even if you understand
(optimized or non-optimized) machine code, I seriously doubt that would be
of any help. Your machine code depends on so many layers (processor,
chipset, operating system), that it is of no interest if there is still
another layer (java virtual machine).

 

[Mike Smith]

What is it good for to know the machine code? Even if you understand
(optimized or non-optimized) machine code, I seriously doubt that would be
of any help. Your machine code depends on so many layers (processor,
chipset, operating system), that it is of no interest if there is still
another layer (java virtual machine).

Yes, you are correct. Even if the Java compiler is doing something
inefficient the JIT compiler has a second chance to optimize it on the way
to the target machine code. Thanks for reminding me, I will try harder to
not care

Mike

 

[Roedy Green]

What is it good for to know the machine code?

The precise details of the machine code for your machine is of less
importance than general understanding of how Von Neumann machines work
inside. If you have written any assembler, you have a good intuition
that file open is a much more time consuming operation than say
throwing an exception.

 

[Stefan Poehn]

Yes, you are correct. Even if the Java compiler is doing something
inefficient the JIT compiler has a second chance to optimize it on the way
to the target machine code. Thanks for reminding me, I will try harder to
not care

The other option is to waste years on finding bugs while watching bits. I am
not keen on doing that, but that should not prevent you from reading the
many ones and zeroes that fly around in your computer.