Mapscript Java Enhancements

[jerry.pisk@…]

1. Static constructor in mapscriptJNI that loads mapscript library. This is 
needed to use mapscript under a servlet container as the library has to be 
loaded in the same class loader as the JNI class. The only drawback I can see 
is somebody versioning mapscript module, but those are mostly going to be 
advanced users who will not have a problem modifying the swig code to use 
versioned name. Or we can include the version number in the module during the 
build process, it just needs to be done everywhere, in the SWIG code and in 
the makefile so whatever makefile builds is the same SWIG (actually Java) uses.

2. Added byte[] imageObj.save().

3. I also created typemap to map char** to String[] but I decided not to 
include it in this patch since SWIG documentation says that mapping will only 
work for NULL terminated char**s. I do not know at this time whether 
mapserver's char**s are NULL terminated or not.

[jerry.pisk@…]

Java SWIG Module

[jerry.pisk@…]

Java Extensions

[jerry.pisk@…]

Updated mapscript.i

[jerry.pisk@…]

Java Module

[unicoletti]

Hi Jerry,
thanks for your patches, I have been aked by Sean to comment on them.

I premise that I have not actually compiled a mapscript version with your
patches, I have just looked at them.

The byte[] imageObj.save() method looks ok and actually is an interesting extension.

The static constructor instead presents at least a problem (I have added comments):

%pragma(java) jniclasscode=%{
    static {
        try {
            System.loadLibrary("mapscript");
        } catch (UnsatisfiedLinkError e) {
            System.err.println("SEVERE: mapscript native code library 
failed to
load. \n" + e);
///********************* THE EXCEPTION SHOULD BE AT LEAST RE-THROWN HERE 
*******/
            +throw e;
        }
    }
%}

In my opinion the static constructor should simply let the exception 
pass through, without writing *anything* to stderr. It will be up to client 
code catching and dealing with such error. It looks to me like we are 
trying to be too smart/protective, and are not getting any *real* benefit from this.
To support this point I can bring my experience with Oracle OCI jdbc driver 
which relies on Oracle native libraries. When the shared library is not 
available you get exactly an UnsatisfiedLinkError.

More over if you catch and swallow this exception the client will not have any
chance to know mapscript is not setup ok.
An argument against writing to stderr is that this output could interfere with
other output from a servlet or anything else and in this case it would be
impossible for the developer to remove it without hacking the swig interface files.

So there is just a small modification to make, after which I will try to compile
and run my app with your enhancements and see what happens.

As of proper patches you can email me privately if you need directions on how to
 produce them. Good work [PAT ON THE BACK HERE]!

[jerry.pisk@…]

Java Module

[unicoletti]

Good idea to use an environ variable. This way one does not even have to recompile.

When the code says:
System.getProperty("mapserver.library.name", "mapserver");

I guess it was meant to read:
System.getProperty("mapserver.library.name", "mapscript");

[sgillies@…]

Committed to branch-4-4.  Could you test it out for me?

In the CVS HEAD I'm going to try getBytes in image.i so that we can reuse it
for other languages.

[sgillies@…]

Are either of you willing and able to try the code in CVS HEAD (aka 4.5)?  
Jerry, I committed the getBytes method itself to image.i, the gdBuffer 
struct to mapscript.i (changing data to unsigned char *data).  I created a 
Python typemap that converts the struct to a string and it works right away.

[jerry.pisk@…]

I tried both HEAD and branch-4-4 and they both work for me. Anybody using the 
4.4 byte[] save will have to change their code for 4.6. Maybe we could keep 
the overloaded save in Java (in javaextend.i) in addition to the getBytes 
method? I didn't expect this to be backported to 4.4.

[jerry.pisk@…]

Please ignore my last comment about overloaded save method.

[sgillies@…]

ok, closing this bug.  thanks for your help!