Stefan Seifert wrote > >> 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.
I guess replacing the current implementation with something else is a lot of work as we might have some subtle deviations from the original code. In addition it would be good to get rid of our own json library and use something everyone else is using. So +1 for just deprecating the whole api, releasing it then and basically ending the life of that module. > > >> 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. > Yeah I think johnzon is a good alternative Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
