There's actually something very odd going on. Here's a simple script showing how not only is JRuby not doing the right thing, but it's not even consistently doing the wrong thing...

::X = true
X ||= raise('a') # => ok
::X ||= raise('a') rescue puts "Should not raise but does!" # => not ok
::X ||= raise('a') rescue puts "Should not raise but still does!" # => not ok, but consistent
::X ||= true  # This, incredibly, changes something, because now...
::X ||= raise('a') # => D=this doesn't raise! Completely inconsistent behavior

FWIW, &&= doesn't exhibit the same inconsistent behavior, i.e. it seems to behave consistently badly...

::Y = false
Y &&= raise('a') # => ok
::Y &&= raise('a') rescue puts "Should not raise but does!" # => not ok

I think the root of the problem is not the control flow itself. It seems that when setting a constant in the "root" (starting with :: without nesting) using either &&= or ||=, the constant lookup gets screwed up:

• Using ||= sets the constant somewhere else (no idea where)
• Using &&= never finds an existing constant (and does an odd exception).

Note that all of the problems go away when not using ::

Clearly not set where it should be...

::OR_EQUAL2 ||= true
puts ::OR_EQUAL2  #=>Exception "uninitialized constant OR_EQUAL2"

Both uses of ::OR_EQUAL2 refer to the same (wrong) place, since the 1 is kept between both uses:

::OR_EQUAL2 = 0
puts (::OR_EQUAL2 ||= 1)   #=> 1
puts (::OR_EQUAL2 ||= 2)   #=> 1
puts ::OR_EQUAL2   #=> 0

The same problem happens when using &&=. But the different flow generates a weird exception early. (In MRI, there is no exception). The output of this example should be 1.

::AND_EQUAL2 = 0
puts (::AND_EQUAL2 &&= 1)   #=> Exception "uninitialized constant ::"

Note also how weird the exception message is. The refered constant is just ::.

All of the above was tested on:

• jruby-head (jruby 9.2.0.0-SNAPSHOT (2.4.1) 2017-10-04 46782c4 OpenJDK 64-Bit Server VM 25.131-b11 on 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11 +jit [linux-x86_64])
• jruby-9.1.13.0

OS:
ubuntu 16.04
Linux max-u1604 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:59:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Ouch. There are probably two bugs here then. In particular, @MaxLap's issue doesn't show in the Foo::Bar case.

The fact that the constant isn't set is more important. I added a spec for it.

Ah, didn't see that other case. Here is some fun investigation into it.

The following should puts 'h1' and then fail. Instead, we get "h1" then "h3" then "h1" then fail.

(puts 'hi1'; raise 'thing'; puts 'h2';String)::Foo ||= puts 'hi3'

Looks like the "getting a constant" of ||= to check if the assignation is needed swallows the exception and assumes that it doesn't exist. Then, after evaluating the value, does the lookup again, without swallowing this time.

Note that even if the constant exists, the lookup is done twice:

(puts 'hi'; String)::Foo ||= 1 #=> Prints 'hi' twice
puts 'separator'
(puts 'hi'; String)::Foo ||= 1 #=> Prints 'hi' twice again

I have been working on this one and it will be fixed but it opened up a wormhole and I discovered another class of bugs where lhs of colon2 (foo::B) will execute twice! Fixing this is more involved but pretty imperative that it is fixed first (all cases will be fixed though).

The originally reported issue was due to two issues in how we emitted instructions for this clause:

1. we emit instrs to emulate what we can think of as defined? logic for figuring out if Foo exists. This logic has a catchall which swallows the first execution of raise 'a'.
2. when we get to the ||= part of this I accidentally emitted the value (raise 'b') before our second calling of raise 'a'.

So just correct the second of those items would fix originally reported issue (and possibly the other ones) but it would be calling raise 'a' twice. If this was a user method which threw an exception but also made a db transaction you would be wondering why there were two updates instead of just one :|

After having fixed design of ||= for constants all of that is working and it is not executing the same method twice.

I ran into the second bug which was that ::A ||= was recording '::' as the name of the constant and not 'A'. Amazingly it only happens for this single case of ::{constant} {op}=.

I still have to figure out &&= though. Getting much closer.