Take Integrity by default into account for jPOS next

[alcarraz]

In JEP draft: integrity by default, it is being proposed to eventually remove setAccessible from the reflection API since it undermines encapsulation. The final decision is still to be made, the considerations are reasonable enough to me.

I have in mind this method, and I haven't looked if it is used somewhere else in jPOS code base yet.

jPOS/jpos/src/main/java/org/jpos/q2/QFactory.java

Line 458 in f1af198

field.setAccessible(true);

I propose that for jPOS next, we try to use setter to do this, and start giving warnings when setters are not available. In that case, we could have a property for disabling those warnings, but I feel they should be on by default.

[ar]

I like the idea and welcome the discussion. I'm aware of this JEP draft and I'm keeping an eye on it as it develops. I think we need to wait until it's final to see what the suggested alternatives to these unsafe operations are. Because our autowire method uses reflection, how would you suggest using a setter? Remember, we might not have setters for variables we define as @config, and they might not be public because we don't want them to be accessible from outside the class.

[alcarraz]

I think we will have to make them settable, if not, I'm afraid it eventually will not comply with integrity, and thus it will require an explicit argument to the VM to allow that. The whole purpose of the JEP is not to allow writing to places that are not exposed somehow.

There may eventually a way to do this differently, I can imagine something like saying which modules are allowed to perform that. What I propose is to try to find a setter through Bean introspection, and if the property has no setter and is not accessible, default to the current behavior with a warning. The warning could state that it may not work in the future, or it most likely will require an explicit JVM parameter that allows it.

Personally, I don't like frameworks changing the visibility of my classes, I prefer them to force me to write the setter if I want them to. Unless until we have a way to say that some class or module is friend, like in C++.

For now, we can just exchange ideas. We can omit the warning part, or delay the implementation at all until the JEP evolves to something more definitive, as you said. I may have just inadvertently used it as an excuse to implement it in a way I like it more :).