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/ee90e16264776d160fdf04077a63f8eaf0681dbbb8bc1eae26764437@%3Cdev.sling.apache.org%3E > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
