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

Sebastian Godelet sebastian.godelet at outlook.com
Mon Mar 7 13:02:31 AEDT 2016

Hi Julien,

Oh I see now why this is so complicated, I didn't think of ground terms, so for a proper fix the compiler would have to
honour the functional dependencies between the various static initialisation blocks.
One thing that might be successful is using a custom class loader, which first loads a class that is responsible for
initialising library code and then delegates the work to its parent class loader. Although now as I understand that might still cause problems with the ground terms.
For compile time expressions, the order problem in static initialisers can be avoided by using absolute references throughout,
which works if the terms involved are constant, see http://stackoverflow.com/questions/12448465/in-what-order-are-static-blocks-and-static-variables-in-a-class-executed 
If using a custom class loader works, then a similar mechanism to class-loading in .NET can be archived by using the assembly resolver
AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => { ... }

On a related problem I once had a case when the user `:- initialise' blocks where in a different order depending which grade was used,
Although unfortunately I don't know any more how exactly I produced that outcome.


More information about the reviews mailing list