Replace and deprecate commons.json

[Karl Pauls <ka...@gmail.com>]

Hi all,

I guess I'm "volunteering" to look into SLING-6536 "Replace JSON
implementation derived from org.json code".

From what I understand, the idea would be to add an @Deprecated to all
classes in there and do one final release before the 1th of April
while at the same time replacing all usages of it inside sling with an
alternative.

The reason I'm bringing this to dev@ is mainly to ask two questions namely,

1) Is the above the way to go (and assuming it is)

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

If we have consensus on 1) I would do the releases and if we figured
out 2) I would try to come-up with patches switching to the new
library for the individual components that use commons.json and create
JIRA issues for them with the patch attached.

WDYT?

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Replace and deprecate commons.json

[Karl Pauls <ka...@gmail.com>]

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 <ka...@gmail.com> 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 <cz...@apache.org> 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
>> cziegeler@apache.org
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com



-- 
Karl Pauls
karlpauls@gmail.com

Re: Replace and deprecate commons.json

[Karl Pauls <ka...@gmail.com>]

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 <cz...@apache.org> 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
> cziegeler@apache.org



-- 
Karl Pauls
karlpauls@gmail.com

Re: Replace and deprecate commons.json

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org

RE: Replace and deprecate commons.json

[Stefan Seifert <ss...@pro-vision.de>]

>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