NoSuchMethodError when converting xml in string to JSONObject

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)

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.

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

Does not appear to be anything to fix here.

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.

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

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.

@powerqian

@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

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.

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

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.

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)

@stleary

@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.

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.

@AppWerft

@AppWerft gotcha... I'm not sure if having the API parity would work for you then. However, including only the portions of this project that you use locally and modifying them to work with the android JSONObject may work for you and have better performance than the recursive copy.

For example, only include the XML class from here, and then fix any compile issues that aren't supported by the Android version of JSONObject.

@stleary

@stleary I have been reviewing the Android implementation of the org.json namespace, and according to their comments, they did "A cleanroom implementation of the org.json API." back in 2010 that was API compatible with this project.

I'm not sure we can take anything from them, or give anything back. their comment headers at the top of each class they use look like this:

/*
 * Copyright (C) 2010 The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.json;

// Note: this class was written without inspecting the non-free org.json sourcecode.

Given that their license is generally more permissible than ours, we could possibly bring things in from there, like method comments. But they also have some things that I know we wouldn't like (support for comments in JSON /* inline comment */, // line comment, and # line comment)

I think that to go forward, we may want to look at adding another package called something like org.json.json-android-extension-VERSION.jar which only includes the classes that are not in Android.

Currently Android includes the following files:

JSON: static class that has things like validators and standard error generators. not implementation
JSONArray: API compatible with our version at around 2014-01-10
JSONException: API compatible with our version at around 2011-07-08
JSONObject: API compatible with our version at around 2013-12-16
JSONStringer: API compatible with our version at around 2010-03-12
JSONTokener: API compatible with our version at around 2010-03-12

I think we could possibly resolve this by ensuring that any of the non-android classes don't use some newer API features, or possibly submitting API compatible changes to the android project.

@johnjaylward

@johnjaylward thanks for doing the analysis.

Android may someday choose to do another clean room implementation that includes support for XML and other classes.
Someone may decide to fork this project to provide an implementation that is Android-compatible.
Code changes that do not break existing applications, and manage to find a way to make life easier for the Android users, are welcome.

see #350

Realize that this comment is rather late, but I just had this occur in my project and my experience may help others ....
Added the following two lines to see where org.json.XML and org.json.JSONObject originated.

System.out.println(org.json.JSONObject.class.getProtectionDomain().getCodeSource().getLocation());
System.out.println(org.json.XML.class.getProtectionDomain().getCodeSource().getLocation());

Turns out that another pom dependency had their own version of org.json ....
file:/C:/Users/xxx/.m2/repository/com/tdunning/json/1.8/json-1.8.jar
file:/C:/Users/xxx/.m2/repository/org/json/json/20171018/json-20171018.jar

Edit:
The "offending" dependency was Apache Tika Parser. Their change log:

Remove non-ASL-2.0-compatible org.json (TIKA-1804)

Further background from ASF: https://issues.apache.org/jira/browse/TC-50

it would help if people used their own namespace... even if it was just bob.org.json, or android.org.json. it would make life much easier for dependency management.

This issue has been addressed to the extent that we can from this side. For more information please see the wiki page: https://github.com/stleary/JSON-java/wiki/JSON-Java-for-Android-developers

Seeing this issue again its because this package name conflicts with other android json. Only way around this is to download the jar and add it as a lib. Or use jarjar and rename the package. Might want to rename this package for the future

We will not be renaming this package as it's the originator of the namespace

Renaming the package is not on the table, but someone could look into upgrading the Android code to be compatible with JSON-Java.

Navigation Menu

Repository navigation

NoSuchMethodError when converting xml in string to JSONObject #213

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

NoSuchMethodError when converting xml in string to JSONObject #213

Description

Activity

stleary commented on Mar 31, 2016

johnjaylward commented on Mar 31, 2016

stleary commented on Apr 6, 2016

AppWerft commented on Sep 21, 2016

stleary commented on Sep 21, 2016

powerqian commented on Jan 5, 2017

AppWerft commented on Jan 5, 2017

stleary commented on Jan 5, 2017

AppWerft commented on Jan 5, 2017

stleary commented on Jan 5, 2017

johnjaylward commented on Jan 5, 2017

johnjaylward commented on Jan 5, 2017

AppWerft commented on Jan 5, 2017

johnjaylward commented on Jan 5, 2017

johnjaylward commented on Jun 20, 2017

stleary commented on Jun 21, 2017

johnjaylward commented on Jun 21, 2017

slankas commented on Oct 26, 2017

johnjaylward commented on Oct 27, 2017

stleary commented on Jan 13, 2018

grndvl1 commented on Nov 18, 2021

johnjaylward commented on Nov 18, 2021

stleary commented on Nov 19, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions