Re: New JSON library
Hi I like this approach. As to replacement options: I'd go for Apache Johnzon. First it's Apache hence eating our own dogfood. But more importantly, it is an implementation of the standard javax.json API. I much prefer standard APIs over the fragmented JSON API scene. Regards Felix Von meinem iPad gesendet > Am 01.12.2016 um 23:14 schrieb Justin Edelson : > > While I think that it is a good idea in theory to remove our custom JSON > library, I don't think that is practical in the near term. So I think our > best course of action is a multistep process: > > 1) Rewrite org.apache.commons.json using > https://github.com/tdunning/open-json. > 2) Select a new standard library > 3) Modify internal-usages of org.apache.commons.json to use library from #2. > 4) Handle API usage of org.apache.commons.json on a case-by-case basis. > > Agree with Stefan that Semantic Versioning is critical for library > selection. I'm not sure that Jackson actually does this. As far as I can > tell, they only use SemVer at the bundle level, not the package level. > > > On Thu, Dec 1, 2016 at 4:32 PM Stefan Seifert > wrote: > >> following [4] it looks that the best options are currently either GSON or >> Jackson. >> i think GSON has smaller footprint and is more compact, but both are good >> options. >> >> another criteria for choosing is: do they publish their APIs following >> semantic versioning? otherwise we have the same dilemma as with guava. >> for jackson this is the case, see >> https://github.com/FasterXML/jackson/wiki/Jackson-Releases >> for gson i've not found a documentation, but it seems they follow it as >> well, have not checked in detail. >> >> stefan >> >> >>> -Original Message- >>> From: Robert Munteanu [mailto:rmunt...@adobe.com] >>> Sent: Monday, November 28, 2016 10:35 PM >>> To: dev@sling.apache.org >>> Subject: New JSON library >>> >>> Hi, >>> >>> The JSON license has been moved to 'Category X' [1] which means that we >>> can no longer use the org.json library. This has been announced on the >>> legal@ mailing list, please see [2] for the complete picture. >>> >>> We have until 30 Apr 2017 to remove all dependencies and inclusions of >>> the org.json library. We may decide to do this earlier, of course. >>> >>> I think it's a good time to drive down the TEF [3] of Sling and move to >>> using a more mainstream JSON library. I don't have a strong opinion on >>> the replacement, but I added a couple of ideas at [4]. >>> >>> Anyone with an opinion, do chime in :-) >>> >>> Thanks, >>> >>> Robert >>> >>> >>> [1]: https://www.apache.org/legal/resolved#category-x >>> [2]: https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b >>> 885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E >>> [3]: Technical Exoticity Factory - I made it up on the spot >>> [4]: https://cwiki.apache.org/confluence/display/SLING/New+JSON+library >>
Re: New JSON library
While I think that it is a good idea in theory to remove our custom JSON library, I don't think that is practical in the near term. So I think our best course of action is a multistep process: 1) Rewrite org.apache.commons.json using https://github.com/tdunning/open-json. 2) Select a new standard library 3) Modify internal-usages of org.apache.commons.json to use library from #2. 4) Handle API usage of org.apache.commons.json on a case-by-case basis. Agree with Stefan that Semantic Versioning is critical for library selection. I'm not sure that Jackson actually does this. As far as I can tell, they only use SemVer at the bundle level, not the package level. On Thu, Dec 1, 2016 at 4:32 PM Stefan Seifert wrote: > following [4] it looks that the best options are currently either GSON or > Jackson. > i think GSON has smaller footprint and is more compact, but both are good > options. > > another criteria for choosing is: do they publish their APIs following > semantic versioning? otherwise we have the same dilemma as with guava. > for jackson this is the case, see > https://github.com/FasterXML/jackson/wiki/Jackson-Releases > for gson i've not found a documentation, but it seems they follow it as > well, have not checked in detail. > > stefan > > > >-Original Message- > >From: Robert Munteanu [mailto:rmunt...@adobe.com] > >Sent: Monday, November 28, 2016 10:35 PM > >To: dev@sling.apache.org > >Subject: New JSON library > > > >Hi, > > > >The JSON license has been moved to 'Category X' [1] which means that we > >can no longer use the org.json library. This has been announced on the > >legal@ mailing list, please see [2] for the complete picture. > > > >We have until 30 Apr 2017 to remove all dependencies and inclusions of > >the org.json library. We may decide to do this earlier, of course. > > > >I think it's a good time to drive down the TEF [3] of Sling and move to > > using a more mainstream JSON library. I don't have a strong opinion on > >the replacement, but I added a couple of ideas at [4]. > > > >Anyone with an opinion, do chime in :-) > > > >Thanks, > > > >Robert > > > > > >[1]: https://www.apache.org/legal/resolved#category-x > >[2]: https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b > >885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E > >[3]: Technical Exoticity Factory - I made it up on the spot > >[4]: https://cwiki.apache.org/confluence/display/SLING/New+JSON+library >
RE: New JSON library
following [4] it looks that the best options are currently either GSON or Jackson. i think GSON has smaller footprint and is more compact, but both are good options. another criteria for choosing is: do they publish their APIs following semantic versioning? otherwise we have the same dilemma as with guava. for jackson this is the case, see https://github.com/FasterXML/jackson/wiki/Jackson-Releases for gson i've not found a documentation, but it seems they follow it as well, have not checked in detail. stefan >-Original Message- >From: Robert Munteanu [mailto:rmunt...@adobe.com] >Sent: Monday, November 28, 2016 10:35 PM >To: dev@sling.apache.org >Subject: New JSON library > >Hi, > >The JSON license has been moved to 'Category X' [1] which means that we >can no longer use the org.json library. This has been announced on the >legal@ mailing list, please see [2] for the complete picture. > >We have until 30 Apr 2017 to remove all dependencies and inclusions of >the org.json library. We may decide to do this earlier, of course. > >I think it's a good time to drive down the TEF [3] of Sling and move to > using a more mainstream JSON library. I don't have a strong opinion on >the replacement, but I added a couple of ideas at [4]. > >Anyone with an opinion, do chime in :-) > >Thanks, > >Robert > > >[1]: https://www.apache.org/legal/resolved#category-x >[2]: https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b >885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E >[3]: Technical Exoticity Factory - I made it up on the spot >[4]: https://cwiki.apache.org/confluence/display/SLING/New+JSON+library