NativeLibrary.getOptions allows options to be mutated

[sebbASF]

The getOptions() method returns a pointer to the options Map:

jna/src/com/sun/jna/NativeLibrary.java

Lines 624 to 626 in 3656295

	public Map<String, ?> getOptions() {
	return options;
	}

This means the options can be mutated externally, which may cause unpredictable behaviour.
It also means that the class is not thread-safe, as changes to the options in one thread may not be seen by another.

One solution is to provide a copy of the options (note: this needs to be a deep copy)

[dbwiddis]

I made that suggestion here

Now that we're on JDK8 we can use Map.copyOf(). It makes a new copy (so changes can be made to the old map without impacting it).

It is a shallow copy, but I'd propose that's enough here. Looking at the various values in the maps one would have to work pretty hard to change their objects to something else, and there are far worse things they can abuse in this codebase.

[matthiasblaesing]

IMHO we should not do that because we gain little and in this case break API behavior.

Changing options after a function was created from the library will not magically kill your JVM, but creating a raw pointer and writing to it or unloading a native library and invoking functions created from it will kill it most probably with a segfault (if you are lucky).

JNA is a sharp weapon and if authors misuse it, it can break stuff.

[sebbASF]

What API behaviour would be broken?