Problem: When attempting to generate a proxy assembly from a project file created on another machine, JNBProxy hangs or throws a ClassNotFoundException.

There are a couple of reasons why this might happen. You may have left some classes or jar files out of the classpath used by JNBProxy on the new machine. Attempt to remedy the problem by adding the appropriate classes or jar files to the classpath.

If this doesn't fix the problem, it is possible that you are attempting to generate the new proxy assembly using a different Java platform from that on which the original proxy assembly was generated on the first machine. The project file generated on the first machine may include nested classes that are implementation dependent and which may not exist on the Java platform on the second machine. For example, in some Java implementations, the class java.lang.ThreadLocal contains a nested non-public class java.lang.ThreadLocal$SecureKey; other Java implementations do not have this class. In such a case, the Java-side will throw ClassNotFoundException. Some Java implementations have a bug that may cause the Java runtime to hang in certain cases when a missing class is encountered.

When such behavior is encountered, the workaround is to rebuild the JNBProxy project from scratch, and to not use the project file from the other machine.

It should be noted that, even though it might not be possible in some cases to move a project file from one Java platform to another and to generate a proxy assembly from that project file on the new platform, proxy assemblies generated on the first Java platform will work without problem on all other Java platforms. The .NET side will always access Java classes through proxies representing public classes or public interfaces; there will be no occasion for the .NET side to directly access a non-public class or interface.