This isn't new to 8u40; I just tested, and it's broken in 8u31 and 8u25 too. If I had to guess, it has been like this since the initial release. I base my guess on the fact that the way Nashorn compiled finally blocks in presence of control flow transfers (break/continue/return) was unfortunately broken, I myself discovered this last December and fixed it early February – that's indeed the JIRA issue that Anthony pointed out. Unfortunately, it didn't make it in time for 8u40 :-(
If you're self-deploying, I'd suggest you get an 8u60 EA from <https://jdk8.java.net/download.html> and drop its nashorn.jar into your 8u40 JRE (it'll work). A glance at Mercurial log shows this issue with finally block inlining was picked up for 8u60-b03 build; the currently latest build is 8u60-b05, so it should be in there already. Apologies for the inconvenience. I've been doing a lot of stabilization work lately. I could get ready with some of the issues for 8u40, but there's a bunch of others that I couldn't finish in time… Attila. On Mar 8, 2015, at 3:22 PM, Anthony Vanelverdinghe <anthony.vanelverdin...@gmail.com> wrote: > Hi Tal > > This might already have been solved in 9, and backported to 8u60, with bug > JDK-8067139 [1]: Finally blocks inlined incorrectly > > Kind regards, > Anthony > > [1] https://bugs.openjdk.java.net/browse/JDK-8067139 > > > On 8/03/2015 14:55, Tal Liron wrote: >> This was very hard to discover, but it is real and easy to reproduce. Try >> running this program: >> >> var finalies = 1 >> var line = 'TEST THIS LINE' >> try { >> while ('' !== (line = line.substring(0, line.length - 1))) { >> if (line.length % 2 == 0) { >> continue >> } >> java.lang.System.out.println(line) >> } >> } >> catch (x) { >> java.lang.System.out.println(x) >> } >> finally { >> java.lang.System.out.println('Finalies ' + (finalies++)) >> } >> >> If you run this code, you'll see that the "finally" block is run every time >> "continue" is reached, and then the while loop continues after the "finally" >> block is run. Of course, the "finally" block should only be called once in >> this example, and the while loop should not continue, and this broken >> behavior can lead to serious problems. >> >> (I added the "catch" block only to make sure that exceptions are not thrown, >> and indeed they are not. Sorry about the silly functionality of the program, >> but it's the result of trying to wrap my head around what was going on...) >> >> Or maybe I'm crazy and am missing something trivial? The same code runs in >> Rhino without this problem. >> >> The bug appears in the 8u40 release. :( >> >> -Tal >> >> >
