On Mon, 18 May 2026 22:40:48 GMT, Joe Darcy <[email protected]> wrote:
>> src/jdk.compiler/share/data/symbols/jdk.graal.compiler-M.sym.txt line 1: >> >>> (failed to retrieve contents of file, check the PR for context) >> I don't know if we want to remove this file or do the jdk.jsobject-style >> removal in the symbols - it might be okay for us to nuke these internal >> modules this way. > > Hmm. > > I think removing the files for JDK releases from "M" (i.e. 22) through "R" > (i.e. 27) i needs some more consideration, Removing the files in the current > release is much less problematic. Sorry, I somehow missed this. Normally, I would say the historical data (i.e. `src/jdk.compiler/share/data/symbols`) should not be touched when removing something. But, in this case, these files seem more like an accident than real history. They are not used (not used in `symbols`), and so are not part of `ct.sym`, and so do not affect `--release`. It is possible the script malfunctioned when producing the historical record for JDK 22, as there are a few more files like this for JDK 22 (`jdk.internal.ed-M.sym.txt`, `jdk.internal.jvmstat-M.sym.txt`, `jdk.internal.le-M.sym.txt`, `jdk.internal.opt-M.sym.txt`). So, I am fine with removing JVMCI-related files. Separately, we might look at cleaning up the other stray JDK 22 files and/or investigating what happened. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30834#discussion_r3287057741
