SWIG wraps C++ bitmask enums unhelpfully

[Naveen]

While using the FLAG_SPELLING flag from the java binding. This is the code i tried to use it.

TermGenerator termGenerator = new TermGenerator();
termGenerator.setDatabase(db);
termGenerator.setFlags(TermGenerator.flags.FLAG_SPELLING);

I get the below exception.

Exception in thread "main" java.lang.IllegalArgumentException: No enum class org.xapian.TermGenerator$flags with value 0
	at org.xapian.TermGenerator$flags.swigToEnum(TermGenerator.java:146)
	at org.xapian.TermGenerator.setFlags(TermGenerator.java:73)
	at com.searchlab.test.IndexDocument.addField(IndexDocument.java:40)
	at com.searchlab.test.IndexDocument.addFields(IndexDocument.java:63)
	at com.searchlab.test.Main.main(Main.java:25)

[Olly Betts]

If you're using 1.2.13, you must be using the java-swig bindings (since TermGenerator isn't wrapped at all in the JNI ones). Or are you actually using trunk?

Either way issues with the SWIG-based Java bindings aren't "critical" - they're marked as a work in progress in 1.2.x and on trunk haven't yet been in a stable release. And please don't inflate bug priorities - it won't get the bug fixed any sooner.

It looks like SWIG wraps the C++ enum in a way that only allows it to take the values in the enumeration, so the default second argument doesn't work because the value 0 isn't named in the C++ enum.

I think we really want the TermGenerator flags to be wrapped as an Java integer type, because it's really a bitmask. We probably want to do this for any other C++ enums in the API which are used as bitmasks.

This seems to be how to do that:

​http://swig.org/Doc2.0/Java.html#Java_typeunsafe_enums

[Olly Betts]

Fixed by Anish Kanchan in r17932 and r17933 by making the C++ enum an anonymous enum, which arguably makes the C++ API slightly more logical.