...
| FasterXML Jackson version | Google gson version | Comments |
|---|
| Code Block |
|---|
mapper = new ObjectMapper(); |
| | Code Block |
|---|
JsonParser parser = new JsonParser(); |
|
|
| Code Block |
|---|
JsonNode rootNode = mapper.readTree(new File(authFilename));
JsonNode rolesNode = rootNode.path(AuthConstants.ROLES_NODE_PATH); |
| | Code Block |
|---|
JsonObject authObject = parser.parse(authFile).getAsJsonObject();
JsonArray roles = authObject.getAsJsonArray("roles"); |
| Jackson's JsonNode is a more abstract data structure, compared with Gson's more concrete data structures JsonObject and JsonArray. |
| Code Block |
|---|
String function = functionNode.path(AuthConstants.FUNCTION_NAME_PATH).asText(); |
| | Code Block |
|---|
String roleName = roleObject.get("name").getAsString(); |
| Code structure differs at this point (function name vs role name) but the general intent of the code is equivalent (get the element name as a string). |
| Code Block |
|---|
public synchronized void loadUsers(String authFilename) throws Exception
(no exception handling in this method) |
| | Code Block |
|---|
} catch (JsonProcessingException e) {
ErrorLogHelper.logError("AAI_4001", globalAuthFileName + ". Not valid JSON: " + e); |
| For some reason, this version still catches com.fasterxml.jackson.core.JsonProcessingException even though it uses Google gson for parsing. Not a good idea to defer exception handling to the caller since the caller has no idea why/how/when/where the parsing failed and might be left with an invalid data structure as well. |
| Code Block |
|---|
boolean hasMethods = handleMethodNode(methodsNode, role, function); |
| | Code Block |
|---|
usrs.forEach((key, value) -> {
...
}); |
| Method call vs Java lambda call is not really relevant to the Jackson replacement, but consistency of style could be an overall goal if the code is being re-factored anyway. |
...
At this point, if the application is only using Jackson for automatically serializing and deserializing request and response objects in its REST APIs, the conversion should be complete. Your Spring Boot application should now be switched to using the Gson implementation, and function as before.
Notes:
- I did not need to add the "preferred-json-mapper" property to my application.properties as stated in the link above. Spring Boot 2.0.3 seems to be capable of detecting and using the Gson dependencies on its classpath automatically.
- Additional complications and code changes may arise if you are explicitly using any of the Jackson library classes in your code. These will need to be manually converted to use the equivalent Gson classes instead.
- Jackson dependencies may be pulled in transitively from other AAI modules (such as aai-common). Excluding these manually in your own pom may be risky, so ideally they need to be fixed at the source.