I started to do some prototype patches and create issues for the johnzon replacement (SLING-6679 and sub-tasks) but I'm not so super happy about it. It would be good if we can get some reviews and see what others think. Towards that end:
The first 5 sub-tasks have some patches that would need some clean-up before they can be applied but they should be enough to show the general idea and some of the problems. Please have a look and see if it makes sense to continue like this (Notice the comment on restrictions put on sling by this approach in SLING-6679 as well). On Thu, Mar 16, 2017 at 3:33 PM, Karl Pauls <[email protected]> wrote: > Ok, it sounds like 1) we are fine with deprecating all classes in the > commons.json bundle and do one more release (I'll increase the minor > number of the package version as well) and 2) replace exiting usage > inside sling with Johnzon. I'll start with the deprecation release > asap and then start to provide patches for the replacement. > > regards, > > Karl > > On Tue, Mar 14, 2017 at 5:20 PM, Carsten Ziegeler <[email protected]> > wrote: >> 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] > > > > -- > Karl Pauls > [email protected] -- Karl Pauls [email protected]
