Cannot create a wrapper for class with a function called "copy"

[Olivier Chafik]

From @jarBwocky on September 17, 2014 16:56

Using JNAerator on this header fails:

class __declspec(dllimport) MiniTest {
public:
bool setSomeValue(uint seconds);
bool copy();
};

The _jnaerator.preprocessed.c is ok:

line 1 "D:\temp\minitest\minitest.h" 1

class __declspec(dllimport) MiniTest {
public:
bool setSomeValue(uint seconds);
bool copy();
};

but the _jnaerator.rawParsed.cpp is blank, and no wrapper is produced.

Commenting out the bool copy(); in the header then makes it work ok, and _jnaerator.rawParsed.cpp then contains:

attribute((dllimport)) class MiniTest {
bool setSomeValue(uint seconds);
};

and the MiniTest.java is produced correctly.

Command used was:
java -jar jnaerator-0.12-20140626.234513-58-shaded.jar -mode Directory -runtime BridJ -v minitest.h

This is a minimal example of the issue I have with a 3rd party dll. I cannot change the name of the copy() function itself as that is beyond my control.
Any advice on a fix or workaround?
Cheers,

Copied from original issue: nativelibs4java/nativelibs4java#528

[Olivier Chafik]

From @jarBwocky on September 22, 2014 9:2

The workaround is pretty simple:
Rename the "copy()" function in the header file to something like "copyRenameMeToCopyAgain()".
Run JNAerator with -mode Directory.
Edit the resulting .java file. Find and replace the "copyRenameMeToCopyAgain() " with "copy()"
Package up into jar.
For convenience I created a base .jar using the -mode Standalone option (which is unusable due to the bug noted). Then edited the jar, deleted the generated files leaving the lib and org directories so it has the BridJ support, and replaced them with the files from the (edited) Directory output.