-
Enhancement
-
Resolution: Fixed
-
P5
-
25
-
jdk-25+9-73-gba28119642a
-
b18
-
generic
-
generic
This is a minor refactoring/cleanup issue.
The Log singleton gets reused in the class JavacTaskPool, via a subclass called ReusableLog. That class has a clear() method that resets some, but not all, of the fields in its superclass, Log.
It only clears some of the fields in part because new fields were added to Log after ReusableLog was created (nsuppressederrors and nsuppressedwarns), but ReusableLog was not updated to also clear those fields.
Instead, following the principle of proper encapsulation, the class Log itself should be responsible for clearing its own fields, and ReusableLog.clear() should invoke super.clear() as its first statement. This should help avoid easy "misses" in the clear() method after future changes.
The Log singleton gets reused in the class JavacTaskPool, via a subclass called ReusableLog. That class has a clear() method that resets some, but not all, of the fields in its superclass, Log.
It only clears some of the fields in part because new fields were added to Log after ReusableLog was created (nsuppressederrors and nsuppressedwarns), but ReusableLog was not updated to also clear those fields.
Instead, following the principle of proper encapsulation, the class Log itself should be responsible for clearing its own fields, and ReusableLog.clear() should invoke super.clear() as its first statement. This should help avoid easy "misses" in the clear() method after future changes.
- links to
-
Commit(master) openjdk/jdk/5b42c46b
-
Review(master) openjdk/jdk/24460