I was wondering, whether the following code are safe.
public class GUIBundle {
// The technique known as the initialization on demand holder idiom,
// is as lazy as possible.
// http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom
//private static class BundleHolder {
// private static final ResourceBundle bundle = ResourceBundle.getBundle("org.yccheok.jstock.data.gui");
//}
private static final ResourceBundle bundle = ResourceBundle.getBundle("org.yccheok.jstock.data.gui");
private GUIBundle() {
}
public static String getString(String key) {
// return BundleHolder.bundle.getString(key);
return bundle.getString(key);
}
}
public class SellPortfolioChartJDialog extends javax.swing.JDialog {
private static final String[] cNames = new String[] {
GUIBundle.getString("BuyPortfolioTreeTableModel_NetGainValue")
};
}
Since cNames is within static scope, is it safe for it to access static bundle? Does it make any different whether I am using lazy initialization technique?
I remember I came across an article (I lost the article anyway) talking about nondeterministic of initialization order of static variables. I am not sure whether the nondeterministic of initialization order of static variables, applied to the above case?
I believe the nondeterministic initialization order of static variables (in different compilation units) is a C/C++ "feature". In Java, static variables are initialized when their class is loaded, and within a single class in their order of declaration. So the order is deterministic (at least in a single threaded environment).
This guarantees that what you intend to do should work: when GUIBundle is first referenced, the classloader loads it and initializes bundle too. The call to GUIBundle.getString() happens only after the class initialization is done.
That works just fine. I got it to compile by keeping the principle the same but using different classes (I didn't want to bother getting your jars... :-).
Obviously there are some small problems, like how you declare your String[] needs to be
private static final String[] cNames = new String[] {
GUIBundle.getString("BuyPortfolioTreeTableModel_NetGainValue")
};
}
Other than that, it works just fine. The key to using statics in other statics is the order they're declared. You can't do this
static Foo b = a;
static Foo a = new Foo();
I think its perfectly safe, You see because the when
GUIBundle.getString
is used in your JDialog subclass, the JVM will completely initialize (see java language spec loading, linking and initialization) the class GUIBundle before calling the method getString on it, which will initialize all the class (static) initializers in the class GUIBundle.
Edit: Read more about this in VM spec:
http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#16491
To me it's safe.
bundle is initialized right after GUIBuilder is loaded and therfore before getString is called for the first time.
Related
Why would you declare a static final variable as private for an immutable type?
Could it possibly do any harm to declare them public on any case?
So that nobody can access it from outside and rely on that value, giving you the freedom to change it without risk of side-effect (at least outside of the class where it's declared).
There are serveral reasons...
Privacy
Keep implementation details hidden from the clients, for example constants for internal use only and with no use for clients
Security
Protect your code from maliscious client codes for example:
static class A
{
public final static List<String> list = buildList();
public static List<String> buildList()
{
ArrayList<String> list = new ArrayList<>();
list.addAll(Arrays.asList("A", "B", "C"));
return list;
}
}
static class B
{
public static void main(String[] args)
{
A.list.clear();
System.out.println(A.list);
}
}
You dont want any one to manipulate you internal data.
It's just best OOP practice to keep variables within the proper scope. An example would be a global static final integer for performing a number of calculations within the class. Having it exposed (public) not only could cause problems, but confusion as well.
Say you had a class where you needed to know the value of pi:
public class MyClass {
private static final double PI = 3.14159;
//functions performing calculations with value of PI
}
The value of pi is only needed within MyClass, so leaving it to be exposed makes no sense - all calculations with the variable are done within MyClass. If you need it again to perform a calculation, it should be done within the class holding the value to keep your code organized.
public class GUICommon {
private static final ExecutorService executorServices = Executors.newWorkStealingPool();
public static void useExecutors(Runnable run)
{
executorServices.execute(run);
}
}
I used it on this way.
I am learning C# and JAVA I found Static Constructor in C# which is used to initialize any static data, or to perform a particular action that needs to be performed once only. It is called automatically before the first instance is created or any static members are referenced.
For Example:
class SimpleClass
{
// Static variable that must be initialized at run time.
static readonly long baseline;
// Static constructor is called at most one time, before any
// instance constructor is invoked or member is accessed.
static SimpleClass()
{
baseline = DateTime.Now.Ticks;
}
}
My Question is that how can I gain same functionality in JAVA is there any way ???
You may use static initialization block like this -
class SimpleClass
{
static{
}
}
The static block only gets called once, no matter how many objects of that type is being created.
You may see this link for more details.
Update: static initialization block is called only when the class is loaded into the memory.
You have static initializer block.
static final long baseline;
static {
baseline = ...
}
I was going through this topics:
In what order do static initializer blocks in Java run?
Java Static Initialization Order
And I don't understand if we have a constructors, where we can put some logic, such as dealing with exceptional situations, why we need initialization blocks, which code we can also move to constructor ?
If the answer is that in some cases we need to initialize some resources before constructor runs would you help me with some examples, so I could fully see the picture.
One example of a time when you'd use (and I have used) static initialization blocks is to initialize a collection of elements. For example, if I have some set of parsers that are stored in a static map:
private static Map<String, Parser> parsers = new HashMap<String, Parser>();
I may use a static initialization block to populate the members of this map:
static {
parsers.put("node", new NodeParser());
parsers.put("tree", new TreeParser());
parsers.put("leaf", new LeafParser());
//etc.
}
I would do this because I want the map to be static rather than part of a particular object, or if I only want there to be one of these maps (maybe I only need one).
The difference between this and a constructor is the constructor is called at object instantiation whereas the static initialization block will be called when the class is loaded.
That is, if you call
MyClass.parsers.get("node");
The MyClass constructor is never called so if you waited to initialize the parsers map until the constructor, the above call would return null.
why we need initialization blocks
For instance initialization blocks, I can only think on two cases:
When creating an anonymous class:
Runnable runnable = new Runnable() {
int x;
//initialization block here
{
//IMO this is such odd design, it would be better to not
//create this as an anonymous class
x = outerClassInstance.someMethod();
}
#Override
public void run() {
//write the logic here...
}
};
When using double brace initialization (if the class is not marked final):
List<String> stringList = new ArrayList<>() {
{
add("Hello");
add("world");
}
};
System.out.println(stringlist);
//prints [Hello, world]
For static initialization blocks, there are two cases:
When defining the data for a static field. This is covered in #ChrisThompson's answer.
When initializing a constant (static final) field from an external source, like the result of some computation.
class Foo {
public static final boolean DEBUG;
static {
DEBUG = getDebugMode();
}
private static boolean getDebugMode() {
//code to open a properties file, read the DEBUG property
//and return the value
}
}
Who can explain what's going on?
public class MagicFinal {
public static void main(String[] args) {
System.out.println(A.s);
}
}
class A {
static {
System.out.println("class has been loaded");
}
public static final String s = "final";
public static final Integer i = 3;
}
Console :
final
What's it? I don't understand why the class has not been loaded, I know classes always load at the first call. Field s is in pool of string, I see that final modifier is magic.
If I delete final modifier (public static String s = "final" ) I will get
Console :
class has been loaded
final
Note: I have changed field i : public static final int i = 3; and show it in console.
I got the same as in String situation. Why?
"final" is a string literal and as such is a compile-time constant expression. The value of a static final variable initialized with a compile-time constant expression is directly hardcoded into the class which references it, and no reference is made to the originating class. Therefore the initialization of the originating class does not occur.
As a side point, please note the distinction between class loading and class initialization: only the latter's occurrence is precisely specified by the JLS. Class loading can happen at any time.
This is what is written in Java Language Specification {8.3.2.1 Initializers for Class Variables}. This must answer your question
One subtlety here is that, at run time, static variables that are final and that
are initialized with compile-time constant values are initialized first. This also
applies to such fields in interfaces (§9.3.1). These variables are “constants” that
will never be observed to have their default initial values (§4.12.5), even by devious
programs. See §12.4.2 and §13.4.9 for more discussion.
Right now I'm thinking about adding a private constructor to a class that only holds some String constants.
public class MyStrings {
// I want to add this:
private MyString() {}
public static final String ONE = "something";
public static final String TWO = "another";
...
}
Is there any performance or memory overhead if I add a private constructor to this class to prevent someone to instantiate it?
Do you think it's necessary at all or that private constructors for this purpose are a waste of time and code clutter?
UPDATE
I'm going for a final class with private constructor and a descriptive javadoc for the class. I can't use a ENUM (which I'd prefer) because I'm stuck on Java 1.4 for now. This would be my modification:
/**
* Only for static access, do not instantiate this class.
*/
public final class MyStrings {
private MyString() {}
public static final String ONE = "something";
public static final String TWO = "another";
...
}
Use of private constructor to prevent instantiation of class?
There are several ways you can think of users preventing from the Instantiations for the purpose of creating the Constants
As you have mentioned a class with the private Constructors and has all the string constants, is one way, even there is an overhead, that can be negligible
Else you can create a Class with Final Modifier and Define your string constants
You can use the Abstract Class with the String Constants
You can define the string constants in the properties files and can access from that, this will definitely reduce the memory and increase the flexibility of your code.
For me the best explanation is in Effective Java book: Item 4: Enforce noninstantiability with a private constructor (See more)
In Summary:
Private constructor is due utility classes were not designed to be instantiated, so is a design decision. (NO performance or memory overhead)
Making a class abstract doesn't work because can be subclassed and then instantiated.
With an abstract class the user may think the class is for inheritance.
The only way to ensure no instantiation is to add a private constructor which ensures the default constructor is not generated.
Private constructor prevents inheritance because the super constructor cannot be called (so it is not need the declare the class as final)
Throw an error in the private constructor avoids call it within the class.
Definetively, the best way would be something like next:
public class MyStrings {
private MyStrings () {
throw new AssertionError();
}
...
}
You could add a private constructor, but there are two other options.
In the same situation I would use an enumerator. If it makes sense to your implementation, you could use that instead, if it's public or private depends on where you need to use it:
public enum MyStrings {
ONE ("something"),
TWO ("something else");
private String value;
private MyStrings(String str) {
this.value = str;
}
}
Another option would be to put it in an abstract class, those can not be instantiated:
public abstract MyStrings {
public static final String STUFF = "stuff";
public static final String OTHER = "other stuff";
}
Access for both enumerator and abstract class works just like with the implementation you presented:
MyStrings.STUFF
If you don't won't anyone to make an object of the class you could make it abstract like this
public abstract class MyStrings {
public static final String ONE = "something";
public static final String TWO = "another";
}
and access your static variables like this
String val1 = MyStrings.ONE;
String val2 = MyStrings.TWO;
I think this would be a nicer solution.
I would rather use an enum to hold that Strings. This would ensure that wherever you use that Strings, you only get passed in one of the allowed Strings.
There is no performance or memory overhead if you add a private constructor in this case. As well, it is not needed since your public static variables are shared among all instances of your object.
If your class has only static members, then there is no need to have a private or public constructor. All members are accessible even without an object. In fact I find it confusing to have a constructor in such a case.
A synthetic public constructor would have been generated any way. So no.
Really a few bytes out of hundreds of millions at runtime isn't going to make much difference.
I also suggest making the class final and just for completeness have the constructor throw an exception.
If you want terse source code, you could create an enum with no values. Might cause some confusion with beginner programmers though.
That's the right way to store some constants, as also suggested in Effective Java (2nd Ed.), item 19.