[gdal-dev] Issues with Java Bindings in 1.5 ...

[Tamas Szekeres]

Rick,

You can get further information about the history of the related
changes from this ticket:
http://trac.osgeo.org/gdal/ticket/1578

According to the changeset http://trac.osgeo.org/gdal/changeset/11640
The ColoryEntry is treated as objects for all of the binding instead
of arrays. Therefore the typemaps for GDALColorEntry in java has
become outdated.
It seems to me that these typemaps in the java bindings are tending to
map GDALColorEntry directly to java/awt/Color which is a target
language specific type.

I can consider the following 2 trivial options to fix this problem:

1, Revert the change for java

Index: gdal.i
===================================================================
--- gdal.i	(revision 13527)
+++ gdal.i	(working copy)
@@ -258,7 +258,7 @@
 // GDALColorEntry
 //
 //************************************************************************
-#ifndef SWIGPERL
+#if !definied(SWIGPERL) and !defined(SWIGJAVA)
 %rename (ColorEntry) GDALColorEntry;
 typedef struct
 {


2. Strip the GDALColorEntry typemaps and thread ColorEntry as a separate class.

Index: typemaps_java.i
===================================================================
--- typemaps_java.i	(revision 13527)
+++ typemaps_java.i	(working copy)
@@ -65,46 +65,9 @@



-%typemap(in) (GDALColorEntry *) (GDALColorEntry tmp) {
-  /* %typemap(in) (GDALColorEntry *) (GDALColorEntry tmp) */
-  $1 = NULL;
-  float *colorptr = 0;
-  const jclass Color = jenv->FindClass("java/awt/Color");
-  const jmethodID colors = jenv->GetMethodID(Color, "getRGBComponents",
-    "([F)[F");

-  jfloatArray colorArr = jenv->NewFloatArray(4);
-  colorArr = (jfloatArray)jenv->CallObjectMethod($input, colors, colorArr);

-  colorptr = (float *)jenv->GetFloatArrayElements(colorArr, 0);
-  tmp.c1 = (short)(colorptr[0] * 255);
-  tmp.c2 = (short)(colorptr[1] * 255);
-  tmp.c3 = (short)(colorptr[2] * 255);
-  tmp.c4 = (short)(colorptr[3] * 255);
-  /*printf( "  %d, %d, %d, %d\n",
-                    tmp.c1, tmp.c2, tmp.c3, tmp.c4 );*/
-  $1 = &tmp;
-}

-%typemap(out) (GDALColorEntry *) {
-  /* %typemap(out) (GDALColorEntry *) */
-  const jclass Color = jenv->FindClass("java/awt/Color");
-  const jmethodID ccon = jenv->GetMethodID(Color, "<init>",
-    "(IIII)V");
-  $result = jenv->NewObject(Color, ccon, $1->c1, $1->c2, $1->c3, $1->c4);
-}
-
-%typemap(jni) (GDALColorEntry *) "jobject"
-%typemap(jtype) (GDALColorEntry *) "java.awt.Color"
-%typemap(jstype) (GDALColorEntry *) "java.awt.Color"
-%typemap(javain) (GDALColorEntry *) "$javainput"
-%typemap(javaout) (GDALColorEntry *) {
-    return $jnicall;
-  }
-
-
-
-
 /*
  * Typemap argout of GDAL_GCP* used in Dataset::GetGCPs( )
  */

I would suggest to apply #2 in the development version since it
reduces the divergence between the java and the other languages,
however it breaks the backward compatibility.

Best regards,

Tamas




2008/1/14, Rick Brownrigg <brownrigg at sunflower.com>:
> I have spent some time investigating the build issues for the Java
> bindings in 1.5, and for the most part there are a couple of nearly
> trivial fixes to the Makefile and the environment settings that are
> required. However, the most troublesome issue seems to be a swig
> type-mapping issue, which at present I do not know how to correct. It
> centers upon the gdal type ColorEntry, which is mapped in
> ...../swig/include/gdal.i    For reasons I don't understand, the
> generated file ..../swig/java/org/gdal/gdal/ColorEntry.java tries to
> pass arguments of type long (a pointer presumably) to the various native
> settors/gettors implemented in gdalJNI.java (also a generated file),
> which is expecting java.awt.Color objects instead. Hence the code will
> not compile.  I don't understand the source of the mismatch,
> particularly as these two files are generated by swig.
>
> Note that this mismatch was present in 1.4.x, but was masked by a #ifdef
> SWIGCSHARP directive around the mapping in gdal.i.  (and thus there was
> no Java proxy for the gdal type ColorEntry in 1.4.x (?)).
>
> I had indicated I would volunteer to support the Java bindings, but with
> this experience, I am now not confident  that I can do so in a timely
> fashion.
>
> FWIW...
> Rick Brownrigg
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>