I couldn't find an answer to my question on the net (maybe I did not search well enough, since I am still a novice on this).
Could anyone tell me if Jackson and Gson implement the standard JSR 353: Java™ API for JSON Processing. I would like to write using standard code.
This link has the reply (apparently by the Jackson founder), and it essentially says that Jackson doesn't implement the JSR:
Reply by Tatu Saloranta on January 26, 2014 at 8:21pm
I am not a big fan of JSR-353 (I consider it a big fail) and unless something drastic happens, Jackson core will not implement JSR-353. There is no benefit from data-binding to use it; both because implementations do not bring anything to table (none are particularly fast), nor implement all that databind needs (base64 encoding, multi-format support capabilities) -- and worst of all ALL existing (de)serializers would need to be rewritten use new, less capable API. And baseline for Jackson would need to become Java 8. So I see no upside.
However, the reverse is possible; it is possible to have a JSR-353 implementation based on Jackson streaming package, and this has been done already:
https://github.com/pgelinas/jackson-javax-json.
Or, to make Jackson capable of reading/writing JSR-353 JSON object types, a simple datatype module is needed. I wrote one a while back:
https://github.com/FasterXML/jackson-datatype-jsr353
So if Java developers end up following "the standard" track, Jackson can play along.
Google didn't (couldn't?) vote on the JSR, and I couldn't find anything on Gson's roadmap either to suggest that they'd want to comply.
tl;dr
Use:
JSON-P
JSON-B
Update
The other two Answers are correct, but outdated. As they explain, Jackson does not directly implement any JSR.
However:
There is a project providing a datatype module to help make Jackson more compatible with JSR 353: jackson-datatype-jsr353.
JSR 353 is superseded by JSR 374: Java™ API for JSON Processing 1.1.
The JCP continued work on JSON support, for processing of JSON as well as binding yielding the pair of JSRs: 374 JSON-P & 367 JSON-B.
JSR 374 defines JSON processing (JSON-P).
See project page for JSON-P.
A reference implementation can be found in Glassfish, the reference implementation of Jakarta EE (formerly known as Java EE).
JSR 367 provides binding capabilities (JSON-B).
See the project page for JSON-B.
Yasson is the reference implementation.
So you may indeed now write in standard code using JSON libraries other than Jackson.
No, neither implements this API natively, nor has plans (that I know of) to implement it. As far as JCP standards go, this is DOA; it offers very little (dumbed-down streaming API, no data-binding at all), and there is very little incentive for anyone to implement it, except to add compatibility check-box for set of JSRs implemented.
There is a Jackson-based JSR-353 implementation available at https://github.com/pgelinas/jackson-javax-json/ however, if you really think it is good idea to base your code on this API.
Related
How to solve Scala Problem?
I have warning by JSON usage in my project:
Object JSON in package json is depricated. This object will be
removed.
import scala.util.parsing.json._
JSON.parseRaw("[{'a':'b'},{'c':'d'}]")
Usually, this means a piece of functionality has been superseded by another implementation the use of which is preferred over the old one and a question like this simply means the OP is too lazy to google the docs. This is especially true in case of libraries in the Java language, which treats backward compatibility very seriously (to the point it becomes a pain for some). The Scala ecosystem is not so strict in this regard and upgrading to a newer version of the language means you can get a different API or even binary incompabilities. See also Scala: binary incompatibility between releases. This is not a comment against Scala. There are good reasons these incompatibilities exist.
However, I must admit that the documentation for scala.util.parsing.json does not contain any information regarding the recommended replacement for this functionality whatsoever. It took me quite a while to dig up something that just barely resembles a clear statement of what the recommended replacement is.
There seems to have been a lot of discussion in the community about the point and repercussions of this deprecation. I recommend reading this thread in the scala-users group if you're interested.
The most quoted reasons for this deprecation seem to be around poor performance and thread safety.
The deprecation was done as part of this Jira issue and the use of different parsers is recommended in the closing comment of this related task that was not completed due to the deprecation.
Alternatives include:
play-json
spray-json
argonaut
jackson
rapture-json (which allows you to choose between different implementations)
To answer your question. This is a warning, your code should not break until this object is actually removed. However, if new bugs are found in this functionality, they most likely aren't going to be fixed. Your code can also break if you upgrade to a newer version of Scala that actually has those packages removed (Version 2.11.0 and above, according to the documentation)
The answer previously provided by #toniedzwiedz is very complete and describe the whole story around the question.
I just had the same issue using Scala 2.11 and I solved adding the dependencies which are in this repository.
In particular, for Scala 2.11 is:
<dependency>
<groupId>org.scala-lang.modules</groupId>
<artifactId>scala-parser-combinators_2.11</artifactId>
<version>1.1.0</version>
</dependency>
Then you will not have the warning.
Also considere using Lift JSON as an alternative
https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/
The JSON parser in the Scala standard library is deprecated. You should pick one of more robust third-party libraries like Jackson, Play-Json, json4s, etc.
There are many possibilities to parse a JSON in context of a Windows Store App.
Regardless in which language (C#, JavaScript or C++).
For example: .NET 4.5 JsonObject and DataContractJsonSerializer, JavaScript Json parser or an extern one like Json.NET.
Does anybody know something about that?
I only read good things about Json.NET's performance.
But are they true and play that a role for JSON's which include datasets of 100k JSON objects? Or the user won't notice a difference?
I only have experience using Json.NET ... works just fast and great! I also used the library in enterprise-projects - i never got disappointed!
If it helps, and FWIW, I've been collecting recently some new JSON parsing / deserialization performance data that can be observed over various JSON payload "shapes" (and sizes), when using four JSON librairies, there:
https://github.com/ysharplanguage/FastJsonParser#Performances
(.NET's out-of-the-box JavaScriptSerializer vs. JSON.NET vs. ServiceStack vs. JsonParser)
Please note:
these figures are for the full .NET only (i.e., the desktop / server tier; not mobile devices)
I was interested in getting new benchmark figures about parsing / deserialization performances only (i.e., not serialization)
finally, I was also especially interested (although not exclusively) in figures re: strongly typed deserialization use cases (i.e., deserializing into POCOs)
'Hope this helps,
I have an Object that is reference by two other Objects
I use Jackson to serialize my objects but have found my shared object is duplicated rather than reference.
The reason is as I understand that Jackson can only serialize by value and not by reference.
I have unsuccessfully looked around for some recommended solution.
Any and all help is appreciated.
current Jackson Lib 1.8.3
Well time passed and Jackson 2.0 is out. Here is the requested feature ! I answer this so people like me coming after know its available
https://github.com/FasterXML/jackson-docs/wiki/Presentation-Jackson-2.0
Currently (1.9) you would have to write custom serializer, deserializer, to handle this. There is no out-of-the-box support for handling object identity.
Of Java frameworks the only one that I know to support object identities is XStream.
For what it is worth, there is a long-standing feature request for Jackson to add support. And there is reasonable chance this gets worked on for 2.0. But even if it will be, it'll take a while (a month or two).
UPDATE (April 2013): As per the other accepted answer, this feature -- #JsonIdentityInfo -- was indeed included in Jackson 2.0, and is available. No need for custom (de)serializers.
I'm writing a RIM BlackBerry client app. BlackBerry uses a simplified version of Java (no generics, no annotations, limited collections support, etc.; roughly a Java 1.3 dialect). My client will be speaking JSON to a server. We have a bunch of JAXB-generated POJOs, but they're heavily annotated, and they use various classes that aren't available on this platform (ArrayList, BigDecimal, XMLGregorianCalendar). We also have the XSD used by the JAXB-XJC compiler to generate those source files.
Being the lazy programmer that I am, I'd really rather not manually translate the existing source files to Java 1.3-compatible JSON-marshalling classes. I already tried JAXB 1.0.6 xjc. Unfortunately, it doesn't understand the XSD file well enough to emit proper classes.
Do you know of a tool that will take JAXB 2.0 XSD files and emit Java 1.3 classes? And do you know of a JSON marshalling library that works with old Java?
I think I am doomed because JSON arrived around 2006, and Java 5 was released in late 2004, meaning that people probably wouldn't be writing JSON-parsing code for old versions of Java.
However, it seems that there must be good JSON libraries for J2ME, which is why I'm holding out hope.
For the first part good luck but I really don't think you're going to find a better solution than to modify the code yourself. However, there is a good J2ME JSON library you can find a link to the mirror here.
I ended up using apt (annotation processing tool) to run over the 1.5 sources and emit new 1.3-friendly source. Actually turned out to be a pretty nice solution!
I still haven't figured out an elegant way to do the actual JSON marshalling, but the apt tool can probably help write the rote code that interfaces with a JSON library like the one Jonathan pointed out.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Is DOM the only way to parse JSON?
Some JSON parsers do offer incremental ("streaming") parser; for Java, at least following parsers from json.org page offer such an interface:
Jackson (pull interface)
Json-simple (SAX-style push interface)
(in addition to Software Monkey's parser referred to by another answer)
Actually, it is kind of odd that so many JSON parsers do NOT offer this simple low-level interface -- after all, they already need to implement low-level parsing, so why not expose it.
EDIT (June 2011): Gson too has its own streaming API (with gson 1.6)
By DOM, I assume you mean that the parser reads an entire document at once before you can work with it. Note that saying DOM tends to imply XML, these days, but IMO that is not really an accurate inference.
So, in answer to your questions - "Yes", there are streaming API's and "No", DOM is not the only way. That said, processing a JSON document as a stream is often problematic in that many objects are not simple field/value pairs, but contain other objects as values, which you need to parse to process, and this tends to end up a recursive thing. But for simple messages you can do useful things with a stream/event based parser.
I have written a pull-event parser for JSON (it was one class, about 700 lines). But most of the others I have seen are document oriented. One of the layers I have built on top of my parser is a document reader, which took about 30 LOC. I have only ever used my parser in practice as a document loader (for the above reason).
I am sure if you search the net you will find pull and push based parsers for JSON.
EDIT: I have posted the parser to my site for download. A working compilable class and a complete example are included.
EDIT2: You'll also want to look at the JSON website.
As stefanB mentioned, http://lloyd.github.com/yajl/ is a C library for stream parsing JSON. There are also many wrappers mentioned on that page for other languages:
yajl-ruby - ruby bindings for YAJL
yajl-objc - Objective-C bindings for YAJL
YAJL IO bindings (for the IO language)
Python bindings come in two flavors, py-yajl OR yajl-py
yajl-js - node.js bindings (mirrored to github).
lua-yajl - lua bindings
ooc-yajl - ooc bindings
yajl-tcl - tcl bindings
some of them may not allow streaming, but many of them certainly do.
If you want to use pure javascript and a library that runs both in node.js and in the browser you can try clarinet:
https://github.com/dscape/clarinet
The parser is event-based, and since it’s streaming it makes dealing with huge files possible. The API is very close to sax and the code is forked from sax-js.
Disclaimer: I'm suggesting my own project.
I maintain a streaming JSON parser in Javascript which combines some of the features of SAX and DOM:
Oboe.js website
The idea is to allow streaming parsing, but not require the programmer to listen to lots of different events like with raw SAX. I like SAX but it tends to be quite low level for what most people need. You can listen for any interesting node from the JSON stream by registering JSONPath patterns.
The code is on Github here:
Oboe.js Github page
LitJSON supports a streaming-style API. Quoting from the manual:
"An alternative interface to handling JSON data that might be familiar to some developers is through classes that make it possible to read and write data in a stream-like fashion. These classes are JsonReader and JsonWriter.
"These two types are in fact the foundation of this library, and the JsonMapper type is built on top of them, so in a way, the developer can think of the reader and writer classes as the low-level programming interface for LitJSON."
If you are looking specifically for Python, then ijson claims to support it. However, it is only a parser, so I didn't come across anything for Python that can generate json as a stream.
For C++ there is rapidjson that claims to support both parsing and generation in a streaming manner.
Here's a NodeJS NPM library for parsing and handling streams of JSON:
https://npmjs.org/package/JSONStream
For Python, an alternative (apparently lighter and more efficient) to ijson is jsaone (see that link for rough benchmarks, showing that jsaone is approximately 3x faster).
DISCLAIMER: I'm the author of jsaone, and the tests I made are very basic... I'll be happy to be proven wrong!
Answering the question title: YAJL a JSON parser library in C:
YAJL remembers all state required to
support restarting parsing. This
allows parsing to occur incrementally
as data is read off a disk or network.
So I guess using yajl to parse JSON can be considered as processing stream of data.
In reply to your 2nd question, no, many languages have JSON parsers. PHP, Java, C, Ruby and many others. Just Google for the language of your choice plus "JSON parser".