I am developing a Java EE application in which I need Base64 Encoding/Decoding
So I added commons-codec-1.5.jar
in WEB-INF/lib
folder of my application and used
import org.apache.commons.codec.binary.Base64;
in the Java file.
During compile time, when I type Base64
, it shows encodeBase64String
method is available. But during runtime it is throwing an exception like this:
java.lang.NoSuchMethodError:org.apache.commons.codec.binary.Base64.encodeBase64String
I have the JAR in the buildpath, but still I don't understand why it throws me the above error.
That method was introduced in Commons Codec 1.4. This exception indicates that you've an older version of Commons Codec somewhere else in the webapp's runtime classpath which got precedence in classloading. Check all paths covered by the webapp's runtime classpath. This includes among others the Webapp/WEB-INF/lib
, YourAppServer/lib
, JRE/lib
and JRE/lib/ext
. Finally remove or upgrade the offending older version.
Update: as per the comments, you can't seem to locate it. I can only suggest to outcomment the code using that newer method and then put the following line in place:
System.out.println(Base64.class.getProtectionDomain().getCodeSource().getLocation());
That should print the absolute path to the JAR file where it was been loaded from during runtime.
Update 2: this did seem to point to the right file. Sorry, I can't explain your problem anymore right now. All I can suggest is to use a different Base64
method like encodeBase64(byte[])
and then just construct a new String(bytes)
yourself. Or you could drop that library and use a different Base64 encoder, for example this one.
Some Google tooling such as GWT has an embedded version of commons-codec with a pre-1.4 Base64 class. You may need to make such tooling JARs inaccessible to your code by refactoring your project such that only the parts of your code that need that tooling can see the dependency.
@Adam Augusta is right, One more thing
Apache-HTTP client jars also comes in same category as some google-apis.
org.apache.httpcomponents.httpclient_4.2.jar and commons-codec-1.4.jar both on classpath, This is very possible that you will get this problem.
This prove to all jars which are using early version of common-codec internally and at the same time someone using common-codec explicitly on classpath too.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With