MapScript Java memory management

[Tamas Szekeres]

Arkadi,

In this particular case both approach should work.
style.setColor(symbolColors[i]); makes a copy of the underlying struct
by value so both of the symbol object might be destroyed separately.
(However using different settings of ALPHACOLOR_ENABLED when compiling
the core mapserver and the SWIG interface might be a problem with the
recent version.)

Anyway, I consider the latter approach is safer especially when the
underlying object has pointer references to further objects or
strings. In this case the copy itself will not duplicate the further
references so the memory of those items will be destroyed twice.
Before the latest release we have made some effort to make these
unsafe properties read-only and engourage the folks to use your second
approach when setting the properties of these items.

The latest development version is also capable to operate with the
hexadecimal representation of the color value.

Best regards,

Tamas Szekeres



2007/5/29, Arkadi Shishlov <arkadi at mebius.lv>:
> Are there guidelines documented what need to be done (additionally to VM garbage collection) to correctly remove unneeded objects (classObj, layerObj), and how to use objects that may exists outside of Map object hierarchy? Like colorObj, in particular. The previous threads on this list indicate that there are some problems.
> I'm asking because Tomcat is crashing for me sometimes and I suspect this because of colorObj
>    protected static colorObj[] symbolColors = {..}
>    style.setColor(symbolColors[i]);
> later the class is removed with removeClass(), also entire context is reloaded in development process. Is it correct use of colorObj? Or
>    style.getColor().setRGB()
> should be used? Which is rather verbose, because setRGB() takes all components separately.
> Any other quirks?
>