More immutable classes. #1727
More immutable classes. #1727
Conversation
…into ei-reflection
… count. Module and ModuleLayer are for practical purposes, immutable.
…s a ClassLoader. Functions can be considered safe. Annotations are immutable.
| @@ -86,7 +99,7 @@ public static boolean mutableSignature(String sig) { | |||
| private static final class ClassAnalysis { | |||
| private static final List<String> SETTER_LIKE_PREFIXES = Arrays.asList( | |||
| "set", "put", "add", "insert", "delete", "remove", "erase", "clear", "push", "pop", | |||
| "enqueue", "dequeue", "write", "append", "replace"); | |||
| "enqueue", "dequeue", "write", "append", "replace", "prepend", "reset", "update"); | |||
There was a problem hiding this comment.
I'm personally not so positive to edit these prefixes. Name methods and mutability should have no relation.
Then it is better to keep the current implementation as is, to keep backward compatibility and bring no surprise to users.
There was a problem hiding this comment.
@KengoTODA This could be argued to every other previously existing member on this list. I am just building on what is already there.
In fact, I also really dislike the idea of looking the method name for common verbs in English to guess its behavior because it is very prone to go wrong in many ways. If it was for me, I would never make it behave that way to start with. However, considering that it is already there and is already coded that way, I am just adding a few more common prefixes for mutating methods.
I added some classes to the known immutable set.
java.math.Decimaldoes not exists (should beBigDecimal). And the packagejava.mathalready covers it, so I just removed it along withBigInteger.setAccessible(boolean), there is already other checks covering that corner-case, so for every other case, they are immutable. Also, the side-effect of using that method is likely the intended one, and not the accidental side-effect that immutability seeks to prevent.I am not sure if thejava.lang.Moduleandjava.lang.ModuleLayershould be considered immutable, but I left them out.java.lang.Threadis effectively immutable. Stopping or suspending a thread is deprecated and was even removed from the newest JDKs. OnlyThread.interrupt()remains to interfere with a Thread, which is already covered by other checks and is a very unlikely to be a way to attack mutability.Edit:
Optional<T>is immutable if, and only if,Tis immutable. But at this moment, it is too naive to know that.java.lang.Moduleandjava.lang.ModuleLayeraren't 100% immutable, it is extremely unlikely that mutating them causes undesirable side-effects (most likely, only the intended ones). So, I added them to the list.Edit 2:
java.util.functionand annotations are immutable. However, sadly, forThread, there are some stuff there that are too mutable to be safe.Classis fair to be considered immutable, so is theClassLoader.