Problem: You’ve proxied a Java class. Later, you changed the Java class (e.g., added or deleted a member, or changed the signature of a member), and attempted to reload the class into the proxy generation tool. After doing so, the displayed signature for the class does not reflect the changes you made to the underlying Java class, and the re-generated proxies do not reflect the changes, either.

The most likely reason for this problem is that the proxy tool was running, and you had already loaded the old version of your Java class, while you were editing and recompiling the new version of the Java class.

The proxy generation tool runs its own JVM copy, either in-process (if you’re using shared memory) or in a separate process (if you’re using TCP/binary or HTTP/SOAP). The Java side is started up as soon as it’s needed, the first time that Java classes are loaded or proxies are generated. For example, if you are running TCP/binary, the proxy tool will display “Creating binary server” when starting up the Java side in its own process.

The JVM will keep running until the proxy tool shuts down, or until something causes it to restart — for example, changing the classpath. If you try doing that after having loaded some classes (so that the Java side has started), you will notice that the proxy tool will report that the Java side is stopping and starting again. That’s because the running JVM doesn’t see changes to the classpath — the only way to see them is to restart.

The problem is that if you’re running the proxy tool and you change one of the classes you’ve already loaded, the proxy tool does not see subsequent changes because the class in question has already been loaded in the JVM. If you attempt to reload the class in the proxy tool, it will go to the JVM, see the originally loaded Java class and not the changes, and will report exactly the same class as before, so you won’t see the changes.

The workaround is essentially to restart the Java side. One way to do that is by exiting the proxy tool and then restarting it. Alternatively, you can force the JVM to restart while the proxy tool is running. The easiest way to do this is to simply change the classpath. Just bring up the Edit Classpath dialog, and then dismiss it by clicking on OK. That will cause the JVM to restart. Once this is done, re-load the changed classes using Project–>Add classes from classpath… or Add classes from jar file…, and the loaded class signatures will be updated to reflect the changes. Opening and closing the Edit Classpath dialog will work with both the standalone GUI-based proxy tool and the Visual Studio plug-in.

Note that all of the above only applies when the JVM is running in its own process and TCP/binary or HTTP/SOAP communications is being used in the proxy tool. If shared memory is used, the JVM’s process cannot be restarted, because the JVM is running inside the .NET process, and a JVM hosted inside another process cannot be unloaded and reloaded. Therefore, if you are using shared memory in the proxy tool, and you need to restart the JVM, it is necessary to exit and restart the proxy tool.

One way to avoid this problem is to not run the proxy tool while you are updating your Java classes. While this may be practical if you are running the standalone proxy tool, it may not be practical if you are running the Visual Studio plug-in. In that case, simply restart the Java side using the instructions above.

Other possible reasons for changes to Java classes not appearing in the proxies can be found here.