Changing to TCP: Configuration, SSL, Whitelisting & Startup

/in , /

This post continues from our earlier walkthrough, Anatomy of a .NET Calling Java Project (Shared Memory), and uses the same BridgeDemo project to demonstrate how to change from Shared Memory to TCP communication.

While Shared Memory offers high performance for co-located components, TCP mode is used when the .NET and Java sides run on different machines. When using TCP, you can optionally enable additional features such as SSL encryption, IP whitelisting, and class whitelisting — features that aren’t applicable to Shared Memory connections.

1) Overview of the TCP Bridge

When the bridge runs in TCP mode, the .NET side and the Java side communicate through a socket connection rather than shared memory.
This offers several advantages:

  - Cross-platform independence – the .NET and Java components can run on different hosts or operating systems.
  - Remote accessibility – the bridge can connect across LAN or WAN networks.
  - Security options – TCP supports SSL, IP whitelisting, and class-level restrictions(class whitelisting).

Unlike Shared Memory, the Java side must be started first in TCP mode so that the .NET side can connect to it.

2) Updating the .NET Configuration (App.config)

In BridgeDemo, open App.config and locate the <dotNetToJavaConfig> section.
Change the scheme from sharedmem to jtcp, and specify the host, port, and optional SSL parameters.

  - scheme – must be set to jtcp
  - host – the machine where the Java side is running
  - port – must match the port defined in java.properties

Example:

<jnbridge>
    <dotNetToJavaConfig
      scheme="jtcp"
      host="localhost"
      port="8085"
      useSSL="true"
      clientCertificateLocation=".\testclient.p12"
      clientCertificatePassword="pw"
      sslAlternateServerNames="myServer" />
    />
</jnbridge>

If you are not using SSL, simply omit those attributes or set useSSL to false.

3) Updating the Java-Side Configuration (java.properties)

On the Java side, update java.properties to switch the bridge to TCP, define the connection port, and enable optional security features like IP and class whitelisting or SSL.

Example — javaSide.properties

javaSide.serverType=tcp
javaSide.workers=5
javaSide.timeout=10000
javaSide.port=8085
javaSide.useClassWhiteList=true
javaSide.classWhiteListFile=./classWhiteList.txt
dotNetSide.ipWhitelist=127.0.0.1
javaSide.keyStore=./keystore.jks
javaSide.keyStorePassword=changeit
javaSide.trustStore=./cacerts.jks
javaSide.trustStorePassword=changeit

4) Adding Whitelisting (Class and IP)

When using TCP, you can restrict which classes are exposed to .NET and which clients are allowed to connect. These options improve security and control without affecting performance.

a) Class Whitelisting

Create a file named classWhiteList.txt in the same directory as java.properties.
Each line specifies a fully qualified Java class name that can be accessed from the .NET side.

Example — classWhiteList.txt

             bridgeDemo.JavaToCall

Then, enable class whitelisting in java.properties:

       javaSide.useClassWhiteList=true
javaSide.classWhiteListFile=./classWhiteList.txt

Only the classes listed here can be loaded by the bridge; all others are blocked automatically.

b) IP Whitelisting

IP whitelisting limits which machines can connect to the Java bridge.
Add the following property to java.properties:

        dotNetSide.ipWhitelist=127.0.0.1

5) Enabling SSL

 SSL enables encryption, server authentication, and client authentication, protecting both sides of the bridge and preventing unauthorized access or code execution.

To implement SSL, you must complete all of the steps outlined in the “Secure communications using SSL” section of the User Guide(p.78)

1) Generate and install certificates
-Each Java side requires an X.509 server certificate whose Common Name (CN) matches the host where the Java side runs.
-Each .NET side requires its own client certificate, consisting of a public certificate and a corresponding private-key file.

2) Create and install the keystore and truststore on the Java side
-Install the Java side’s server certificate in a keystore file.
-Install each authorized .NET side’s client certificate in a truststore file.
-Both files must have passwords and be referenced in the JavaSide.properties file:

3) Create and install the keystore and truststore on the Java side
-Import the client certificate into the Windows Certificate Store.
-Leave the public certificate file accessible on disk so it can be referenced in the bridge configuration.

4) Configure the .NET side for SSL
-specify properties in app.config for SSL

After these steps are completed, all communication between .NET and Java occurs over an encrypted, mutually authenticated SSL channel.
For example, when .NET calls Ping.incr(1) the invocation is transmitted through this secure connection. The Java server’s identity is verified, the .NET client is authenticated, and all data is protected from interception.
The IP and class whitelists, worker-thread pool, and timeout settings continue to apply normally within this secure channel.

5) Starting the Java side

       – The Java side must be started manually before any .NET connections are made.

       – This launches the JNBridge Java component, loads all required classes, and applies the configuration defined in the properties file.

       – Use the following command:

java -cp “.;javaToCall.jar;jnbcore.jar” com.jnbridge.jnbcore.JNBMain /props “javaSide.properties”

This command must be run from the directory that contains the listed JAR files and the javaSide.properties file. When you execute it, Java uses the classpath (-cp) to locate javaToCall.jar (your Java classes) and jnbcore.jar (the JNBridge runtime).

 

Anatomy of a .NET Project That Calls Java (Shared Memory Bridge)

/in , /

1) What We’re Building

In this post we’ll break down the anatomy of a simple interop project where a .NET application calls into a Java class using JNBridgePro with shared memory.

The goal is to make the moving parts visible:

       – how a proxy connects the .NET and Java worlds,

       – what files live on each side,

      – other considerations for shared memory setups.

Switching this project to TCP (plus added considerations like SSL, IP/class whitelisting, and Java-side startup) will be covered in a separated post: Changing to TCP: Configuration, SSL, Whitelisting & Startup.

2) Project Layout

Here’s the directory structure of a demo project (BridgeDemo). At a glance, you can see two main areas:

  - .NET project (BridgeDemo) – the C# application, configuration file, and runtime DLLs.

  - Java side (Java Side) – the original Java class and supporting JARs and properties.

BridgeDemo/
├── BridgeDemo.sln
├── BridgeDemo/    # .NET project
│   ├── Program.cs
│   ├── App.config
│   ├── bridgeDemo.dll    # Added as reference to project, built by JNBProxyGenerator from JavaClass or JAR
│   ├── JNBShare.dll   # Added as reference to project
│   ├── JNBSharedMem_x86/x64.dll
│   ├── jnbauth_x86/x64.dll
│   └── bin/Release/...    # Executable + runtime dlls
├── Java Side/    # Java side
│   ├── bridgeDemo/javaToCall.java,javaToCall.class
│   ├── jnbcore.jar
│   ├── javaToCall.jar          # Java dependency in this demo
│   ├── bcel-6.10.0.jar    # Only needed for shared mem
│   ├── javaSide.properties
│   ├── classWhiteList.txt
│   └── start Java side.bat

3) .NET Side

On the .NET side, the project is built around referenced assemblies, supporting DLLs, and the App.config that defines how it connects to the Java side.

Referenced assemblies

       – bridgeDemo.dll – the proxy assembly that exposes the Java class to .NET.

       – JNBShare.dll – the core bridge library required for all JNBridge communication.

Both are added under References in Visual Studio and have Copy Local = True, ensuring they’re automatically placed in the output folder when you build. This way, BridgeDemo.exe can find them at runtime without extra configuration.

Supporting DLLs

  - JNBSharedMem_x86.dll / JNBSharedMem_x64.dll – required only when using the Shared Memory transport.

  - jnbauth_x86.dll / jnbauth_x64.dll – used internally by the bridge for authentication and setup.

These supporting DLLs are not referenced in the project. They simply need to be present in the same directory as BridgeDemo.exe.

App.config
At runtime, BridgeDemo.exe uses this configuration to tell JNBridge how to locate and load the Java side.
Below is a sample configuration for the Shared Memory transport.

<jnbridge>
    <dotNetToJavaConfig
      scheme="sharedmem"
      jvm64="C:\Program Files\Java\jdk-25\bin\server\jvm.dll"
      jnbcore="C:\Projects\BridgeDemo\Java Side\jnbcore.jar"
      bcel="C:\Projects\BridgeDemo\Java Side\SharedMemory\bcel-6.10.0.jar"
      classpath="C:\Projects\BridgeDemo\Java Side;C:\Projects\BridgeDemo\Java Side\javaToCall.jar;"
    />
</jnbridge>

  - scheme – transport type (sharedmem or tcp).

  - jvm64 – points to the 64-bit JVM to load (jvm32 used if needed).

  - jnbcore – path to jnbcore.jar, which contains the bridge runtime.

  - bcel – only required when using Shared Memory; omitted for TCP.

  - classpath – tells JNBridge where to find your Java classes or JARs (the Java Side folder in this project).

The classpath section determines whether the .NET side connects to a Java package directory containing .class files, a JAR, or both if listed together.

4) Java Side

The Java side hosts the actual code and bridge runtime that the .NET process connects to. It generally includes core/supporting JARs, the Java code or JAR, and a properties file defining how the JVM bridge runs.

Core and supporting JARs

  - jnbcore.jar – always required; contains the bridge runtime and handles all communication.

  - bcel-6.10.0.jar – only needed for Shared Memory transport.

Java code or packaged JAR
You may have either of the following, depending on how your build is structured:

  - A package directory (for example, BridgeDemo/) with .class files.

  - Or a JAR archive (such as BridgeDemo.jar) containing the compiled classes.

Which of these is used depends on the classpath specified in the .NET project’s App.config.

Java-side properties file
This file (for example, javaSide.properties) controls how the JVM runs the bridge. Typical entries include:

javaSide.serverType=sharedmem
javaSide.timeout=10000
javaSide.port=8085 
javaSide.useClassWhiteList=false 
javaSide.classWhiteListFile=./classWhiteList.txt
javaSide.useSSL=false

5) Considerations for Shared Memory setups

Shared Memory provides the fastest .NET↔Java communication since both run in the same process, but it requires correct architecture alignment and file placement.

The JVM architecture must match your .NET build target.

  - 64-bit .NET → use 64-bit jvm.dll.

  - 32-bit .NET → use 32-bit jvm.dll.

Supporting DLLs must also match:

  - JNBSharedMem_x86.dll / JNBSharedMem_x64.dll

  - jnbauth_x86.dll / jnbauth_x64.dll

You can omit the unused architecture’s DLLs (for example, keep only the x64 set for a 64-bit-only build).

If the app may run in both modes (for example, AnyCPU), include all four — JNBridge will automatically load the correct pair at runtime.

All bridge DLLs (JNBShare.dll, JNBSharedMem_x*.dll, jnbauth_x*.dll) must reside in the same directory as your executable.

Handling ClassNotFoundException and NoClassDefFoundError

These errors during shared-memory startup usually come from missing permissions or classloader issues in older JVMs.

  - Permissions – Ensure the user running the app has Read & Execute, List Folder Contents, and Read access to all Java class and JAR folders (jnbcore.jar, bcel-6.x.x.jar, and any app JARs). Missing access prevents the JVM from loading classes, especially under ASP.NET.

  - Classloader conflicts (Java 8 and earlier) – If permissions are correct but errors persist, move the affected .jar from the classpath to the boot classpath using -Xbootclasspath/p: and remove it from the regular classpath.

<jnbridge>
    <dotNetToJavaConfig
      scheme="sharedmem"
      jvm64="C:\Program Files\Java\jdk-25\bin\server\jvm.dll"
      jnbcore="C:\Projects\BridgeDemo\Java Side\jnbcore.jar"
      bcel="C:\Projects\BridgeDemo\Java Side\SharedMemory\bcel-6.10.0.jar"
      classpath="C:\Projects\BridgeDemo\Java Side;"
      jvmOptions.0="-Xbootclasspath/p:C:\Projects\BridgeDemo\Java Side\javaToCall.jar"
    />
</jnbridge>

– In this example, javaToCall.jar was removed from the classpath and added to the boot classpath, allowing the JVM to load it earlier and resolve the conflict.
  (The -Xbootclasspath/p: option works only through Java 8 and was removed in Java 9+.)

 

 

JNBridgePro and the new Windows 8 and VS11 bits

/in , , /

As you’re probably aware, Microsoft today released the new Windows 8 Consumer Preview and the new Visual Studio 11 beta. While we of course don’t yet support JNBridgePro on Windows 8 and VS11, we do encourage you to try it and let us know about any problems you run into.

In our initial tests, JNBridgePro 6.0.1 (our current release) installs and runs fine on the Windows 8 desktop environment. Nothing new or special needs to be done to get that working.  (We do concede that the tiles on the Start screen could be prettier.)

In addition, the JNBridgePro plugin for Visual Studio also works with the new Visual Studio 11 beta, with a little bit of help. If you want to use the plugin with VS11, please contact us, and we’ll let you know what needs to be done. Note that the plugin will not work with the Express version of VS11; it’ll only work with the Standard, Professional, Premium, and Ultimate versions.

Also note that JNBridgePro is not a Metro app, and the generated proxies are not targeted toward the .NET Metro profile, so it currently won’t run in the Windows 8 Metro environment. Are you planning to use JNBridgePro in Metro apps? If so, please contact us.

Instantiating Generic Collections

/in , /

We had a question from a user recently asking how to instantiate certain generic collections in Java-to-.NET projects.  Some of the things that were discussed are of interest to the general community.

The user had a .NET method that was proxied to Java.  The method had several parameters, one of which was List<string>, and the other of which was Dictionary<string, List<string>>.  (Both List<> and Dictionary<,> were part of System.Collections.Generic.)  The questions were how to instantiate these collections and add elements to them.

This is actually one of the rare cases where you need to make use of the proxy for System.String. Ordinarily, .NET strings (System.String) are automatically converted to java.lang.Strings, and you never need to use the proxy for System.String, but you do here, since you need to access the .NET type object for System.String from the Java side.

To instantiate List<string>, you first need to make sure you’ve proxied System.String, as well as System.Collections.Generic.List__1 and System.Collections.Generic.Dictionary__2. Then use the code

import System.Collections.Generic.List__1;
import System.String;
…
List__1 theList = new List__1(String.GetDotNetClass());

Note that String above is the proxy of System.String, because of the import statement. We use that because we need the .NET typeof(string), not the Java String.class.

Note that the proxied List.Add() method has signature void Add(System.Object), so if we want to add a string using the proxied method, we need to do it as follows, using the DotNetString wrapper:

import System.DotNetString;
…
theList.Add(new DotNetString("a string"));

There are several ways to instantiate Dictionary<string, List<string>>, but they generally involve instantiating List<string> as above, and then getting a .NET Type object from that instantiated list. Sometimes you may need to instantiate such a list just to get the Type object; other times you may have such a list already lying around.  Here’s one way to do it, assuming you’ve instantiated theList as above.  If not, you can just write simple code to instantiate such a list and use that.

import System.Collections.Generic.Dictionary__2;
…
Dictionary__2 theDictionary = new Dictionary__2(String.GetDotNetClass(), theList.GetType());

Then, you can add key/value pairs to the dictionary as follows:

theDictionary.Add(new DotNetString("the key"), theList);

That’s really all there is to it. If you have any questions, or want to see some other examples, please don’t hesitate to contact us.

What does “Any CPU” really mean?

/in , , , , /

There’s a new “Prefer 32-bit” option in Visual Studio 2012 that tripped us up, and can trip you up too.

Running through some standard JNBridgePro test examples recently, we were surprised that the examples didn’t work, and the embedded Java side failed. The examples were created using Visual Studio 2012, set Any CPU, and, since we were running the tests on a 64-bit machine and were using shared memory, we supplied a 64-bit JRE as part of the configuration.

After a bit of investigation, we discovered a new setting in the VS 2012 project that isn’t in previous versions of Visual Studio: in the project’s properties, under the Build tab, there is a new checkbox: “Prefer 32-bit.” The checkbox only seems to be enabled when Any CPU is selected, and it was automatically checked. And indeed the running process was 32-bit. What was happening? Didn’t “Any CPU” mean that the application would run as 64 bit on a 64-bit system, and 32 bit on a 32-bit system? And how does “Any CPU/Prefer 32-bit” differ from simple x86?

We did some research and discovered an explanation in a Microsoft blog post here. It turns out that the meaning of “Any CPU” has changed a bit. I won’t go into too many details, but would suggest that anyone doing .NET development read the blog post. In a nutshell, the new “Prefer 32-bit” is connected to Microsoft’s new support for ARM architectures as of .NET 4.5. It also seems to have something to do with Microsoft’s retreat from encouraging 64-bit and “Any CPU” development in deference to 32-bit development, as the complexity of supporting both 32-bit and 64-bit environments has become apparent. In making the changes, Microsoft has made some design decisions that we feel are to the detriment of users. (Also note that we still strongly believe in supporting “Any CPU” and x64 development. Read more about the bitness challenge in this blog post.)

In the first design decision we take issue with, Microsoft has decided to make “Any CPU/Prefer 32-bit” the default in Visual Studio 2012 when creating .NET 4.5 applications. This is unfortunate because users assume “Any CPU” meant the same thing as it previously did (the application will run as 64 bit on 64-bit systems), and because the new “Prefer 32-bit” setting is somewhat hidden and not immediately obvious. In our experience, most users set the Target Platform (Any CPU/x86/x64/etc.) in the configuration manager, where there’s no mention of the “Prefer 32-bit” setting – “Prefer 32-bit” is only visible (and settable) in the project properties, where most developers don’t have a reason to look, but where it’s already been set, without telling the developer.

Second, setting “Prefer 32-bit” as the default leads to inconsistencies in creating new projects versus migrating exiting ones. “Prefer 32-bit” is set in new “Any CPU” projects created in VS 2012, but it isn’t set when migrating an existing project from VS 2010. Props to Microsoft for not altering the behavior of existing projects when migrating from VS 2010 to 2012, but why not go a step further and make “Any CPU” behavior consistent by leaving the “Prefer 32-bit” setting turned off by default in new projects created with VS 2012?

The inconsistent behavior is what really what makes this change so annoying. Microsoft could have offered the “Prefer 32-bit” capability and not surprise unsuspecting users by just leaving the setting turned off by default. Users would happily create new applications without problem, and without suspecting that “Any CPU” could possibly mean anything different than what it meant before. Interestingly enough, users could still target ARM platforms if “Any CPU” running on ARM was guaranteed to run as 32 bit (until 64-bit ARM chips become generally available, at which time such applications will run as 64 bit). Microsoft could also allow developers to specifically target ARM in the same way as they can now specifically target x86, x64, and IA64. I can almost guarantee that this would be less confusing than the current use of “Any CPU” and “Prefer 32-bit,” particularly since very few .NET developers are going to be targeting ARM, at least not for a long time.

So what does this mean for users of JNBridgePro and the JNBridge adapters? First, as mentioned earlier, we still strongly believe in “Any CPU” and x64 development, and are working hard to create products that can be used in “Any CPU” applications. There are some subtleties and complications in making this transparent to the user, but we’ve done a lot of work on this, which you can see in JNBridgePro 7.0, and will soon see in new releases of the adapters. We’ve discussed the work that we’ve done here. The next version of JNBridgePro will have even more support for “Any CPU” applications; particularly, when using shared memory, you’ll be able to specify paths to both a 32-bit and a 64-bit jvm.dll, and the proper JRE will be loaded depending on whether it’s a 32-bit or a 64-bit process. This will make Any CPU applications using shared memory even easier to deploy on any system without changes.

Second, we want all our users to know that JNBridgePro will still work in all “Any CPU” applications using shared memory, even when “Prefer 32-bit” is turned on. When it is, simply use a 32-bit JRE, and when it isn’t turned on, use a 32-bit or 64-bit JRE as is appropriate to the platform. The V.next of JNBridgePro, with the aforementioned ability to specify both 32-bit and 64-bit JREs, will make this process even more transparent.

We’re always trying to stay ahead of Microsoft’s changes, whether they’re ill-advised or not. The change to the meaning of “Any CPU,” and the new default “Prefer 32-bit” setting are just one example of how we’ve stayed on top of .NET’s evolution, so that your applications using JNBridgePro and the adapters continue to work despite the changes to .NET, and will continue to work in the future.

Software Development and the Bitness Challenge

/in , , , , /

Since 64-bit processors were introduced about ten years ago, they have become the default on both desktop and server machines. With a larger addressable process memory space, wider range of representable integers, and greater floating point precision, what’s not to like? For software developers that need to support both 32- and 64-bit machines, it’s a bit complicated.

Applications written in pure managed code (whether in .NET Intermediate Language or Java bytecodes)  will typically work just fine regardless of whether they’re running as 32-bit or 64-bit processes. However many applications also contain non-managed or native code that is targeted to a specific “bitness” (where “bitness” describes the distinction between 32-bit and 64-bit qualities of a platform, process, or system). In these cases, the developer needs to be careful that the right version of the non-managed code executes when the application is run, depending on the bitness of the running process. For software vendors, like JNBridge, which produce both self-contained applications and components that are integrated inside other users’ applications, the situation becomes even more tricky – the right version of the components needs to be included in the application, and it’s a common and easy mistake for users to include the components with the wrong bitness.  The user sees an error, and we get a support call. Better to reduce the chances of an error, and everybody will be happy.

After facing these issues for a number of years, we now have a workable solution, and our new JNBridgePro 7.0 release reflects this experience. We’d like to share what we’ve learned, so that other developers can successfully address the bitness challenge.

Create a single unified installer for both 32-bit and 64-bit scenarios. Developers’ first instinct is to create separate 32-bit and 64-bit builds and distribute separate installers for each. While this may seem logical, it leads to a lot of user confusion. In our experience, users faced with the decision as to whether to download the installer for the 32-bit or 64-bit version frequently download the wrong one. When they discover this error, they have to go back and download the other version, often after engaging support. Combining the 32- and 64-bit versions into a single installer is a win for the user and a win for us.

The challenge in building a single installer is that most installer generator packages either don’t allow 32-bit and 64-bit components to be combined in a single installer that would run on either system, or if they do support it, the resulting installation is too complicated. In particular, the usual technique of combining 32-bit and 64-bit installers, and a bootstrapper, into a single installer won’t work in our case, since we want 64-bit components to be installed on 32-bit machines, too. We resolved this by creating a single 32-bit installer (that is, one that would run on both 32-bit and 64-bit machines), and fooling the installer generator into thinking that the 64-bit components were simply “content,” so that the installer generator wouldn’t reject them. The “content” is all the 64-bit components packed into a single zip file. When the installer is run, a custom action extracts the 64-bit components then removes the zip file. While there are subtleties in getting this right (Google ‘advertised shortcut’ for pointers to issues that can arise), when done correctly this approach works perfectly and yields a single installer that runs on both 32-bit and 64-bit machines, and installs both 32-bit and 64-bit components on both machines. (Why do we need to install 64-bit components on 32-bit machines? Because, while the build machine may be 32-bit, the developer may be generating 64-bit applications.)

Ensure that users can use your components to create “Any CPU” applications. “Any CPU” applications are designed to automatically run as 32-bit processes on 32-bit machines and as 64-bit processes on 64-bit machines. This is very attractive as it allows the application to take advantage of whatever platform it runs on, and suggests that the code is portable. “Any CPU” implies that the code is completely managed, but there’s nothing to prevent unmanaged code, including third-party components, from being included. We’ve encountered scenarios where a developer used JNBridgePro to create an Any CPU application on their 64-bit development machine, successfully test it there, then ran into problems in deploying the application to a 32-bit machine. Situations like this suggest that developers should develop both 32-bit and 64-bit versions of their components or applications, but this is kicking the developer’s problem down the road, forcing the user to deal with using the right version. This should be as unacceptable to the software developer as it is to the user.

In order to allow users to create and run “Any CPU” applications, we changed JNBridgePro so that the appropriate 32-bit or 64-bit components would be loaded at run time depending on the bitness of the running process. However, platform vendors don’t make this easy. We discovered that the simplest way to test bitness at run time in .NET is to check the value returned by IntPtr.Size: 4 means you’re running as a 32-bit process; 8 means it’s a 64-bit process. (Note that the .NET alternative of calling Environment.Is64BitProcess won’t work in our case, since that API is only supported in .NET Framework 4.0 and later, and our components also need to be able to run in .NET Framework 2.0 through 3.5.) In Java, simply check the value of the system property os.arch. “x86” means that it’s a 32-bit process; “x86_64” means it’s a 64-bit process. These tests allow us to load the appropriate components at run-time, thereby supporting users who want to create applications that run anywhere, even though some of our components contain 32-bit or 64-bit targeted code.

Be careful using the Windows registry. When Microsoft created 64-bit Windows, they made the fateful decision to provide separate 32-bit and 64-bit registries, accessible only to respective 32-bit and 64-bit processes. The problem arises when the registry is used to share information between applications. Information deposited by  a 32-bit application is inaccessible to a 64-bit application, and vice versa. The answer is to only use the registry for information used by a single application, and only when the application’s bitness on that machine will always be the same. Save the information shared between applications in files; do not use the registry. JNBridge used to store information in the registry, but this became a constant source of support headaches once 64-bit platforms were introduced. Now that we store information in files, not the registry, these bitness-related headaches have gone away.

In conclusion: If all the processes in the world were 64-bit processes, the problems I’ve mentioned above wouldn’t exist.  However, as long as 32-bit processes and platforms still exist and must be supported, software developers must be careful and watch out for pitfalls that can trip up users. When developers adhere to the guidelines discussed above, users’ bitness problems should disappear, to the great benefit of both users and software support teams.

Java 7 update “silently” deletes Java 6, breaks applications

/in , , /

Software updates shouldn’t do unexpected things. They particularly shouldn’t remove software other than what they’re ostensibly updating, and they shouldn’t break running applications. It’s even worse when this all happens automatically and without warning.

The other day, one of our customers, an ISV that uses JNBridgePro in one of their applications that includes both Java and .NET, told us that several of their customers had reported that their applications stopped working after the customers updated their installations of Java 7. The strange thing is that the applications didn’t use Java 7; they used Java 6. The problem was fixed by reconfiguring JNBridgePro on those machines to point to Java 7 rather than Java 6. Our customer asked us whether JNBridgePro had problems with this update, or with Java 7. We answered that there should be no problem: JNBridgePro works fine with both Java 6 and Java 7, including the latest updates.

Something odd was going on, so we started digging deeper. Running the auto-installer for the new Java 7 update, we saw the following screen, with the relevant message buried in it:

Then we found the following notice on the Oracle website:

About the Java 6 Auto-Update to Java 7

Oracle will start auto-updating Windows 32-bit, Java Runtime Environment (JRE) users from JRE 6 to JRE 7 in December 2012.

The Java auto-update mechanism is designed to keep Java users up-to-date with the latest security fixes. To achieve this goal Windows users that rely on Java’s auto-update mechanism will have their JRE 6 replaced with JRE 7.

In December 2012 Oracle will start to auto-update a sample of users from JRE 6 to JRE 7 to evaluate the auto-update mechanism, user experience and seamless migration. Oracle will then start auto-updating all Windows 32-bit users from JRE 6 to JRE 7 with the update release of Java, Java SE 7 Update 11 (Java SE 7u11), due in February 2013.

    • JRE 7 has been the default version on Java.com since April 2012 and is now being used by millions of users.
    • As we did when JRE 5 was replaced by JRE 6, we will auto-update users of the older release to the newer version of Java.
    • As always, all users are encouraged to update to the most recent Java versions available for public download.
    • In February 2011 Oracle announced the End of Public Updates for their Java SE 6 products for July 2012. In February 2012 Oracle extended the End of Public Updates for 4 months, to November 2012. See:

• Oracle is now extending the End of Public Updates again for 4 additional months to provide developers and users with additional time to migrate to Java 7. The last publicly available release of Java 6 will be in February of 2013 with the release of Java SE 6 Update 39 (Java SE 6u39).

Java 6 End of Public Updates extended to February 2013

(Emphasis ours.)

This is absolutely astonishing. Oracle has decided that, in order to fix extensively-reported security problems, they will not only update Java 7 (their latest version of Java), they will also completely delete a completely separate product. Yes, Java 6 is a separate product from Java 7. They can be installed side-by-side, and many users have both Java 6 and Java 7 installed on their machines. Some of their applications depend on Java 6, and others might depend on Java 7, and these dependencies are typically hard-coded or configured to point to the correct, and different, file locations. Can you imagine if Microsoft released an update to .NET 4.0 that also removed .NET 2.0? This is just as serious.

Worse, it appears that they are taking it upon themselves to replace installations of Java 6 with Java 7 even if the users have only Java 6 on their machines.

How is this different from, say, Microsoft updating Office by replacing one version by another? That’s an update-in-place, so hard-coded paths will often still work. Even so, updating one version of Office to another likely won’t involve an auto-update, but rather an explicit re-installation, and one would expect dependencies to break. Java 6 and 7, on the other hand, are side-by-side installations, and one doesn’t expect an update to one to affect the other in any way.

Let’s look at this from Oracle’s point of view. The security holes that they plugged in Java 7 likely also exist in Java 6, and they have stopped providing new updates to Java 6. Why not replace Java 6 with Java 7 and fix these problems?

This strategy might make sense for less sophisticated users who only use Java inside their browsers. They likely do not know which version of Java they have, or even if they Java at all. In this case, it makes sense to fix the problem by updating the Java installations, so that machines aren’t infected with malware by visiting rogue websites.

However, most of our customers aren’t using Java in their browsers. Their Java is running on servers, or in self-contained desktop applications that, if they connect to the Internet, only connect to specific sites. Their applications depend on specific versions of Java, or on Java files being in specific places. JNBridgePro’s shared memory mechanism, in particular, depends on an absolute path to a specific jvm.dll, but that’s not the only case where dependencies like this occur. With their update, Oracle has silently pulled the rug out from under many running applications.

Why do I say “silently”? Even though the update installer mentions that Java 6 “might” be removed, and the notice on the website says it “will” be removed, very few people will read the text in the installer; they will likely just click through it, since nobody expects a Java 7 updater to remove Java 6. And almost nobody will read the notice on the website unless they are specifically searching for it.

One could say that IT shops should turn off automatic updates, and apply updates in a controlled process after extensive testing. That’s true, but clearly auto-updates can still happen; it’s not reasonable to assume that all business users have sufficient IT support. After all, it happened to our customer’s customers. It’s also the case that a situation like Java 6 being removed in a Java 7 update might not be found in a controlled test, since most such tests will only try to see whether applications that use Java 7 will be affected. To make matters more difficult, the mechanism for turning off automatic Java updates isn’t obvious.

If you find yourself with a broken application that uses JNBridgePro and Java 6 after updating Java 7, here’s what you can do:

  • You can reconfigure your application (and particularly the JNBridgePro component) to use Java 7 rather than Java 6. JNBridgePro will have absolutely no problem with Java 7. Whether your Java code will work with Java 7 is something that you will need to determine yourself.
  • You can go to the Oracle Java website and download and reinstall Java 6. Then, you’ll be back where you were.

Finally, you should strongly consider turning off automatic Java updates. As I said it isn’t immediately obvious how to do this, since the Java control panel, by default, doesn’t display the Update tab that contains the switch that turns off updating. The Update tab only appears when the control panel is run as administrator. You can turn off the auto-update switch as follows:

  1. In Windows Explorer, navigate to your JRE’s bin folder (for example, C:Program Files (x86)Javajre7bin, although it might be different on your machine).
  2. Once you’re there, find javacpl.exe. Right-click on it, and select “Run as administrator.”
  3. Inside the control panel, you can now see the Update tab. Select it, then uncheck the “Check for Updates Automatically” checkbox.

The control panel will ask if you really want to do this. Trust me, you do. Then click on the OK button.

Note that if you do this, it’s your responsibility to make sure that your Java installations are up to date, and that you engage in good security practices. You will need to keep track of the latest Java security problems and the latest updates when they become available, and you can download them from Oracle’s Java site. The downloaded updaters will only update the specific Java versions, and they won’t pull the rug out from under you by removing completely different versions of Java that your software might depend on.

In summary, Oracle’s latest automatic Java update is dangerous and irresponsible because it “silently” removes software other than the software it ostensibly updates, thereby breaking running code. By all means update and secure the Java running inside browsers, but leave our server and desktop software alone.

Groovy-to-.NET integration

/in , , , /

Lately, much of the action in the Java world has been in the development and use of non-Java languages that run on the JVM. That’s why we were pleased to hear from a customer who wanted to use JNBridgePro to call .NET assemblies from code written in Groovy.

For those of you unaware, Groovy is a dynamic language that runs on the JVM. Groovy classes compile to Java binary .class files, and Groovy code can call (and be called from) any conventional Java class. In our customer’s case, they wanted to call .NET classes from Groovy, which really meant calling proxies. Since proxied .NET classes are just Java classes, everything should just work, and it did.

It’s really easy to illustrate how this is done. Let’s assume we have a very simple test class written in C#:

namespace GroovyTestDotNetSide
{
   public class SimpleObject
   {
      public SimpleObject(int i)
      {
         Console.WriteLine("In SimpleObject.ctor: value supplied is " + i);
      }
   }
}

First, we proxy it and generate a proxy jar file proxies.jar. Now, if we create a Groovy project and include proxies.jar in the build classpath, along with jnbcore.jar, bcel-5.1-jnbridge.jar (all of which would be included in any Java-to-.NET project using JNBridgePro), and groovy-all-1.7.5.jar (or something similar, depending on which version of Groovy is being used), we can write Groovy code to instantiate SimpleObject:

import GroovyTestDotNetSide.SimpleObject
import com.jnbridge.jnbcore.DotNetSide

class SimpleTest {

   static main(args) {

   // set up JNBridge
   DotNetSide.init(args[0])

   def simpleObject = new SimpleObject(3)

   println "Done!"
}
}

Just as in a conventional Java-to-.NET project, you need to initialize the Java side through a call to DotNetSide.init(), supplying the path to the Java-side properties file, or an equivalent Properties object. Once that is done, you can make any valid call to a proxy. In this case, we instantiate SimpleObject, but we can also call static or instance methods of SimpleObject, or access SimpleObject fields or properties or events.

Once the project is build, you will have a binary file SimpleTest.class, and you can run the application in the usual way (assuming all the jar, .class, and .properties files are in the current folder):

java -cp “proxies.jar;jnbcore.jar;bcel-5.1-jnbridge.jar;groovy-all-1.7.5.jar;. ” SimpleTest props.properties

The properties file can configure for tcp/binary, http/soap, or shared memory; if you are using tcp/binary or http/soap, you will or course need to run a properly configured .NET side.

As you can see, this just works in exactly the same way you’d expect if you were using Java.

While we have not yet tried it, interoperability with Groovy should also work in the .NET-to-Groovy direction. Similarly, JNBridgePro should also work when integrating .NET with other JVM-based languages like Scala, JRuby, and Jython.

Are you thinking about using JNBridgePro with JVM-based languages other than Java? If so, let us know in the comments or by sending us email at info@jnbridge.com.

Customer questions answered: Cross-platform method overrides in JNBridgePro

/in , /

Here’s another interesting question from the support inbox.

Let’s say that you have a .NET class that contains a virtual method, and you want to override it in your Java code. The immediate answer would seem to be to proxy the .NET class, then write a Java class that extends the proxy class and override the method in the Java subclass. The problem is that while this will certainly override the method when the Java class is accessed from Java code, if the Java object is passed back to the .NET side – for example, as an argument in a method call – the new Java method won’t be seen; any calls to the virtual method will be handled by the original .NET class’s method.

Overrides are not yet directly supported by JNBridgePro, but there is a way to work around this issue and allow the underlying .NET code to see the Java-based override method, through the use of callbacks. Note that while this example assumes a Java-to-.NET project, the equivalent thing can be done in .NET-to-Java projects.

Let’s say that you have a C# class:

public class C
{

public virtual int myVirtualMethod(int i)
{

// code goes here

}

}

You will need to write some additional C# code:

public delegate int OverrideMethod(int i);

public class C2 : C
{

public OverrideMethod overrideMethod = null;

public override int myVirtualMethod(int i)
{

if (overrideMethod == null)
{

return base.myVirtualMethod(i);

}
else
{

return overrideMethod(i);

}

}

}

The class C2 must be a concrete class — that is, it cannot be abstract. This is important: you must be able to instantiate it, or you will see a different problem.

If you don’t have access to the C# source code so that you can modify the original dll, place C2 in a new dll that you create, and which you include in your application.

Then, proxy C, C2, and OverrideMethod, and make your new Java class extend C2.  As part of the new Java class’s constructor, create and register a callback for overrideMethod:

public class MyOverrideMethod implements OverrideMethod
{

public int Invoke(int i)
{

// the override code goes here

}

}

public class J extends C2
{

public J()
{

super.set_overrideMethod(new MyOverrideMethod());

}

}

Now, the overrides should work as expected.

Do you have a question about how to do something using JNBridgePro? Contact us at info@jnbridge.com.

Customer questions answered: Handling optional parameters in JNBridgePro

/in , /

We received a support question recently concerning methods in .NET with optional parameters, and how to call them from Java. This is something that I think would be of interest to a number of our users.

If a method has optional parameters, they can be left out of the arguments when the method is called. For example, in the method

Microsoft.VisualBasic.Collection.Add(Object Item, string key, Object Before, Object After),

the last three parameters are optional and can be omitted. Optional parameters are most common in Visual Basic, although they also appear in C# starting with C# 2010. They can be used in methods, indexers, constructors, and delegates.

The original support question asked how one would call Collection.Add() when one wanted to leave out one or more of the optional parameters. When Collection.Add() is proxied, only the four-parameter version is proxied. Making the call with only, say, two parameters leads to a compilation error.

In order to know what to do when calling methods with optional parameters from Java, it makes sense to first understand what is really happening when such methods are called. If a method is called without an argument for an optional parameter, a default value is passed in place of the missing argument. The default value is chosen according to the following rules:

  • If the parameter is of type Object, the default value is Type.Missing
  • If the parameter is any other reference type, the default value is null
  • If the parameter is a value type, the default of the particular value type is passed

In the case of Collection.Add(), the full four-parameter version of the method is always called (it’s the only one that actually exists), and the compiler automatically and transparently inserts default values for the missing arguments.

Knowing that, it’s easy to see what to do when calling such methods from Java. Call the full-parameter version of the method (which is what has been proxied), and use the default values for any parameters whose values you ordinarily wouldn’t pass. In the case of Object parameters, pass Type.Get_Missing() – System.Type is always proxied, and Missing is a property, so it’s accessed using its getter method. Note that since the proxied Type class is in the System.* namespace, you’ll need to do something special to avoid compilation errors – see the knowledge base article here for more information.

Do you have a question about how to do something using JNBridgePro? Contact us at info@jnbridge.com.