> What's the "Java dirty trick" that the code talks about? Ari,
Do you really want to hear the explanation ;-) ? OK, here it is. This is related to subtelities of SWIG and Java garbage collection. Imagine that DISOWN is still used for the input parameter of ForceToMultiPolygon Consider the following code : geom1 = ogr.CreateGeometryFromWKT(xxxx); geom2 = ogr.ForceToMultiPolygon(geom1); geom2 = null; /* big memory allocation */ foo(geom1) If nothing special is done, during the big memory allocation, the garbage collector will collect the geom2 object. During its finalization, this will call the destructor of the underlying C++ object (let's call it geom2_cpp). But since the call of ForceToMultiPolygon(), geom1_cpp is owned by geom2_cpp, thus deleting geom2_cpp will cause geom1_cpp to become invalid. And foo(geom1) would operate on garbage. This can be fixed (I have already done this for Feature.SetGeometryDirectly()) by adding special code in ogr_java.i so that geom1 (the Java object) holds a Java reference to geom2 (the Java object). So the 2 objects are bound together and garbage collection of one cannot occur if the other one is still in scope... Calling Clone() and separating the lifetime of the 2 objects avoids the above complication. Best regards, Even > > Ari > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
