Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Umberto,

Here is the corresponding java code to reproduce the issue:

<code>
import edu.umn.gis.mapscript.*;

public class DrawMap {

  public static void main(String[] args) {
    try
	{
	  System.loadLibrary("mapscript");
	}
	catch(UnsatisfiedLinkError ule)
	{
	  System.err.println(ule);
	  System.exit(-1);
	}

    mapObj map = new mapObj(args[0]);

	hashTableObj ht = new hashTableObj();
	ht.set("key0", "value0");
	ht.set("key1", "value1");
	ht.set("key2", "value2");

	for (int i = 0; i < map.getNumlayers(); i++) {
		map.getLayer(i).setMetadata(ht);  // this row causes the exception
		System.out.println("Layer [" + i + "] name: " + map.getLayer(i).getName());
	}
	map.delete();
  }
}
</code>

I was using jdk1.5.0_07.

Note that i would not want to make demonstrations for the suggested
members one by one, since leaving these elements writeable makes the
interface unclear and incoherent.

Tamas



2006/8/17, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> On 8/17/06, Daniel Morissette <dmorissette at mapgears.com> wrote:
> > Tamas Szekeres wrote:
> > >
> > >> I think you can safely hide the labelPathObj, that should not be
> > >> exposed. I think the others
> > >> should be immutable too (assuming I understand the problem correctly),
> > >> the question is how
> > >> many scripts will the change break and should backward compatability
> > >> breakage be limited
> > >> to major releases (e.g. 5.0).
> > >>
> > >
> > > Those scripts are *erroneous* !  It would be desirable to force the
> > > users to put them into a good shape as soon as possible.
> > >
> > >
> >
> > It seems that I should take position as release manager but
> > unfortunately I do not know or use SWIG MapScript much so I have to rely
> > on those who know to make an opinion on whether the current stuff is
> > dangerous enough to warrant breaking a few scripts with 4.10.
> >
> > Based on the understanding I have of the problem from reading this
> > thread and previous discussions, it seems to me that if those scripts
> > are doing something that is just waiting to bomb then changing SWIG
> > MapScript in v4.10 to make those object references immutable is not a
> > backwards compatibility issue, it is a bugfix and a service we are
> > making to those users by forcing them to fix their scripts... and in the
> > end their apps will just be more robust.
> >
>
> Daniel,
> IMO  we are talking about fixing pieces of code we are not even sure
> they are broken. For instance I have some Java mapscript tests (and an
> application) running just fine that add layers and classes at run time
> and that's why I am so reluctant in approving this proposal. Only once
> we get a test case that reproduces this errors reliably then we can go
> and change the code.
>
> Unfortunately I couldn't join the IRC meeting because I am on vacation
> otherwise I'd have spoken  earlier (I am writing this on the road).
>
> Regards,
> Umberto
>
> > The real question that I would throw at the SWIG MapScript experts is:
> > "Is the practice of overwriting those object references really dangerous
> > or not?"
> >
> > If the answer is yes then I think that solves the question and we need
> > to apply the fix and force users to fix their scripts.
> >
> > If there are object references that can safely be overwritten (such as
> > colorObj) then my opinion is that we should not touch them in 4.10.
> >
> > Daniel
> > --
> > Daniel Morissette
> > http://www.mapgears.com/
> >
>