Replace Map usage with OOP design classes

[djmj]

I am currently testing your service and evaluating to be your customer. But i am dissapointedd from the Java integration you provide.

Everywhere you pass generic Map instances holding String key value pairs for configuration, upload options / results. That is not suitable for an object oriented programming language, and looks like 15 years ago programming style (including underscores).

Also enumeration classes could be used for fixed parameters like transformations and meaningfull exceptions shall be thrown. To detect a resource not found exception one must check the generic message like if (e.getMessage().contains("Resource not found")).

That key-value and error message approach is very error prone and really not developer friendly.

Example:

String publicId = (String) uploadResult.get("public_id");

Could be:

String publicId = uploadResult.getPublicId();

[roeeba]

Hi @djmj, thank you very much for the feedback. It's in our roadmap to make the Java library more structured. We'll update here on any progress made in this direction.

[MateuszPluciennik]

This issue is a bit old, but.. can someone tell what is current status? :)

[aleksandar-cloudinary]

Hi @MateuszPluciennik

We're in the process of rewriting all of our SDK code into a second iteration with shared code standards, consolidation of dependencies, with focus on easier extensibility through object orientation and more. The change outlined in this thread would be part of the SDK 2.0 project automatically.

For example, one of the first SDKs under this new SDK 2.0 project is our the PHP one which you can find here - https://cloudinary.com/documentation/php2_integration