[ 
https://issues.apache.org/jira/browse/OFBIZ-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121310#comment-14121310
 ] 

Justen Walker commented on OFBIZ-5751:
--------------------------------------

Another option for a minimal library could be 
[GSON|https://code.google.com/p/google-gson/] (ASL 2.0). It also has no further 
dependencies beyond the JDK, Is under active development (Last release Aug 
2014) and it seems to perform pretty well in the comparative benchmarks that 
Pierre mentioned.

Having zero dependencies is a plus especially in a large project where the 
likelihood of transitive dependency version conflicts are high. 

That all said - Jackson is a good choice as long as the additional baggage 
isn't a problem.

> Replace JSON Parser with proper library
> ---------------------------------------
>
>                 Key: OFBIZ-5751
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5751
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>            Reporter: Justen Walker
>            Priority: Minor
>              Labels: json
>
> Recently I was bitten by the JavaCC JSON parser.  Apparently the folks 
> developing JavaCC thought that encountering an unexpected token in the input 
> stream should be treated like a StackOverflowError or OutOfMemoryError and 
> derive from the Error class rather than Exceptions - guaranteeing that no 
> sane try/catch block would be able to catch it (Since you aren't typically 
> expected to catch 
> [Errors|http://docs.oracle.com/javase/6/docs/api/java/lang/Error.html])
> A bit peeved by this design bug, I did some more investigation as to when 
> this class was added and why. I discovered that this was added 4 years ago 
> (February 10 2010) with the commit message admitting that - even though it 
> seemed unneeded - it would later be extended to be more useful. 
> It has been 4 year since that commit and the code has not been touched. In 
> that time (and perhaps even at that time) other production-ready libraries 
> have been created for parsing JSON; some which are extensible and full 
> featured as well those which are very simple and robust. (A list exists at 
> [json.org|http://json.org/])
> I don't see a need to keep maintaining a home-rolled JSON parsing library 
> inside the project that has to be built by everyone when other libraries 
> exist that do the job better and are less likely to have these pitfalls (due 
> to being actively developed).
> *References*
> - [Rev 908712 - 10 Feb 
> 2010|https://fisheye6.atlassian.com/changelog/ofbiz?cs=908712]
> - [File History of 
> JSON.jj|https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/json/JSON.jj]
> - [json.org (list of java libraries)|http://json.org/]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to