By necessity, I need to upgrade from Jackson 1.x to 2.x. After reading the notes on the release, I thought it would be fine to upgrade, so long as I made the necessary code changes:
http://wiki.fasterxml.com/JacksonRelease20
However, I realized after-the-fact that I still need to be able to deserialize data serialized with 1.x versions in the event that we have pre-upgrade data data flowing back into the service, which is guaranteed to happen.
Is Jackson 2.x suited to this or not? I understand that 2.x requires recompile, but can it still handle the old serialized format?
So, your case is that data serialized with Jackson 1, will be read by Jackson 2, this shouldn't be a problem at all, since both understand JSON format.
There is a possibility you have customizations based on annotation and hierarchies, even if this is the case, almost everything is supported in Jackson 1, should be supported in Jackson 2 (this is where backwards compatibility plays a role).
In the remote case you have something that only can be deserialized with Jackson 1, you can still do a rolling upgrade in your project, the Jackson guys did an amazing job in this scenario, where they changed all packages name to com.fasterxml.jackson from the old org.codehaus.jackson, this means that both version can live in your classpath, allowing you to upgrade things based on priorities, or incrementally.
I have experience in the 3 scenarios I mentioned, since our projects used to use Jackson 1 and now we moved all of them to the latest and greatest.
Hope this helps,
Jose Luis
Related
We have a Java EE 7 application running on a WildFly 9, consisting of an exploded EAR deployment, which contains several WAR files, some JARs at EAR level and a lib folder containing 3rd pary JARs. (I know this is not how one would do it today, but it is like it is.)
One of the WARs contains a JAX-RS REST service, which GETs and POSTs a data object which contains a Java 8 OffsetDateTime. Since JSON-B is not yet available, we used #JsonSerialize/#JsonDeserialize form jackson-databind in order to marshall it from and to JSON.
This worked quite well until due to a change of another WAR, the dependency jackson-jaxrs came into the lib folder at EAR level. What happened then was that the marshalling stopped working, since the container tried to set the date string from JSON directly into the OffsetDateTime type and when getting it, writing all the internal fields of the Java 8 date instead of the formatted string.
I assumed, that the processing of the above-mentioned annotations didn't take place and thus the server tried to map it like other simple types. When I deleted the JARs belonging to the jackson-jaxrs dependeny, everything worked fine again. The application server then probably used its own version of this very JAR from its modules folder.
So, my question is: What is the difference when having the jackson-jaxrs JAR in EARs lib folder additionally to the system provided module or only the latter? Why does it not consider the annontaions in the first case when de/serializing?
Wildfly 9 bundles jackson 1.9 as a base module and the annotations are in the org.codehaus.jackson package.
I suspect that the library added recently is the (more recent) jackson 2.x and the annotations are now in the com.fasterxml.jackson package.
If that's the case, upgrading to jackson 2.x (ideally the same version as the one your get from the EAR) should solve the problem.
Alternatively isolating your subdeployment from the jackson jar present in the EAR might work but it can be messy with transitive dependencies. See class loading in Wildfly
EDIT as you confirmed, there are two different versions running. If you can afford it, aligning the versions would most definitively help solving the problem.
Short of that, you might need to isolate each subdeployment's so it only sees the expected version. See this answer for example (which isolate the entire deployment from the base module).
I want to upgrade my newtonsoft dll,but I have serialized records in my db,is there any risk of upgrade newtonsoft version.Can I correctly deserialized my old records in new versions.In my tests I have no problems.But is there any knowing issue about that?By the way my newtonsoft is too old version.
Thanks
I would say the risk is pretty low of something breaking due to upgrading Json.Net, but it really depends on what features you are using. You can only know by running your own extensive tests (sounds like you have already done that) and by reading the release notes carefully to find out what changes have been made to Json.Net between the version you were originally using and the version you are using now.
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.
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.