Using Mirah 0.2.1 - Breaks Oracle Java 8.

[jscott...@gmail.com]

Hi guys,

I have run across a relatively trivial design pattern that seems to break the Java run time while compiling code.

First, I start off with a trivial interface definition.  This will of course be in it's own class file with proper boiler plate.  The meat of it looks like this:  It's basically a way of peering classes for callbacks.

#####
#
# Interface for beacon list update dispatch.
#
interface BeaconListUpdateDispatcher
  def beacon_list_update_dispatcher:void ; end
  def register_beacon_list_update_receiver (blud:BeaconListUpdateDispatcher):void ; end
  def unregister_beacon_list_update_receiver (blud:BeaconListUpdateDispatcher):void ; end
end

So I go and create a class that uses this and provide an implementation:

#
# Main activity served up by the launcher.
#
class MainActivity < ActionBarActivity

    implements BeaconListUpdateDispatcher

    #protected
    def onCreate (state:Bundle):void

        ....

    end


    #
    # From: interface BeaconListUpdateDispatcher
    #
    # This receives the data update notification and dispatches
    # it to all objects that have registered to receive such
    # notifications.
    #

    #public
    def beacon_list_update_dispatcher:void
        AppDebug.d "MainActivity.beacon_list_update_dispatcher()"

        return unless @blud

        @blud.each do |blud:BeaconListUpdateDispatcher|
            blud.beacon_list_update_dispatcher
        end

        self.set_view_switcher
    end

    #public
    def register_beacon_list_update_receiver (blud:BeaconListUpdateDispatcher):void
        AppDebug.d "MainActivity.register_beacon_list_update_receiver()"
        @blud = []      unless @blud
        @blud.add Object(blud)  unless @blud.contains blud
    end

    #public
    def unregister_beacon_list_update_receiver (blud:BeaconListUpdateDispatcher):void
        AppDebug.d "MainActivity.unregister_beacon_list_update_receiver()"
        @blud.remove blud  if (@blud and @blud.contains blud)
    end

end # Class.


The assumption here is that we may get peered with more than one "dispatchee", or none at all.  So we use a list for this, and walk the list when we have to fire something out.

What I want you guys to take notice of is the seemingly unnecessary object cast, second function from the bottom.

@blud.add Object(blud)  unless @blud.contains blud


If I don't wrap the code with the Object() cast, then the compile fails.  If I build using Java 8 on x86_64, and don't have the cast, then I get a call stack overflow error, and the dump shows that "TypeFuture" is stuck in infinite recursion or something.  If I put the cast in, then all is fine.  This happens with all recent releases of Java 8, so it doesn't seem to be specific to a Java 8 release.  It happens with both the Windows and Linux releases of Java.

Also interesting is that this does not happen at all on ARM!  I have tried Oracle Java 8 for ARM32 and AARCH64.  Cast or no cast, it builds fine.  It's just Intel java that cannot build the code.

For reference, my tools stack looks like:

jdk1.8.0_151 (On Linux x86_64)
jruby-1.7.27
apache-ant-1.10.1
Mirah 0.2.1
Pindah 0.1.3


Unfortunately, it may take more than just a few simple lines of code to trigger this, but happens regularly on any large project.  The worst part is, there are no diagnostic messages of any kind to indicate where the code parsing is stuck.  It took a manual binary search, removing files to narrow it to the file, and then another bisection to get to the exact line of code.

Any insights?

Thanks,
-JSK-