ProGuard Java Optimizer and Obfuscator

Ok, we'll solve it like this. I've removed the MONITOR_EXIT line for the
upcoming ProGuard 4.5 beta3.

I can confirm that just removing that line also produces code that actually
runs.

I assume you mean MONITOREXIT, but yes, I believe that would work. That was
actually the solution proposed by one of my colleagues, but I thought it
better (in light of the aforementioned discussions) to make the minimum
changes required to the class files in order to get them to run correctly.
I'm happy to test any patches.

Another potential source of exceptions in MONITOREXIT is asynchronous
exceptions, i.e., ThreadDeath or an internal JVM error. The former, at
least, has long been deprecated because it could never hope to work
correctly. But the current optimizations will already remove exception
handlers in ways that could affect these.

We also discussed the possibility of duplicating the handler, so that each
one could throw exceptions into the other, thus possibly avoiding the JIT
bug. I haven't confirmed that this would really work around the problem,
but it might be palatable to compiler writers. However, this is no longer
an optimization (it would add 3-5 instructions and another exception table
entry for each synchronized block).

Thanks for the detailed analysis and for the clean code. I would prefer to
handle this as a general optimization, since ProGuard's retargeting does
not attempt to fix any incompatibilities between versions (e.g.
StringBuffer vs StringBuilder). For programs (or at least Java programs)
that are compiled correctly, I would assume that monitorexit cannot throw
exceptions. It's a bit worrying that this goes against the conclusions in
the discussions to which you refer, and against the way Java programs are
currently compiled.

Removing line 94 (opcode == InstructionConstants.OP_MONITORENTER) in
proguard/optimize/info/ExceptionInstructionChecker.java then seems to be
sufficient. Would that work for you?