Possible compiler bug: continue is skipped after or-condition

[Maurizio Cimadamore]

They are _generally_ very reliable - to be clear, nothing has changed in 
this area to make less reliable. You "just" came across a quirk in javac 
code generation strategy that has been there for the last 20 years.

There are other situations where putting a breakpoint won't necessarily 
result in anything meaningful to occur - for instance, if you put a 
breakpoint on a local variable declaration. This is not to say that 
nothing should be done about it _ever_ - but as you said, you lived for 
20 years w/o realizing that this hiccup has been there all along (along 
with other hiccups) - so please also understand a certain reticence in 
making an abrupt change in the code generation strategy (or worse, 
supporting multiple code generation strategies) for what feels like 
something that is annoying, yes, but hardly a breaking issue.

As I said in my last email, I'd like to address this as part as a more 
holistic investigation on how bytecode fidelity is retained from class 
files. Note that we have features in the pipeline like constant folding 
(see [1]) which are going to cause an even bigger impact to how source 
files relates to classfiles. So I'd just like to think this through 
properly, as I think this needs more thinking and more time than what 
we've available right now - to fully assess the extent of this and other 
'premature' optimizations javac might do to the code, verify that 
changing code shape won't hurt C1, C2 compilers, and make sure that no 
relevant functional regression is introduced.

Maurizio

On 17/02/2020 17:35, Roland Illig wrote:
> How would you explain to an average developer that breakpoints are not
> reliable? Up to now, they have been very reliable to me, and after more
> than 20 years of using Java, this is really the first time that the
> breakpoints surprise me.