There is the class JsonParserFactory which tries to find a Json parser on the classpath.
I think the first parser that is looked up should be JSON-P (JSR-374) since that is the standard for a few years now.
Furthermore, using SnakeYaml as a JSON parser may not be such a good idea, because exception stacktraces will be very confusing for the user -- they are working with JSON and seeing exceptions about YAML.
Comment From: wilkinsona
Thanks for the suggestion. While JSON-P may be a standard in name, it is not a standard in terms of adoption. From what we have seen, Jackson remains the dominant de-facto standard for JSON parsing on the JVM with Gson being the most commonly seen alternative.
Comment From: amihaiemil
@wilkinsona I understand your point. However, I would still endorse JSON-P.
The Java world was designed and is supposed to work primarily on standard interfaces. Sadly, the market shows us that most developers did not understand that. Most developers are using Jackson not because it is the best, but because they have no idea about JSR 374 and can't appreciate Java Interfaces.
That said, I'd still try to look for JSON-P first. Then Jackson second and Gson third. Perhaps it would also be elegant to display warnings if the user has more than one of them on the classpath, as it is clearly a mistake in their architecture/dependency tree.