Stefan Seifert wrote > i've created https://issues.apache.org/jira/browse/SLING-6536 to track option > a) > unfortunately the unit test converage to the affected classes is not very > high, this makes replacing the impl difficult. > True, I think someone posted a link on the felix dev list some time ago about a clean room implementation from google/android of the json.org api. That one has ASF license, so maybe we can just copy that code, add ordering and are done
Carsten > stefan > >> -----Original Message----- >> From: Carsten Ziegeler [mailto:[email protected]] >> Sent: Tuesday, February 21, 2017 9:21 AM >> To: [email protected] >> Subject: Re: Removing dependency to org.json >> >> Stefan Seifert wrote >>> >>>> The biggest usage is our own commons.json library which is currently a >>>> copy of the org.json source. So we have to completely replace this. >>> >>> do we have a plan what to do about commons.json? >> >> No :) So let's create one. >> >>> do we plan to keep the existing exported API and just replace the >> implementation? >> >> I think we have to options: >> a) keep the API and replace the impl >> b) completely get rid of the module and remove it's usage everywhere. >> >> I think, even if we go with a) we should deprecate the API and replace >> it's usage over time. >> On the other hand, if we just do b) then everyone still using >> commons.json suffers from the problematic license. Not sure how much of >> a problem that is though. >> >>> do we have a list of features in what ways this implementation differs >>from json.org, or from others which may replace it (see discussion on [2])? >> >> I guess we don't. I think we added ordering, but other than that I'm not >> aware of functional changes. >> >>> >>> after playing around with the new simple JSONParser from felix utils >> there are at least two major differences which are also deviations from the >> JSON spec: >>> - the parser keeps object ordering (like gson, jackson, but not following >> the spec) >>> - the parser can parse files which includes comments and ignores them >> (comments not allowed in spec) >>> >>> if i read jim's post [1] correct we have to find a solution within the >> next two months, after this we can not make new releases of commons.json or >> any library that depends on it. this affects ~45 sling modules. >> >> Wow, so we're using this library a lot. I guess we should go with a) in >> this case. >> >> Carsten >> >>> >>> stefan >>> >>> [1] https://mail-archives.apache.org/mod_mbox/www-legal- >> discuss/201611.mbox/%[email protected]%3E >>> [2] >> https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681d >> bbb8bc1eae26764437@%3Cdev.sling.apache.org%3E >>> >> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
