When you generate proxies in a .NET-to-Java project, you see a dialog box titled “Proxy class naming conflicts” with the message “There was a problem proxying the following classes because their names conflicted with the names of automatically generated helper classes for proxied interfaces.”

This is not an error, but an informational warning. In certain cases, you can ignore it; in other cases you can work around it.

The problem has to do with the way Java interfaces are proxied. Because Java interfaces can contain static constants, but .NET (C#, VB.NET) interfaces cannot, JNBridgePro extracts the static constants from the Java interfaces when the interfaces are proxied, and generates a new helper class in which the proxies are placed. For example, if you proxy the Java interface MyInterface, the resulting proxy DLL will contain the proxied MyInterface, and an additional helper class MyInterfaceConstants. Any static constants that appeared in the original underlying MyInterface will not appear in the proxied MyInterface, but will appear in MyInterfaceConstants.

A problem arises when there is also another Java class that you are attempting to proxy that has the same name as the automatically generated helper class; for example, if you have a Java class MyInterfaceConstants that you are also attempting to proxy at the same time as you are proxying MyInterfaces.

When this happens, either the helper class or proxy of the actual Java class with the same name will be generated, but not both. Which one is generated is undetermined. The dialog box indicates that this is the case. When this happens, you have several choices:

• If you are not directly calling from your .NET code either of the classes in conflict, you can simply ignore the message.
• You can choose to proxy one of the classes in conflict, or the other. To do so, place a check box in the Exposed Proxies pane next to the class you do not want to proxy, then click on the Delete button to remove it from the Exposed Proxies pane. Then generate your proxies.
• If you have access to the Java source code, you can change the name of one of the classes in conflict, then re-generate the proxies. The conflict will be removed.
• Alternatively, if you do not have access to the Java source code, you can add an additional Java class that act as facade for one of the conflicting classes. The facade class can act as a pass-through. Then, proxy the facade class but not the conflicting class, and use the proxy of the facade class from your .NET code.