> This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related > methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance > fields in serializable type > > to get feedback on the general approach and test strategy before further > polishing the implementation. > > The implementation initially started as an annotation processor I wrote > several years ago. The refined version being incorporated into Attr has been > refactored, had its checks expanded, and been partially ported to idiomatic > javac coding style rather than using the javax.lang.model API from annotation > processing. > > Subsequent versions of this PR are expected to move the implementation closer > to idiomatic javac, in particular to use javac flags rather than > javax.lang.model.Modifier's. Additional resources keys will be defined for > the serialization-related fields and methods not having the expected > modifiers, types, etc. The resource keys for the existing checks related to > serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account > whether a class, interface, annotation, record, and enum is being analyzed. > Enum classes and record classes have special handling in serialization. This > implementation under review has been augmented with checks for interface > types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with > the augmented checks. For most modules, this PR contains the library changes > necessary for the build to pass. I will start separate PRs in those library > areas to get the needed SuppressWarning("serial") or other changes in place. > For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and > without these changes, but informally the build seems to take about as long > as before.
Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Restore serial checks on java.xml module. - Merge branch 'master' into JDK-8202056 - Appease jcheck - Implement checks chegar recommended for interfaces. - Update comment. - Add tests for instance field checks. - Clean build with instance field checks in place. - Merge branch 'master' into JDK-8202056 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/7925d0cc...bacff4e9 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/053de6bb..bacff4e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=01-02 Stats: 2951 lines in 77 files changed: 2399 ins; 397 del; 155 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709
