Risks of serializing and deserializing json in different newtonsoft versions - json

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.

Related

scala-json-rpc: value pretty is not a member of io.circe.Printer

i recently updated huge project from Scala 2.12 to 2.13 and switched form using
https://github.com/shogowada/scala-json-rpc
to:
https://github.com/nawforce/scala-json-rpc
And few methods - jsonRPCServer.{bindApi, receive} and jsonRPCClient.createAPI - started giving me this error:
value pretty is not a member of io.circe.Printer
It didn't appear in the former version of the library. I tried to examine the sources, but failed to find the problematic calls.
Do, by any chance, any of you had similiar problem?
Looking at Scaladex and looking at the circe dependency for both packages (Scaledex for the original, Scaladex for the fork you are using), it has been upgraded from 0.8.0 to 0.13.0. Looking at this commit it looks like pretty has been deprecated in 0.12.0 (and judging from your post, probably dropped in 0.13.0) and replaced by printWith, which is likely what you want to use.

Jackson 1.x to 2.x and the meaning of backwards compatibility

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

What to use in the face of deprecation of the scala.util.parsing.json._ package?

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.

JSON Jackson Shared references

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.

How can I marshal JSON to/from a POJO for BlackBerry Java?

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.