java 增量编译_maven增量编译

最近由于不清楚maven(2.2.x)增量编译的机制，导致应用出现了一个当时觉得非常诡异的一个问题。先描述一下问题。

背景是应用A有一个公用的base包，版本为1.6.6-SNAPSHOT，应用B依赖于这个公用的base包。我在base包中修改了一个字符串变量的值，该变量是一个缓存的key(如下面代码的Constants类，中的CACHE_KEY)。然后使用mvn deploy 命令把base包上传到中心库中。出现的问题是应用B打包部署，应用上线后，使用后台功能删除"cache.key.new"对应的缓存值，提示删除成功。但是前台展示的还是老的值(前台展示取的数据是从缓存取出的，简化代码后，参考下面的CategoryManager的showCategory()方法，根据key在缓存中取出值，然后前台展示)。

publicInterface Constants{public interfaceCache{

String CACHE_KEY= “cache.key.new”;//旧值为"cache.key"

}

}

publicClass CategoryManager{private static Map keyMaps = new HashMap();static{

keyMaps.put(1, Constants. Cache. CACHE_KEY);//把缓存的key存到map中

.........

}publicObject showCategory(){return cacheManager.get(keyMaps.get(1));//在缓存中获取数据

}

}

一开始怀疑是包没有成功deploy到中心库中，然后在中心库中把1.6.6-SNAPSHOT的源码包拉了下来，发现里面的代码是新的。

我的印象中deploy是maven生命周期的最后一步，执行deploy命令是会执行compile编译操作的，当时怀疑自己记错了，以为base包deploy的时候没有走到compile，就把包发到中心库中了，后续把base包的1.6.6-SNAPSHOT的编译后的文件拉下来，并且反编译Constants类，发现CACHE_KEY的确是新的值"cache.key.new",证明这块是被重新编译过了。(后续翻阅了下资料”http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html maven生命周期“发现自己记的的确没错)

最后把CategoryManager.class反编译过来一看，发现里面的部分代码是这样的：

publicClass CategoryManager{private static Map keyMaps = new HashMap();static{

keyMaps.put(1, "cache.key");//问题出在这里，这个"cache.key"没有替换成新的值"cache.key.new"

.........

}

........

}

发现问题了，这里的"cache.key"并没有替换成新值。也就是说CategoryManager类并没有重新编译。这里的原因是maven的增量编译机制。

后续找了些资料表明，默认情况下maven是增量编译的，maven在编译的时候会先去比较源文件(.java)文件的修改时间和对应类文件(.class)的修改时间，如果源文件的修改时间比类文件的修改时间要晚的话，重新编译原文件否则不做处理(另外，如果删除了一个java文件，对应的class文件在增量编译时是不会被移除的)。

在这里CategoryManager的源文件并没有发生过改变，所以不会重新编译。并且这个地方恰好是静态代码块，这段代码  keyMaps.put(1, Constants. Cache. CACHE_KEY); 编译时直接被替换成 keyMaps.put(1, "cache.key"); ，如果是在非静态代码块里面使用的话，这块地方是不会出问题的。所以之前一直使用mvn deploy都没有出现过问题。

那要怎么避免这个问题呢，使用mvn clean deploy。clean会做一些清理的工作，包括移除上一次构建的文件。这样就能很好的解决这个问题了。

参考：