Error Unresolved compilation problems method replace(char, char) is not applicable

Invoking Java from Clojure throws the following error

Error Unresolved compilation problems:
        The method replace(char, char) in the type String is not applicable for the arguments (String, String)
        The method replace(char, char) in the type String is not applicable for the arguments (String, String)

The running JRE is 1.8, so there is no way that the replace method of String refuse to accept String arguments, because the replace(CharSequence target, CharSequence replacement) is provided since Java 1.5.

There is a show function in Clojure that can print all method signatures of a Java class, the output evidently suggests the method exists.

user=> (show java.lang.String)
nil #<Method public java.lang.String java.lang.String.replace(char,char)>
nil #<Method public java.lang.String java.lang.String.replace(java.lang.CharSequence,java.lang.CharSequence)>
nil nil)

The MANIFEST.MF in the jar indicates it was Created-By: 1.7.0_17 (Oracle Corporation). But recompile with Java 1.8 didn't solve the problem.

Compile with Xlint enable didn't mention anything wrong about the replace invocation.


In the end, it was the -verbose:class option revealed the root cause. The JVM was launched from the home directory of the project that would generate the jar that is supposed to be loaded by JVM. Accidentally the classpath of the launched JVM included "." which means the current directory. It was the class files in the current directory are loaded into JVM which were compiled by Eclipse. It was an old version of Eclipse which happens to not work well with JDK 1.8. There was a compilation error "The type java.lang.CharSequence cannot be resolved." in the source code:

The project was then built and packaged with Maven instead. The jar would be copied to classpath of the launching JVM and be loaded. But it would never happen if the classes are already loaded as separate class files instead of as jar file. So the error message literally means there is compilation error, if your build tool compiled successfully, the only reason would be that there are wrong classes are loaded by JVM, and you should add -verbose:class option to pinpoint what are actually loaded.

In this case, there are three solutions to solve this problem: change to another working directory, remove the "." in classpath of JVM, or fix the Eclipse compilation error.