To build your application so that the rlm913 dll file or files is always included in the build, please do the following:

• In Visual Studio’s Solution Explorer, right-click on your application’s node and select Add->Existing element….
• Navigate to the appropriate rlm dll (rlm913_x86.dll or rlm913_x64.dll) and select it.  The file will now be added to the project. (Note that you cannot simply add it as a reference, since it is not a managed DLL.)
• Right-click on the newly added rlm dll in Solution Explorer and select Properties.
• In the properties pane, look for the Copy Output property and make sure it is set to Copy Always.
• Repeat the process for the other rlm dll, if you want both to be part of your application (only if you are building the application as Any CPU — so that it will run as 32-bit on a 32-bit system, and as 64-bit on a 64-bit system.
• Build your application.  Now, the rlm dlls will always be copied into your build.

For example, if you have proxied the Java method:

public void registerListener(MyListenerInterface)

and have implemented .NET code like the following:

[Callback("java.util.EventListener")]
public class MyListenerClass : MyListenerInterface { … }

and then call:

javaClass.registerListener(new MyListenerClass());

the code will properly compile, but when it executes, an IllegalArgumentException will be thrown.

If this happens, the solution is to make sure that the [Callback] or [AsyncCallback] attribute specifies the precise listener class expected on the Java side.  In this case, changing the attribute to

[Callback("MyListenerInterface")]

will solve the problem.  Note that the attribute must contain the fully qualified name of the interface.

There are two ways to work around this problem:

The simplest way is to not use the designer to add the problematic control, but rather to add the control manually, by writing code.

The other approach is to identify the problematic lines that cause the proxies to be called from the designer and temporarily comment them out. After finishing with the designer, you can uncomment the lines of code.  Alternatively, you can place the problematic lines inside a try/catch block that will catch TypeInitializationExceptions and drop them on the floor. After your are done with the designer, remember to remove the try/catch block or otherwise handle the TypeInitializationExceptionss or pass them along, since it is dangerous to ignore TypeInitializationExceptions in your running application.

Situation: In Java-to-.NET projects, if you are using by-value proxies and a SecurityException is thrown.

The issue has to do with the use by JNBridgePro of certain reflection calls that may throw exceptions if the proper security policies have not been set in your Java Runtime Environment (JRE). The problem particularly manifests itself when by-value proxies are passed in Java-to-.NET projects, and a passed proxy class has protected fields whose values are being passed.  Note that the default security managers with most JREs will not cause this exception to be thrown, so it is unlikely that you will see it. If you do see this exception, you have two options for addressing it:

1) You can set your JRE’s java.policy file to grant permissions for the operations that cause the problem.  In particular, add the following lines:

grant codebase “file://location of jnbcore.jar_goes_here”
{
permission java.lang.RuntimePermission “*”, “accessDeclaredMembers”;
}

Once this change is made, the exception will be thrown, and everything will work properly.

2) If you cannot change the Java security policy, or you do not care about the values of protected fields being passed, simply set the following properly in your Java-side configuration file:

javaSide.throwSecurityException=false

When this property is set to false, the exception will not be thrown, and the values will not be passed for protected fields (that is, the values that are passed are default values such as 0 (zero), null, or the empty string, depending on the type of the field). Note that if a setting for javaSide.throwSecurityException is left out of the Java-side configuration, its default value, true, will be used, and the SecurityException will be thrown.

• You can install the 32-bit version of JNBridgePro on a 64-bit machine
• You can download and install both the 32-bit and 64-bit versions of JNBridgePro on the same 64-bit machine
• If you are creating a .NET-to-Java application that uses shared memory, you must decide whether the application will always run as a 32-bit application or as a 64-bit application, then use the 32-bit or 64-bit versions of the JNBridge runtime components (particularly jnbsharedmem.dll, jnbjavaentry.dll, jnbjavaentry2.dll). If you are running as a 32-bit process, you must use a 32-bit JRE with a 32-bit JVM.dll. If you are running as a 64-bit process, you must use a 64-bit JRE with a 64-bit JVM.dll.
• If you want to create an “Any CPU” .NET-to-Java application (that is, an application that will run properly as a 32-bit application on a 32-bit machine, and as a 64-bit application on a 64-bit machine), then you must use tcp/binary or http/soap. You will not be able to use shared memory. (Note that it is actually possible to use shared memory with “Any CPU,” but you will need to take care to deploy 32-bit JNBridgePro components when the application is being deployed on a 32-bit machine, and to deploy 64-bit JNBridgePro components when the application is being deployed on a 64-bit machine.)
• The 64-bit version of JNBridgePro contains both 32-bit and 64-bit versions of the license management software (rlm913_x86.dll and rlm913_x64.dll). If your application will always run as a 32-bit or 64-bit application, include the appropriate version of the license management dll. If your application is “Any CPU” and will run as either a 32-bit or 64-bit process, then include both rlm913_x86.dll and rlm913_x64.dll; the appropriate version will automatically be used.
• If you are creating a Java-to-.NET application that uses shared memory, you must decide whether the application will always run as a 32-bit application or as a 64-bit application, then use the 32-bit or 64-bit versions of the JNBridge runtime components (particularly jnbsharedmem.dll, jnbjavaentry.dll, jnbjavaentry2.dll). If you are running as a 32-bit process, you must use a 32-bit JRE with a 32-bit java.exe. If you are running as a 64-bit process, you must use a 64-bit JRE with a 64-bit java.exe.
• If you want to use the Visual Studio plug-in, you may do so with either the 32-bit or the 64-bit version of JNBridgePro. However, since Visual Studio is a 32-bit application, if you are using the 64-bit version of JNBridgePro then you may only use the plug-in with tcp/binary or http/soap; you cannot use it with shared memory.
• If you want to use the Eclipse plug-in, the 32-bit version of Eclipse will only work with the 32-bit version of JNBridgePro. The 64-bit version of Eclipse will only work with the 64-bit version of JNBridgePro.

Note: This copy of JNBridgePro is for evaluation purposes only. JNBridgePro proxy components targeted for licensed runtime environments must be generated using a permanent JNBridgePro Developer license. For mroe information on licensing, please see: http://www.jnbridge.com/licensing.htm

This message appears whenever you use JNBridgePro proxy dlls or jar files that have been generated using an evaluation license. Your application will continue to run, but you will continue to see the warning message until you re-generate the proxies using a permanent JNBridgePro developer license and use the re-generated proxies in your application.

The purpose of the warning is to remind you that production work must be done with proxies generated by properly licensed JNBridgePro proxy generation tools and not with the free evaluation licenses.

With JNBridgePro 6.0, the smaller-feature-set Standard Edition has gone away: JNBridgePro 6.0 includes all the features of JNBridgePro EE in previous versions.

Current customers, with active support and maintenance contracts, may upgrade to JNBridgePro 6.0 at no or minimal cost. Please contact us for details.

A: Yes! You have two choices. One is to temporarily switch from shared memory to TCP/binary, then start up the Java side in its own debugger and debug it in the usual way.

You can also debug while using shared memory as follows:

Alter the .NET-side configuration by adding the following jvmOption (note that the jvmOptions number could be different in your application):

jvmOptions.0=”-Xrunjdwp:transport=dt_socket,server=y,address=4000,suspend=n”

Then, start up the application and attach a Java debugger to the process in the manner prescribed by the particular Java development environment that you’re using.

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.