Is Java Interface the best place for constant storage? (reprint study, non-original)

Is Java Interface the best place for constant storage? (reprint study, non-original)

Because the fields declared in Java interface are automatically added to the static final modifier at compile time, they are declared as constants. Thus interface is usually the best place to store constants. However, there are some problems in the practical application of Java.

The cause of the problem is two, the first, is that the constants we use are not immutable, but are relative to the variables can not be assigned to change. For example, we define constant ∏=3.14 at the beginning of a project, and because of the increase in computational accuracy we may redefine ∏=3.14159, and the entire project reference to this constant should be changed. Second, Java is a dynamic language. Unlike static languages such as C + +, Java's reference to some fields can be performed dynamically at runtime, and this flexibility is a big advantage of dynamic languages such as Java. It also makes it possible for us to change part of the content in the Java project without recompiling the entire project, and simply by compiling the changed part of the re-release can change the entire application.

Tell me so much, don't you know what I'm going to say? OK, let's look at a simple example:

There is a interface A, a class B, the code is as follows:

File A.javapublic interface a{string name = "Bright";} File B.javapublic class B{public static void Main (string[] args) {System.out.println ("class A ' s name =" + A.name);}}

Simple enough, OK, compile A.java and B.java.

Run, enter Java B, and the obvious results are as follows:

Class A ' s name = Bright

We now modify A.java as follows:

File A.javapublic interface a{string name = "Bright Sea";}

After compiling the A.java, rerun B class, enter Java B, note: The results are as follows

Class A ' s name = Bright

Why not "Class A ' s name = Bright Sea"? Let's use the anti-compilation tool provided by the JDK Javap B.class to see exactly, input: Javap-c B, the result is as follows:

Compiled from B.javapublic Class B extends Java.lang.Object {public    B ();    public static void Main (java.lang.string[]);} Method B ()   0 aload_0   1 invokespecial #1 <method java.lang.Object () >   4 returnmethod void Main ( java.lang.string[])   0 getstatic #2 <field java.io.PrintStream out>   3 ldc #3 <string "Class A ' s name = Bri Ght ">   5 invokevirtual #4 <method void println (java.lang.String) >   8 return

Have you noticed the code for label 3? Because a static final field is referenced, the compiler has compiled the contents of name interface A into Class B instead of a reference to name in interface A. So unless we recompile class b,interface A, the change in name cannot be reflected in class B. If you do that then Java's dynamic advantage disappears.

Solution, there are two workarounds.

The first method is to no longer use constants, to put the required fields in class declaration, and to remove the final modifier. However, this method has a certain risk, because it is no longer constant, so when the system is running, it is possible for other classes to modify its value and error, it is against our intention to set it as a constant, and therefore deprecated.

The second method, which is declared in class, uses the class method to get the value of the constant. To maintain the simplicity of this constant reference, we can use a static method. We will revise A.java and B.java as follows:

File A.javapublic class A{private static final String name = "Bright";p ublic static String GetName () {return name;}} File B.javapublic class B{public static void Main (string[] args) {System.out.println ("class A ' s name =" + A.getname ());} }

Likewise we compile A.java and B.java. To run Class B and enter Java B, the obvious result is as follows:

Class A ' s name = Bright

Now we modify A.java as follows:

File A.javapublic class A{private static final String name = "Bright";p ublic static String GetName () {return name;}}

We re-run Class B after compiling A.java again, enter Java B: The results are as follows

Class A ' s name = Bright Sea

Finally get the result we want, we can re-compile B.class to see the change of Class B, input: Javap-c B, the result is as follows:

compiled from B.javapublic Class B extends Java.lang.Object {public B (); public static void Main (java.lang.string[]);} Method B () 0 aload_0 1 invokespecial #1 <method java.lang.Object () > 4 returnmethod void Main (java.lang.string[ ]) 0 getstatic #2 <field java.io.PrintStream out> 3 new #3 <class java.lang.stringbuffer> 6 dup 7 Invo Kespecial #4 <method java.lang.StringBuffer () > LDC #5 <string "Class A ' s name =" > invokevirtual #6 &L T Method java.lang.StringBuffer Append (java.lang.String) > invokestatic #7 <method java.lang.String getName () > invokevirtual #6 <method java.lang.StringBuffer append (java.lang.String) > invokevirtual #8 <method J Ava.lang.String toString () > invokevirtual #9 <method void println (java.lang.String) > Return 

Note The code for lines 10 through 15, which has become a reference to the GetName () method of Class A, and when the value of the constant name changes, we only need to modify and recompile the constants in Class A. No need to compile the entire project we can change the entire application reference to this constant, that is, to maintain the Java dynamic Advantage and maintain the purpose of our use of constants, so method two is an optimal solution.

Note: This article is reprint study notes, non-original, do not like to spray. Original link: http://www.ibm.com/developerworks/cn/java/l-java-interface/

Is Java Interface the best place for constant storage? (reprint study, non-original)