Aws-sdk-java: Cannot find symbol com.amazonaws.util.json.JSONObject on version 1.11.0

[alabeduarte]

Hi everyone,

I'm having a compilation error with missing com.amazonaws.util.json.JSONObject object when using aws-java-sdk-s3.

I was surprised this morning with this failure and this may be an issue with version 1.11.0. That said, I had to downgrade to version 1.10.77 in order to have my code running again.

The error is following:

error: cannot find symbol import com.amazonaws.util.json.JSONObject;

Thanks

[breedloj]

Hey Alabê,

This is actually expected as we've dropped our usage of the Json.org parsing library in favor of Jackson for 1.11 (mentioned in the release notes here: https://aws.amazon.com/releasenotes/9979983567247718). You'll need to update any code that was explicitly using this library when you upgrade to 1.11.

Feel free to re-open if you have any further questions or concerns about the migration.

[alabeduarte]

Thank you @breedloj

[mslinn]

Hey! Was JSONObject deprecated before dropping it? We have a bunch of code that uses com.amazonaws.util.json.JSONObject. For example, this Scala code:

def jsonPrettyPrint(awsObject: Object) = Json.prettyPrint(Json.parse(new JSONObject(awsObject).toString))

You should provide warning before dropping, and migration instructions, not just 'deal with it'!

[akshayvadher]

Any alternate JSONObject you guys suggest?

[shorea]

We personally use Jackson, if you do end up using Jackson make sure to declare an explicit dependency on it as relying on transitive dependencies of third party libraries is considered bad practice.

If you prefer to remain using JSONObject you can import the following into your project.
https://github.com/stleary/JSON-java

[mslinn]

I used the Jackson dependency provided by AWS for Java. Here is what I wrote (in Scala):

import com.amazonaws.util.json.Jackson
def jsonPrettyPrint(awsObject: Object) = Jackson.toJsonPrettyString(awsObject)

Again, docs would be helpful, including advance warning of deprecation and a migration guide.

[mslinn]

@shorea I disagree about what might constitute best practices. If you introduce an explicit dependency that matches an existing transitive dependency, and then the transitive dependency is updated, both versions will be referenced, which is a problem. Instead, 'riding along' with the transitive dependency requires that your code tracks the dependency evolution however there won't be version mismatches.

[shorea]

If we decide to move off Jackson and remove our dependency on it then that would break customers consuming it transitively.

[mslinn]

We already know this to be true, don't we? No matter, consumers would then have the option of explicitly adding the dependency. This is the best practice because it avoids dueling versions of a given dependency.

[shorea]

I personally believe once a dependency crosses product boundaries and is not exposed in public interfaces then you should not rely on it transitively. For example if you declare a dependency on aws-java-sdk-s3 then it's 100% okay to rely on aws-java-sdk-core to be pulled in transitively as it's within the same project branding and you use classes in core to make the s3 code functional. Jackson however is not a project we control and we do not expose it in our public interfaces so it's more of an implementation detail that we may remove at any time. I wouldn't think of it as duplicating dependencies as your free to use later versions of Jackson that are compatible with the version we depend on so the versions are not necessarily the same. For example we are using Jackson 2.6 which is not the latest and greatest that you may want to use in your project.

[mslinn]

@shorea I understand. We have different beliefs as to what might constitute best practices. No problem.

[sylnsr]

"relying on transitive dependencies of third party libraries is considered bad practice" -- isn't dropping something without deprecating it gracefully considered bad practice?

Kettle ... meet pot.