Hello,

I had a look to JNAerator thru WebStart?.

On the C side you have

enum SimpleEnum? {

First, // first comments Second = 10, // comments on second Last // not a real value

converted in Java to

public static interface SimpleEnum? {

/// first comments public static final int First = 0; /// comments on second public static final int Second = 10; /// not a real value public static final int Last = 11;

}

The the field is passed to the method as simple int:

/// @see SimpleEnum? public int enumValue;

Does the native side care about receiving an "int" instead of a SimpleEnum? ?

Hi Frederic,

We could indeed think of retaining the type-safetiness here, by creating some int-convertible class which would be constructable with an arbitrary value and would have public static final enum fields. This might however make some expressions a bit more complex, such as :

enum E { a, b = a + 2 };

which could result in :

public static final class E extends jnaerator.Enum {
public E(int value) { super(value); }
public static final E a = new E(0);
public static final E b = new E(a.value + 2);
}

A major downside is that we'll slow down the loading of most libraries, because of all the enum instances that will need to be created during the class initialization. Also, I'm unsure how much more memory it will take. You can file an issue for this if you wish :-) Cheers

@frederic.conrotte btw, BridJ supports fully typed enums (along with combining enum flags)

I want to generate BridJ and JNA files from the same set of C header files. However this fails because of the following: public class DeferredFileReader? extends Reader { ... static java.util.HashSet?<File> files = new java.util.HashSet?<File>();

Now I think, the set is there so that header files if included by multiple other header files would be parsed only once.

Also jnaerator-maven-plugin doesn't support forked mode so for now I am cleaning up that set via reflection to get around the issue.