与番石榴CharMatcher.matchesAnyOf怪异的Java编译错误

在我的Java项目中，我有下面的代码行：与番石榴CharMatcher.matchesAnyOf怪异的Java编译错误

CharMatcher.JAVA_LETTER_OR_DIGIT.matchesAnyOf("string");

此行完全在日蚀（在Windows，番石榴14.0.1，爪哇1.6.0_22 -b04）。当我们的集成虚拟机（Debian的，番石榴14.0.1的Java 1.6.0_22-B04）编制，线路产生以下错误：

[javac] /opt/quantis/src/Quantis_EJB/ejbModule/internals/QtsSessionManagerBean.java:298: cannot find symbol 
[javac] symbol : method matchesAnyOf(java.lang.String) 
[javac] location: class com.google.common.base.CharMatcher 
[javac]   CharMatcher.JAVA_LETTER_OR_DIGIT.matchesAnyOf("string");

这不是一个类路径问题，因为其他行需要番石榴14功能效果很好。以下行不会产生错误：

CharMatcher.JAVA_LETTER_OR_DIGIT.matchesNoneOf("string"); 
Hashing.sha512().newHasher().putString("string");

任何有关为什么只是这个符号而不是其他的解决方案的想法？ Linux JDK中的特例错误？与其他潜在的jar在我的类路径冲突（我们有很多其他依赖）？

来源

2013-06-04 cporte

您使用的是Maven吗？如果是这样，'mvn dependency：tree'显示什么？ –

不幸的是，这个旧项目仍然没有maven – cporte

由于您不使用Maven，因此您可能会手动管理您的依赖关系。在那种情况下，你是否尝试过简单地将所有的依赖关系都写进来，以找到该类存在于哪个罐子中？

grep -E com.google.common.base.CharMatcher lib/*

它也可以，如果你的构建过程中捆绑包含依赖的东西，重要的是让他们在同一个地方。

另一种方法是从运行时中以编程方式找出类来自哪里。如果你注释掉这些行能够编译，你可以以某种方式（单元测试等）运行它，你可以使用下面的代码找出类的起源：

System.out.println(CharMatcher.class.getProtectionDomain() 
     .getCodeSource().getLocation())

罪犯可能是一个旧的Google Collections jar，Guava的前身，如果它有CharMatcher（“Since 1.0”似乎表示它）或另一个嵌入Guava类的jar。

来源

2013-06-06 10:57:12

我不认为Google Collections有一个“CharMatcher”类。 –

@JoachimSauer对，我在写这行时忘了具体问题。 –

在运行时使用正确的jar。我整理了整个虚拟机，只有一个jar包含一个旧版本的番石榴（没有matchesAnyOf（）方法，在番石榴8中引入）。奇怪的部分是这个jar不应该也不会在编译类路径中。但这是唯一连贯的解释，所以我想我们将使用一种解决方法，直到我们转向maven。谢谢！ – cporte

与番石榴CharMatcher.matchesAnyOf怪异的Java编译错误

回答

相关问题