> As part of: > https://github.com/openjdk/jdk/pull/16505 > > there are new symbol files for JDK 22, and @jddarcy noted the content looks > weird. > > I was investigating, and found a few problems, some introduced by > https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, > some pre-existing. > > Note that > https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b > changed the way we generate `ct.sym` - it now contains `.sig` files also for > the current JDK, not only for the past versions. Before this patch, `ct.sym` > only contained a list of permitted modules for the current JDK, and the > classfiles themselves were read from `lib/modules`. > > The problems (and their solution) I've attempted to tackle here: > - since > https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, > the ct.sym accidentally includes all modules for the current release, > including non-API/undocumented modules. The proposed solution is to pass the > documented modules together with their transitive dependencies as a parameter > when constructing ct.sym, then use them to only generate data for these > modules. > - there are tiny differences between the data that are in `ct.sym` and in > the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` > files contain references to internal annotations (like `@PreviewFeature`), > which are stripped or converted before the `.sig` file is written into > `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` > on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is > done using `--release N`, so that we read the correct span of modules. Sadly, > since now `--release N` will always use the `.sig` files, we are loosing a > little bit of information esp. around the annotations. The proposal here is > to use `--release N` to read the list of modules to cover, and `--source N` > to read the actual real classfiles from `lib/modules`. This should basically > revert the behavior to the previous state. > - this is an existing issue, but one that needs to be fixed. Sealed types > are not written and read properly - writing was not storing them, and reading > permitted subclasses was happening too late, not on the `header` line. Note > that when fixing this, we now must store some of the non-exported elements, > which are reachable through the permitted subclasses, so that casting works > as expected. Also, since the historical record is incorrect here, I re-run > the generator for JDK 17-21 (as sealed c...
Jan Lahoda 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 ten additional commits since the last revision: - Removing unneeded exports. - Merge branch 'master' into JDK-8321224 - Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES. - Removing trailing whitespace. - Ensuring qualified packages are recorded properly. - Fixing tests. - Adding a way to dump the API. - Adding missing file. - 8321224: ct.sym for JDK 22 contains references to internal modules ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16942/files - new: https://git.openjdk.org/jdk/pull/16942/files/87927789..ce981117 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16942&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16942&range=01-02 Stats: 56068 lines in 1520 files changed: 31819 ins; 18328 del; 5921 mod Patch: https://git.openjdk.org/jdk/pull/16942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942 PR: https://git.openjdk.org/jdk/pull/16942
