[m-rev.] diff 3/3: [java] The thread pool now works when Mercury is used as

[Julien Fischer]

On Tue, 16 Dec 2014, Paul Bone wrote:

> On Tue, Dec 16, 2014 at 12:01:42PM +1100, Julien Fischer wrote:

>>> +
>>> +    /**
>>> +     * Request that the thread pool shutdown.
>>> +     * This method does not wait for the thread pool to shutdown, it's an
>>> +     * asychronous signal.  The thread pool will shutdown if: shutdown() has
>>> +     * been called (implicitly when running as an application) and there are
>>
>> What do you mean by "running as an application"?
>
> The oppisite of using Mercury as a library.  Is there a better way to
> explain this other than "when main/2 is written in Mercury"?

    ... where the program entry point is a Mercury main/2 predicate.

>>>
>>> +        try {
>>> +            runProgram(args);
>>> +        } finally {
>>> +            // When we have finished calling Mercury procedures then we need to
>>> +            // tell the Mercury Runtime that we've finished using it.
>>> +            // This invokes any finalisers specified using ':- finalise'
>>> +            // declarations in the set of Mercury libraries we are using.  It
>>> +            // also tells the thread pool to shutdown, if the thread pool is not
>>> +            // runnuing then this does nothing.
>>> +            // The static method finalise() in the MercuryRuntime class does
>>> +            // this.
>>> +            //
>>> +            MercuryRuntime.finalise();
>>> +
>>> +            // The Mercury exit status (as set by io.set_exit_status/1) may
>>> +            // be read from the MercuryRuntime class.
>>> +            //
>>> +            out.println("JavaMain: Mercury exit status = "
>>> +                + MercuryRuntime.getExitStatus());
>>> +
>>> +            out.println("JavaMain: end main");
>>> +        }
>>> +
>>> +        System.exit(MercuryRuntime.getExitStatus());
>>> +    }
>>
>> You should explain *why* it is necessary to wrap the calls to Mercury
>> in this try - finally block and the consequences of not doing so in the
>> case of an uncaught Mercury exception.
>>
>
> This may not be obvious to people who don't know Java.  But try-finally is
> farmiliar to someone who does know Java.  All that needs explaining here is
> that finalise() is mandatory and the JVM may not exit (at all) if it is not
> called.

I know people who know Java will be familiar with try-finally.
What they may not be familiar with is how Mercury exceptions work in the
Java grade and what the consequences of not shutting down the thread
pool may be (i.e. the JVM not terminating).

>>> diff --git a/samples/java_interface/standalone_java/Makefile b/samples/java_interface/standalone_java/Makefile
>>> index 407104a..8c3bf94 100644
>>> --- a/samples/java_interface/standalone_java/Makefile
>>> +++ b/samples/java_interface/standalone_java/Makefile
>>> @@ -14,7 +14,7 @@ MER_JARS = $(MER_LIB_DIR)/mer_std.jar:$(MER_LIB_DIR)/mer_rt.jar
>>> .PHONY: all
>>> all: run
>>>
>>> -JavaMain.class: JavaMain.java mercury_lib.jar
>>> +JavaMain.class: JavaMain.java libmercury_lib.jar
>>> 	$(JAVAC) JavaMain.java -cp $(MER_JARS):Mercury/classs -d .
>>
>> Where is libmercury_lib.jar coming from?  In the Java grade, the jar
>> generated for libraries will be named mercury_lib.jar.
>
> the target on the very next line of your Makefile.
>
>>> libmercury_lib.jar: mercury_lib.m
>
> ^ Here.  It looks like I should have changed this line rather than the above
> one.

That's what I get for cut-and-pasting it.

Cheers,
Julien.