I have previously admitted my incomplete knowledge of the subtleties of static and final keywords in Java so this is a probable but unconfirmed hypothesis and a cautionary tale for folks who manipulate Java.
I often run IntelliJ's inspect function on code I am going to commit anyway in the belief that "inspected" code is more robust or easier to maintain. Often IntelliJ will suggest a static field could be declared final and I accept the suggestion.
I was writing tests for EquipmentDatabase. Everything worked. I made changes I wanted to EquipmentDatabase and declared some fields static final as suggested. Tests failed, but not mine. The failure indicated a problem with static initialization (and was in a test that used EquipmentDatabase).
EquipmentDatabase has a static block that calls a function that reads a file and populates fields.
I believe the static analysis saw that the function was the only thing that set some fields and thus made the suggestion. But there are circumstances where the function is called elsewhere or the EquipmentDatabase object is recreated and making the fields final prevents reinitialization.
I will address this in the short term by not believing static field can be declared final without further investigation but I mention it as a warning in case other folks also like to remove lint.
Long term, there are probably some implementation details that should be reviewed. I can often argue in favor of reducing the number of static declarations. We have probably violated some kind of recommendation by initializing what I changed to static final fields in a publicly accessible method. We may want better separation of fields that we know are really final and ones that can be reset by an extraordinary event, such as changing character or breaking the prism.
At the moment this is a cautionary tale that may be seriously revised as I actually make and undo changes to get things to work.
I often run IntelliJ's inspect function on code I am going to commit anyway in the belief that "inspected" code is more robust or easier to maintain. Often IntelliJ will suggest a static field could be declared final and I accept the suggestion.
I was writing tests for EquipmentDatabase. Everything worked. I made changes I wanted to EquipmentDatabase and declared some fields static final as suggested. Tests failed, but not mine. The failure indicated a problem with static initialization (and was in a test that used EquipmentDatabase).
EquipmentDatabase has a static block that calls a function that reads a file and populates fields.
I believe the static analysis saw that the function was the only thing that set some fields and thus made the suggestion. But there are circumstances where the function is called elsewhere or the EquipmentDatabase object is recreated and making the fields final prevents reinitialization.
I will address this in the short term by not believing static field can be declared final without further investigation but I mention it as a warning in case other folks also like to remove lint.
Long term, there are probably some implementation details that should be reviewed. I can often argue in favor of reducing the number of static declarations. We have probably violated some kind of recommendation by initializing what I changed to static final fields in a publicly accessible method. We may want better separation of fields that we know are really final and ones that can be reset by an extraordinary event, such as changing character or breaking the prism.
At the moment this is a cautionary tale that may be seriously revised as I actually make and undo changes to get things to work.