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

[Tamas Szekeres]

Hi,

That might be a side effect of the issue below. I guess each of my
suggestions would provide a fix for it.

However I personally don't favour adding much of the target language
specific things in the bindings. It would be more convenient to
implement this at the other side of the API by using the ColorTable
and ColorEntry classes.

Best regards,

Tamas



2008/1/18, abhay menon <abhay.menon at gmail.com>:
> Hi,
>
>  The GDAL Java Bind for GDAL 1.5 got compiled but the GDALTest.Java failed
> to compile.
>
> at line 295
>
> cm = poBand.GetRasterColorTable().getIndexColorModel(
>                                 gdal.GetDataTypeSize (buf_type));
>
> Is the getIndexColorModel method been deprecated is there any other method
> that is return ColorModel which is available in GetRasterColorTable ??
>
> Rgds
>
> Abhay
>
>
>  On Jan 15, 2008 2:40 AM, Tamas Szekeres <szekerest at gmail.com> wrote:
> > 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
> > >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
>
>