> @@ -267,7 +267,7 @@ public Resource getServer() {
> return this.server;
> }
>
> - public Map<String, String> getMetadata() {
> + public Map<String, Object> getMetadata() {
So this is the killer part of this problem. This change is backwards
incompatible. If someone has
Map<String, String> metadata = image.getMetadata();
in their code (and I know image metadata is used a lot) will be broken by this.
For reference, I brought this up in the thread [Dealing with different JSON
value types in a
Map](http://www.mail-archive.com/dev%40jclouds.apache.org/msg05255.html) and
the suggestions there were to change the method signature as well. That's
something I'm not in favour of because of all of the code it would break.
Also, when you do `Map<String, Object>` you force the client to deal with
`Object` every single time. Even when `Map<String, String>` is the more common
case.
However, the solution space seems to be limited. One alternative is to *add*
another field to `Image`
Map<String, Object> metadataWithBlockDeviceInfo;
...
Map<String, Object> getMetadataWithBlockDeviceInfo();
And deserialize to that if the metadata contains `block_device_mapping`. Then
one of `metadata` or `metadataWithBlockDeviceInfo` will always be null. The
client will have to either know or test to see which one it is.
Thoughts on that?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/626/files#r21716908
