<div dir="ltr"><div dir="ltr">On Mon, Jan 26, 2026 at 5:07 PM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:</div><div dir="ltr"><br></div><div>Alan,</div><div><br></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't think we should go back to that.</blockquote><div><br></div><div>I was not suggesting we ditch the file key information from Key, that was more to demonstrate the change in class loading. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Actually, anything non-trivial causes these classes to be loaded.<br></blockquote><div><br></div><div>Granted, although many useful programs are indeed trivial!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't think that would make sense to expose on the legacy File class.</blockquote><div><br></div><div>Okay. I'd be happy with a private API point that wasn't so eager to load these classes at startup.</div><div><br></div><div>For reference, "java -cp hello.jar Hello" runs in ~62 ms on the mainline. On a branch using a non-NIO "file key" API, it runs in ~58. So startup impact is significant.</div><div><br></div><div>But the appetite seems meager, so I don't plan to kick this ball any further.</div><div><br></div><div>Cheers,</div><div>Eirik.</div><div> </div><div><br></div><div>   </div></div></div>