更新Java final常量后,class不能重新编译的问题
2015-11-30 16:34
363 查看
程序中使用的各种常量用一个类来统一管理,类似:
public class AppConst {
public static final String STR_1 = "String1";
public static final String STR_2 = "String2";
......
}
然后在某些逻辑代码段里使用了这些常量。这样做可以便于管理常量,避免了大量的magic number/text,在修改常量内容时只需改这一个类就行了,但有时候会奇怪地发现,重新编译打包的程序依旧我行我素,并没有即时反应我们对常量的修改,这是何解呢?
在之前的《JVM学习笔记三--类的初始化》中我曾提到,静态常量(即用 static final 修饰的变量)是编译时常量,当一个class文件编译完毕,它内部使用到的所有常量的具体值就已经确定了,不能想当然地以为它在运行时并连接常量管理类之 后才会以引用方式使用常量。比如下面这段代码:
import AppConst;
public class SomeService {
public void serviceJob1() {
System.out.println(AppConst.STR_1);
}
}
类SomeService使用了STR_1这个常量,表面上是通过AppConst类取得的这个值,实际上在SomeService被编译后,其代码其实变成了
<textarea cols="50" rows="15" name="code" class="java">public class SomeService {
public void serviceJob1() {
System.out.println("String1");
}
}</textarea>
这里面根本没有AppConst什么事,所以你即使修改了AppConst的相关常量,令STR_1 = "NotString1",SomeService可能依然会打印"String1",因为SomeService的代码没有任何修改,在增量编译的情况 下,它的class文件不会被重新编译。
明白了上面这些,大致就知道怎么办了,我的方法有两个:
1. 原始条件下,删除class文件后手动重编译。
2. 使用IDE的时候, 先对SomeService做一个细微修改并保存(会自动编译),然后再修改回来并保存(再次自动编译)。如此class文件就会被更新了。
是这样的,单纯的修改静态变量是没用的,还要重新编辑所有引用静态变量的类,不然不会生效的。
改成
public class AppConst {
public static getString2(){
return "String2";
}
......
}
就可以仅仅修改并编译一个类就行了 .
从根本上来解决此问题得这么做,最简单。
public class AppConst {
public static final String STR_1 = new String("String1");
public static final String STR_2 = new String("String2");
public static final int number1=new Integer(123);
......
}
反编译,你会发现在引用此静态类属性的时候,引用代码不是直接用具体值替代,而还是源代码里的引用。
一句话总结,在静态类里定义的静态属性,坚决不用引用类型,而需要用对象类型。
public class AppConst {
public static final String STR_1 = "String1";
public static final String STR_2 = "String2";
......
}
然后在某些逻辑代码段里使用了这些常量。这样做可以便于管理常量,避免了大量的magic number/text,在修改常量内容时只需改这一个类就行了,但有时候会奇怪地发现,重新编译打包的程序依旧我行我素,并没有即时反应我们对常量的修改,这是何解呢?
在之前的《JVM学习笔记三--类的初始化》中我曾提到,静态常量(即用 static final 修饰的变量)是编译时常量,当一个class文件编译完毕,它内部使用到的所有常量的具体值就已经确定了,不能想当然地以为它在运行时并连接常量管理类之 后才会以引用方式使用常量。比如下面这段代码:
import AppConst;
public class SomeService {
public void serviceJob1() {
System.out.println(AppConst.STR_1);
}
}
类SomeService使用了STR_1这个常量,表面上是通过AppConst类取得的这个值,实际上在SomeService被编译后,其代码其实变成了
<textarea cols="50" rows="15" name="code" class="java">public class SomeService {
public void serviceJob1() {
System.out.println("String1");
}
}</textarea>
这里面根本没有AppConst什么事,所以你即使修改了AppConst的相关常量,令STR_1 = "NotString1",SomeService可能依然会打印"String1",因为SomeService的代码没有任何修改,在增量编译的情况 下,它的class文件不会被重新编译。
明白了上面这些,大致就知道怎么办了,我的方法有两个:
1. 原始条件下,删除class文件后手动重编译。
2. 使用IDE的时候, 先对SomeService做一个细微修改并保存(会自动编译),然后再修改回来并保存(再次自动编译)。如此class文件就会被更新了。
是这样的,单纯的修改静态变量是没用的,还要重新编辑所有引用静态变量的类,不然不会生效的。
改成
public class AppConst {
public static getString2(){
return "String2";
}
......
}
就可以仅仅修改并编译一个类就行了 .
从根本上来解决此问题得这么做,最简单。
public class AppConst {
public static final String STR_1 = new String("String1");
public static final String STR_2 = new String("String2");
public static final int number1=new Integer(123);
......
}
反编译,你会发现在引用此静态类属性的时候,引用代码不是直接用具体值替代,而还是源代码里的引用。
一句话总结,在静态类里定义的静态属性,坚决不用引用类型,而需要用对象类型。
相关文章推荐
- 启动 Eclipse 弹出“Failed to load the JNI shared library jvm.dll”错误的解决方法!
- spring mvc 跳转到新视图中如何携带锚点
- Hadoop-利用java API操作HDFS文件
- javaweb 复习系列(三)
- Spring事务管理的三种方式
- Insertion sort
- java(5)--IO流之PipedInputStream和PipedOutputStream
- 在 Java 中应用设计模式 - Factory Method
- java枚举类型示例
- Spring事务管理的三种方式
- 为什么C#动态调用Java的cxf多了bool型参数
- java设计模式----外观模式(门面模式)
- intllij idea 出现 java.lang.AssertionError:upexpected content storage modification错误信息
- java、js 对于四舍五入、向上取整、向下取整
- Myeclipse自动生成的get set方法 加上文本注释
- Bean的生命周期
- 常见java异常
- 一、编写高质量的代码—Java开发中通用的方法和准则(笔记)
- SpringMVC下打包文件的下载
- 基于JDK API实现文件的压缩与解压