dsl-json seems to be fast, and the license seems to be compatible (BSD 3-Clause). However, this is a quite new project, which is java-8 oriented AFAICS. I guess the JSON library we will choose should be java 1.5, 6, 7 & 8 compatible...
On Wed, Nov 23, 2016 at 6:37 PM, Martin Grigorov <[email protected]> wrote: > Better use https://github.com/fabienrenaud/java-json-benchmark > The article by Takipi is both old and the testing approach is inaccurate. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 23, 2016 at 6:25 PM, Tobias Soloschenko < > [email protected]> wrote: > > > Hi, > > > > we should also consider the performance impact, shouldn't we? > > > > http://blog.takipi.com/the-ultimate-json-library-json-simple > > -vs-gson-vs-jackson-vs-json/ > > > > kind regards > > > > Tobias > > > > Am 23.11.16 um 17:26 schrieb Sebastien: > > > > I'm +1 for jackson. We already use it in wicket-extensions > >> > >> https://github.com/apache/wicket/blob/master/wicket-extensio > >> ns/src/main/java/org/apache/wicket/extensions/requestlogge > >> r/JsonRequestLogger.java#L22 > >> > >> Moreover, I'm personally fine to rely on a 3rd party library for JSON > >> objects. That way you can use the same library back-end side and get the > >> JSON objects back (no deserialization issues, which is not true if a > >> specific JSON lib is front-end side only, like for our JSON internal > lib) > >> > >> > >> On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst < > >> [email protected]> wrote: > >> > >> Another option would be to use jackson and use the JSON classes in > >>> Wicket as API wrappers. > >>> > >>> Martijn > >>> > >>> > > >
