1. right. These maps are all functions of Metafix and Metamorph and are not used standalone, I think.
2. I don't understand what you want to say. SqlMap and JndiSqlMap already do implement Closeable, so why not just make the need to implement mandatory when extending AbstractReadOnlyMap? You could always just "//do nothing" for close() (but are forced to make this decision deliberately)
3. As I understand it AutoCloseable could break a contract of users that rely on close() to only throw an IOException and not all (checked) Exceptions (which could be thrown when using AutoCloseable). So while this could be nice for some this should be considered an API break IMO.

1. These maps are all functions of Metafix and Metamorph and are not used standalone, I think.

Well, but they can be (and are) used standalone. I don't think we should dismiss this option offhand.

2. so why not just make the need to implement mandatory when extending AbstractReadOnlyMap?

Because not all maps have to be closable. It's not a property of AbstractReadOnlyMap, IMO.

3. As I understand it AutoCloseable could break a contract of users that rely on close() to only throw an IOException and not all (checked) Exceptions (which could be thrown when using AutoCloseable).

I have to admit, I don't understand this part. Where would the API break be if the maps don't even implement close() yet?

But please note that these were only suggestions. If you're not persuaded, feel free to ignore. Just one thing, though: Maps that only implement close() in order to satisfy the interface should maybe include a comment like "Nothing to do" (cf. JndiSqlMap); just to be clear that there's actually nothing to close.