On Fri, 1 Sep 2023 08:29:41 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> I think you may have missed the comment in the JBS issue. Logging means >> running potentially arbitrary code, doing this at Runtime.halt time is >> problematic. I thought the conclusion from the work on Runtime.exit was not >> to log in Runtime.halt? > >> @AlanBateman Sorry for missing your comment on JBS. I can't find any >> discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not >> sure if it was intentional that no logging output was added to Runtime.halt. >> However, if Runtime.halt is overlooked without discussion, I think it should >> be added after considering the need. >> I think it's the same problem as Runtime.exit when it comes to executing >> arbitrary code. >> Are there any issues specific to Runtime.halt? > > The purpose of the halt method is to terminate immediately, it doesn't > initiate the shutdown sequence. My recollection of the System.exit logging is > that it was deliberate to not change the halt method. Changing halt to log > means it would not terminate immediately. Also I think there were concerns > with logging libraries that needed the shutdown hook to execute in order to > fush/close logs. @RogerRiggs or @stuart-marks may be able to say more about > this. > @AlanBateman @RogerRiggs Could you comment on the above? Changing Runtime.halt to log means it would not terminate immediately. It's worse: Logging is pluggable so it means logging can potentially run "faraway" and arbitrary code. We have to super cautious with logging in core classes. The conclusion from the work on Runtime.exit was to not add this logging to Runtime.halt. So I don't think the changes in the PR should be integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1786553171
