[m-rev.] diff: workaround standard library initialization problems in the Java grade

[Julien Fischer]

Hi Sebastian,

On Sun, 6 Mar 2016, Sebastian Godelet wrote:

> Concerning the library initialisation problem, you mention
>> this in Java using static initializers we can't guarantee that the order things
>> occur in.
> But reading the docs and writing a simple test program (c.f. attached Test.java)
> the order of static initialisers is guaranteed by the JVM.

The Java spec. guarantees that within a class the initializers are run in textual
order.  It gets bit more hand-wavy when multiple classes are involved, in particular:

     The fact that initialization code is unrestricted allows examples to be
     constructed (§8.3.2.3) where the value of a class variable can be observed when
     it still has its initial default value, before its initializing expression is
     evaluated, but such examples are rare in practice

This is, I'm fairly certain, what we encounter below.

> If you run my test class like this: `java Test C B A' with any order of A B C,
> the output will always be:
> A0
> A1
> B0
> B1
> C0
> C1
> This works also for: java Test C C.
> So to solve the problem the call to std_library_init/2 must be wrapped into a static block,
> maybe in the same class defining the procedure, and each user initialiser
> must contain a static reference to the library class (either by accessing a static field or using Class.forName, etc.).

I tried that -- it doesn't (currently)  work.  The situation with Mercury is
bit more complicated than your test program: we use static initializers for
three purposes, (1) filling in the static fields for RTTI data structures, (2)
filling in the static fields containing static ground terms and (3) running the
predicates specified by ':- initialise' declarations.

I suspect the reason I am encountered problems with the approach you mentioned
above is that (2) and (3) are not in the right order.  That's the reason I
described this change as a "workaround" rather than a "fix".   It may be
possible to modify the code generator so that it generates the static
initializers in an appropriate order, I haven't looked into that yet 
though.

Julien.