tag:blogger.com,1999:blog-741750605858169835.post1085920925656788460..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Exiting the JVMStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-741750605858169835.post-30983393813553260082015-11-30T22:12:24.626+00:002015-11-30T22:12:24.626+00:00Re your claim: "Final thought - if you're...Re your claim: "Final thought - if you're writing code to exit the JVM, have you considered whether you even need that code? After all, exiting the JVM doesn't play well in embedded or cloud environments..."<br /><br />... I don't know about embedded environments. In the cloud, I think `Runtime.halt()` is a great idea.<br /><br />In the cloud, your JVM might disappear entirely at any instant. You code as though any line of code might be the last one executed. In that context, `Runtime.halt()` is sensible: it leaves the broader system in a consistent state.Anonymoushttps://www.blogger.com/profile/02632905761151229381noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43016702459942387152014-11-10T01:12:43.692+00:002014-11-10T01:12:43.692+00:00how about remove shutdown hook before exit(-1) ? w...how about remove shutdown hook before exit(-1) ? would that work?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49392810346072094362014-04-09T03:36:31.929+01:002014-04-09T03:36:31.929+01:00Maybe I just do this out of habit/paranoia, but fo...Maybe I just do this out of habit/paranoia, but following <a href="https://www.securecoding.cert.org/confluence/display/java/LCK00-J.+Use+private+final+lock+objects+to+synchronize+classes+that+may+interact+with+untrusted+code" rel="nofollow">LCK00-J</a> guidelines would prevent the deadlock because the Runnable instance would have its own lock object... Nevertheless, chalk this up as another example of how giving people different ways to do the same thing is not always a good idea.Anonymoushttps://www.blogger.com/profile/08220880215329923555noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89133394228629392014-02-15T21:07:18.848+00:002014-02-15T21:07:18.848+00:00thx!thx!Daniel Dietrich's Bloghttps://www.blogger.com/profile/02492628698632995681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-34155664567645764252014-02-15T11:16:42.544+00:002014-02-15T11:16:42.544+00:00I suspect that the SecurityException would be one ...I suspect that the SecurityException would be one case where the finally block is reached.<br /><br />I'd agree that the JDK could do with a method for invoking Timer more easily.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-9785967740673408982014-02-15T04:00:15.203+00:002014-02-15T04:00:15.203+00:00Hi, nice one! Are there any chances to reach the f...Hi, nice one! Are there any chances to reach the finally block? I want to use this code and stripped it down to this:<br /><br /><b><br />public static void exit(int status, long timeout) {<br /> final Runtime runtime = Runtime.getRuntime();<br /> try {<br /> Timers.schedule(() -> runtime.halt(status), timeout);<br /> runtime.exit(status);<br /> } catch (Throwable x) {<br /> runtime.halt(status);<br /> }<br />}<br /></b><br /><br />For scheduling a TimerTask I wrote a convenience method (I'm missing such ones in the Jdk8):<br /><br /><b><br />public final class Timers {<br /><br /> private Timers() {<br /> throw new AssertionError(Timers.class.getName() + " cannot be instantiated.");<br /> }<br /><br /> public static Timer schedule(Runnable task, long delay) {<br /> final Timer timer = new Timer();<br /> timer.schedule(new TimerTask() {<br /> @Override<br /> public void run() {<br /> task.run();<br /> }<br /> }, delay);<br /> return timer;<br /> }<br /><br />}<br /></b>Daniel Dietrich's Bloghttps://www.blogger.com/profile/02492628698632995681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-88840290766049596942014-02-07T10:51:58.525+00:002014-02-07T10:51:58.525+00:00Don't forget that invoking exit/halt can throw...Don't forget that invoking exit/halt can throw an instance of SecurityException. Perhaps this is partly why invocations of exit/halt are not considered for the unreachable-statement analysis performed by the compiler, despite the fact that such invocations never complete normally. In any case, the deadlock behavior of the puzzler goes against the warnings in the documentation of Runtime.addShutdownHook(Thread).Anonymoushttps://www.blogger.com/profile/08894208930017919992noreply@blogger.com