On Fri, 27 Jan 2023 04:16:05 GMT, Ioi Lam <ik...@openjdk.org> wrote: >>>I'd expect that at least java.util.Date and java.lang.ProcessBuilder have >>>the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so >> would both have verification disabled by default. Bt as you note the >> behaviour can change when CDS is involved and only one class gets dumped. >> >>> But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder >>> doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment >> on why we treat things differently during dumping. > >> > I'd expect that at least java.util.Date and java.lang.ProcessBuilder have >> > the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so >> would both have verification disabled by default. Bt as you note the >> behaviour can change when CDS is involved and only one class gets dumped. >> >> > But in Date has StackMapTable (starting from JDK12-b15), and >> > ProcessBuilder doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on >> why we treat things differently during dumping. > > We always enable verification for all classes during -Xshare:dump. That avoid > problems where the classes were dumped without verification but at run time > you enable verification.
I'm not sure of all the implications of always having the stackmap. IIU what @iklam was saying then anyone running with cds enabled will not encounter the reported problem as the stackmap will be present. So these days only when you run without CDS can you encounter the issue. Is that right? ------------- PR: https://git.openjdk.org/jdk/pull/12155
