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.
Related
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.
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 painfully come across the facts that scala.util.parsing and scala.swing are apparently no more bundled in Scala 2.11. Each time, I had to google for the right line to add to an sbt configuration, or to find the right link for where to download the jar file.
In case there are other libraries that moved out, how am I supposed to know these things? Or am I supposed to rely only on questions from people having the same problem on Stackoverflow? The Scala Swing project on github does not even document these info.
I like creating Eclipse projects on the fly, and making them depend on other projects in the same workspace, without going through sbt, and it is annoying to run into these library disappearance cases on every computer/workspace where I do this.
The modularization (what you call externalizing) has been discussed for a good while on the scala-users mailing list. But the canonical place where to find this information is in the release notes. While you may not want to read all of those, I would strongly advise reading at least the release notes for a major version of any language you use. Case in point, the release notes for Scala 2.11.0:
Modularization
The core Scala standard library jar has shed 20% of its
bytecode. The modules for xml, parsing, swing as well as the
(unsupported) continuations plugin and library are available
individually or via scala-library-all. Note that this artifact has
weaker binary compatibility guarantees than scala-library – as
explained above. The compiler has been modularized internally, to
separate the presentation compiler, scaladoc and the REPL. We hope
this will make it easier to contribute. In this release, all of these
modules are still packaged in scala-compiler.jar. We plan to ship them
in separate JARs in 2.12.x.
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.
I'd like to know what is the most efficient way of handling properties in Scala. I'm tired of having gazillion property files, xml files and other type of configuration files in Java and wonder if there's "best practice" to handle those someway more efficient in Scala?
Why would you have a gazillion property files?
I'm still using the Apache commons Digester, which works perfectly well in Scala. It's basically a very easy way of making a user-defined XML document map to method calls on a user-defined configurator class. I find it extremely useful when I want to parse some configuration data (as opposed to application properties).
For application properties, you might either use a dependency injection framework (like Spring) or just plain old property files. I'd also be interested to see if Scala offers anything on top of this, though.
EDIT: Typesafe config gives you a simple and powerful solution for configuration - https://github.com/typesafehub/config
ORIGINAL (possibly not very useful):
Quoting from "Programming in Scala":
"In Scala, you can configure via Scala code itself."
Scala's runtime linking allows for classes to be swapped at runtime and the general philosophy of these languages tends to favour convention over configuration. If you don't want to deal with gazillion property files, just don't have them.
Check out Configgy which looks like a neat little library. It includes nesting and change-notification. It also include a logging library.
Unfortunately, it didn't compile for me on the Mac instances I tried. Let us know if you have better luck and what you think...
Update: solved Mac compilation problems. See this post.