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

[Paul Bone]

On Tue, Dec 16, 2014 at 12:01:42PM +1100, Julien Fischer wrote:
>
> Hi Paul,
>
> On Tue, 16 Dec 2014, Paul Bone wrote:
>
>> Branches: master
>>
>> The concept and names of the classes and new method have already been
>> improved.  So no review is necessary.
>
> Wanna bet? ;-)

I've been having trouble with typos since I had my eye surgery.  I'm not
always seeing what I've typed so I don't notice.

>> +
>> +    /**
>> +     * 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"?

>>
>> +        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.

>> 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.


-- 
Paul Bone