I have an ear app with two EJB and one WEB (war) projects all using compiler compliance 1.5. In my web project I created a utility Class file that takes a byte array of an xml file and returns some string values using the vtd-xml library v2.10 and I instantiate an object of this class in a servlet. At the call of the constructor of the object (that takes a byte array) I get the error:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
When I remove all vtd-xml related objects from the class I do not get this error. Any advice would be appreciated.
Regards
It sounds like the vtd-xml jar file has classes in it that are 1.6
you can recompile using the build.bat file (included with vtd-xml.zip) to obtain a new vtd-xml.jar.
The documentation says:
Thrown when the Java Virtual Machine attempts to read a class file and determines that the major and minor version numbers in the file are not supported.
The library you are using must have been compiled with a different version of Java.
Now it works executing build.bat file (included with vtd-xml.zip) but you need to edit the target version to 1.5 instead of 1.6
Related
I'm currently getting this error:
java.lang.NoSuchMethodError: org.json.JSONObject.keySet()Ljava/util/Set;
at ee.ut.cs.Parser.accessLint(Parser.java:39)
I have tried cleaning the project to no awail.
I suspect I have an error in the src/plugin/parse-htmlraw/build.xml while creating the jar file but I'm not certain. I understand that this error is because the function does not exist at runtime, but the object is created which means that the class is there, just not that function. I decompiled the .class file in created jar and it has the necessary functions.
Code is available at https://github.com/jaansusi/WCAGgrader
Q: What is wrong with the build that produces this error?
The problem is that even if I put the necessary class files in the jar I create, they are not linked correctly and the class that's called in the jar can't locate functions inside the other classes. The class object JSONObject is created but the functions inside the JSONObject class can't be found.
If you do not find the problematic version, there is a possibility you get it (especially if you are using Spring) from the following dependency -
<artifactId>android-json</artifactId>
<groupId>com.vaadin.external.google</groupId>
excluding it worked for me,
An easy way of analyzing dependencies is the maven-helper plugin in Intellij, see here
Check for the version you have used.
There might be a case where 2 different versions are being used which in turn causes this error.
To their own maven local repository com\Google\code\gson\gson, see if there are two or more version about json, will have to do is to delete the old, and remember to look at any other place in the project is introduced into the old version of the dependence, if any, change the old version of the dependence to the new version is perfectly solved this problem
I have some code that depends on jars that were compiled using Java 1.7. I am currently working on OSX, where I only have access to Java 1.6. I am currently attempting to recompile these jars locally. However, the jars only contained the .class files. I downloaded a disassembler and saved the resultant .java files. Now, there are some errors that I am currently trying to debug. One of the files checks to see if some parameter is equal to a class or type. The problem I'm having is that there is the expression
if (paramType.equals([D.class)) { ... }
which is causing a compiler error. What is the proper way of expressing a double array class?
Assuming it's an array of (primitive) double:
if (paramType.equals(double[].class)) { ... }
Or if it's an array of (wrapper type) java.lang.Double:
if (paramType.equals(Double[].class)) { ... }
If the classes don't link against any new library classes introduced in Java 1.7, then they should work just fine in Java 1.6, as the only bytecode features introduced in 1.7 are not actually used in Java.
All you have to do is change the 8th byte of every file from 51 to 50. You don't even have to disassemble and reassemble them.
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.
Download this jar
It resolved my problem, this is 1.7.
I faced the same problem with JBoss 4.2.3 GA when deploying my web application. I solved the issue by copying my commons-codec 1.6 jar into C:\jboss-4.2.3.GA\server\default\lib
You need the Apache Commons Codec library 1.4 or above in your classpath.
This library contains Base64 implementation.
Try add 'commons-codec-1.8.jar' into your JRE folder!
Simply create an object of Base64 and use it to encode or decode, when using org.apache.commons.codec.binary.Base64 library
To Encode
Base64 ed=new Base64();
String encoded=new String(ed.encode("Hello".getBytes()));
Replace "Hello" with the text to be encoded in String Format.
To Decode
Base64 ed=new Base64();
String decoded=new String(ed.decode(encoded.getBytes()));
Here encoded is the String variable to be decoded
I am taking the input from the web, which is an Xml file and converting into a Json data using the library json-lib . I have created a user library and added the following jars into it:-
json-lib-2.3-jdk15.jar
commons-collections.jar
commons-lang.jar
commons-logging.jar
commons-beanutils.jar
ezmorph-1.0.6.jar
xom-1.1.jar
But still gives the following error:-
08-04 13:58:31.642: ERROR/dalvikvm(484): Could not find class 'net.sf.json.xml.XMLSerializer$CustomElement', referenced from method net.sf.json.xml.XMLSerializer.addNameSpaceToElement
Can anyone help me out in resolving this issue.
Either you have a sdk level / jdk level conflict. I mean dalvik can't get the byte code of the CustomElement class of your librairy as it is compiled with to recent features for your SDK like annotations for instance.
Or there is a conflicting librairy json-lib in some other of your jars or lib folders.
(the 3 first comments are not relevant, it's just the way inner classes are compiled, using a $)
Regards,
Stéphane
Since android already support json org.json a different json library may conflict. (You can download the jar here)
Try to use this library instead of an external library on android.
BTW: You can also use this library if you need on any java code (not only android)
I have implemented successfully the reflectionEquals method, with a list of excluded fields.
return EqualsBuilder.reflectionEquals(this, obj, new String[] {"files", "notes", "status"});
However, I recently compiled my program on Java 1.5 and now I get the following error when the program hits the above line:
java.lang.NoSuchMethodError:
org.apache.commons.lang.builder.EqualsBuilder.=
reflectionEquals(Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/String;)Z
If anyone has an insight on why the method does not exist at runtime, I would appreciate it
Every NoSuchMethodError that I've ever encountered has (eventually) been found to be a mismatch between the version of an external library on the classpath at compile time vs. the version of the library on the classpath at runtime (i.e. - in this case, you would have a different version of apache commons on your classpath when the application is compiled than when it is running.)
The method was definitely there when your code was compiled - or a compiler error would've been thrown.
Check the versions of commons-lang.jar on your classpaths - I'm betting you'll find a mismatch.
It's worth noting that this is NOT a MISSING jar file - that would throw a ClassNotFoundException (maybe eventually followed by a NoClassDefFoundError.)
This is likely a var args problem. Be sure to recompile everything in java 1.5 and be sure you are running it on java 1.5, and be sure you reference the same jar at compilation as at runtime.
You may have an older version on your runtime classpath.
Get the latest version of Apache Commons Lang