Community
Participate
Working Groups
In "[eclipse-dev] enable assert during tests?" Stephan Herrmann writes "That said, in my case I was actually happy that one test run did NOT have "-ea" because it detected one of the stupidest mistakes I had made: putting a state-changing operation into "assert"." Suggestion: if the body of an assert is state-changing provide a compiler error by default. If the body is too complex to analyze provide a compiler warning by default.
I was (obviously :) ) thinking about this. Unfortunately *every method call* is (practically) too complex to analyse. This would change if Java had a standard @Pure annotations for pure functions ...
A very quick scan of my own code suggests that over 75% of asserts are of the form assert x; assert !x; assert x == null; assert x != null; Surely all analyzeable? If anything more complicated was a warning,it could be that it provokes only grumbles rather than complaints. The check seems worthwhile, just need to decide whether the not-analyzeable default is warning or ignore.
schedule for assessment re comment 2 during 4.17 - no promise yet.
