NoSuchMethodError when converting xml in string to JSONObject

[AvinashChowdary]

java.lang.NoSuchMethodError: No static method stringToValue(Ljava/lang/String;)Ljava/lang/Object; in class Lorg/json/JSONObject; or its super classes (declaration of 'org.json.JSONObject' appears in /system/framework/core-libart.jar)
at org.json.XML.parse(XML.java:241)
at org.json.XML.toJSONObject(XML.java:331)

[stleary]

Can you tell us a little more about your build and execution environments? Looks like the JSON lib may not be accessible to your executable.

[johnjaylward]

looks like a classpath issue where it was built against one version of json-java, but released with an older version.

[stleary]

Does not appear to be anything to fix here.

[AppWerft]

I have used the the sources in my project because of the CDATA issue. The precompiled jar (suggested by johnjaylward ) runs in this bug. It is amazing: I can compile and at run time comes this error.

[stleary]

How can this problem be recreated, so it can be investigated?

[powerqian]

I come across with this issue using the latest release build (json-20160810.jar) in an Android project, trying to convert a string in XML format to JSON. Since Android SDK already has the org.json package, and that version does not have the stringToValue in JSONObject. At compile time, the IDE successfully resolve the method call into the provided .jar file, but at run time, it tried to access the version provided by Android SDK somehow. Not sure whether there's any work around on this or not... One approach I think think of is import the source code and change the package.

[AppWerft]

@powerqian This is a known problem. I solved the problem with a recursive copy method. This function converts from stearly's JSONObject to to standard JSONObject. Look here: https://github.com/AppWerft/Ti.XML2Json/blob/master/android/src/de/appwerft/remotexml/JSON.java

[stleary]

So far the problem seems to be limited to XML. Perhaps a workaround from our side is possible, so long as it does not change the package name or existing functionality for non-Android users. Let me know if you have any suggestions on how to do this.

[AppWerft]

I know my solution is a workaround. The clean solution would be to rename your class an your class extends the standard JSONObject class.

[stleary]

Can someone demo the problem with minimal code? For example, an XML string and some lines of code, which work when using the the standalone lib, but fail with a runtime exception when executed in an Android environment.

[johnjaylward]

I think renaming the XML class to something else would not solve the issue here. The XML class is not in the android toolkit. https://developer.android.com/reference/org/json/package-summary.html

Also, by definition, this project is the "standard JSONObject", so extending it from the Android one is a bad idea.

The problem is that Android decided to include part of this project with the same package structure, but did not include all the tools (XML). So when users try to include this project there is a class path lookup error.

The best solution for developers on Android, would be to download the source for this project and use it directly in their project under their own packages (not org.json)

[johnjaylward]

@stleary I think the best option moving forward would be to ask Android for some contributions back on their javadoc updates (they added in a lot of good documentation) and to have them possibly update to the latest version of this project in the newer SDKs.

It appears that the main issue with the classpath is that not all the functions on JSONObject that the XML class expects are available in the version included in the SDK. Having the APIs be in parity would solve many class loader issues I believe.

[AppWerft]

OK, you are right, but in my case my framework uses a class KrollDict and this extends JSONObject. This JSONObject != JSONObject of stearly. The XML2JSON convert generates an stleary object, but my class aspects a standard JSONObject. This is the problem, and therefore I recursively copy.