>1) Is the above the way to go (and assuming it is) on the long run this would be the best solution. there was some idea about keeping the sling commons.json code and solve the license problem by replacing the implementation. there were some hints about a "cleanroom-implementation" from android with the same API, but following my research documented in SLING-6536 there is no 1:1 replacement available (at least i did not found it). another solution could be to replace the implementation of the commons.json code internally with a thirdparty json library. but this might get very hard when the philosophy of json API usage differs (this is the case e.g. between commons.json and johnzon) and is perhaps more effort than replacing the usage with another thirdparty library.
>2) What should I try to replace it with (there is a lot of json >libraries out there: somebody suggested johnzon.apache.org but I'm >certainly willing to look into others). from the proposed libraries i like apache johnzon most. it's very compact and not so "bloated" as gson and Jackson, although of course much younger and perhaps less mature. there is an outstanding issue using it in OSGi container documented in GERONIMO-6560, JOHNZON-108 (i've provide PRs). and a barebone implementation like in felix util [1] is just not enough because JSON comments and object ordering are not supported (which is correct following the JSON spec, but sling relies on it on several places). another plus of johnzon is usage of the standardized javax.json API. to get a feeling how a migration from commons.json to johnzon "feels like" i've migrated the maven-sling-plugin to it (SLING-6619). this was an unproblematic use case because the plugin does not run in OSGi and has not effect on the Launchpad etc. converting JSON reading code is not really hard, although there are of course subtle differences. converting writing code is more complex because johnzon follows a builder pattern with immutable JSON objects, whereas commons.json JSON objects are always mutable. thus bigger refactorings might be required which is difficult if the module has insufficient unit test coverage. i also used johnzon in the new (not yet released) fsresource 1.x and 2.x modules. because this bundles is often manually deployed in a running instance i embedded johnzon here directly, at least until a commons.json replacement has settled. stefan [1] https://svn.apache.org/repos/asf/felix/trunk/utils/src/main/java/org/apache/felix/utils/json
