JNBridgePro and Visual Studio 2010

Something cool from the JNBridge labs. What you’re seeing below is the JNBridgePro plug-in running inside Visual Studio 2010. When VS2010 is released, we’ll be ready for it.


JNBridgePro in VS2010

JNBridgePro and Windows 8: It already works

We were at Microsoft’s Build conference in Anaheim a few weeks ago, where they unveiled their upcoming Windows 8 operating system.  In case you hadn’t caught the news, Windows 8 contains two distinct user experiences: a traditional “Desktop” experience which resembles Windows 7, and a new, touch-centric “Metro” experience.  The Desktop experience allows you to access the full .NET Framework as before; Metro applications run in a much more restricted runtime environment.

We’ve spent some time with Windows 8, and we’re happy to report that JNBridgePro, as it’s currently released, already works just fine with Windows 8 in desktop mode. So, if you’re already using JNBridgePro and want to move your application to Windows 8, or to create a new application for the Windows 8 desktop, JNBridgePro is as easy to use as always.

We’re also happy to report that the JNBridgePro plug-in for Visual Studio will work with the upcoming Visual Studio 11 Developer Preview with only minor changes, which will be incorporated in an upcoming JNBridgePro release.  This means that JNBridgePro will be ready for the new Visual Studio by the time VS 11 is released, and likely sooner.  In the meantime, if you want to use JNBridgePro in conjunction with VS 11 development, we recommend using the standalone proxy generation tool.  If you’d like to be a tester for the JNBridgePro plug-in for VS 11, please contact us.

As might be expected, Metro-style development, along with the more restrictive WinRT and new .NET Metro profile, offer a few challenges.  During the run-up to the Windows 8 release, we will be addressing those challenges.

We’d be interested to know whether any customers or prospective customers are planning to produce Metro apps, and whether they anticipate building .NET/Java interoperability into those applications.  If you are planning to produce such applications, we’d like to hear from you, and work with you, at this early stage in the Windows 8 product cycle — please contact us.

Over the coming months, we’ll periodically post new blog entries discussing interesting technical aspects of Metro and WinRT, as they affect interoperability.  We expect to learn a lot during this process, and we look forward to sharing it with you.

JNBridgePro and the new Windows 8 and VS11 bits

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.

Announcing JNBridgePro v6.1

We’re excited to announce the release of JNBridgePro v6.1. The new version connects Java and the .NET Framework both on the ground and in the cloud, and has all the features of previous versions of JNBridgePro, plus the following significant new features:

  • We’ve added support for the new Visual Studio 2012 and .NET Framework 4.5. The JNBridgePro Visual Studio plugin will now work just as well in VS 2012 as it does in VS 2005, 2008, and 2010.
  • We also now support all versions of Eclipse from version 3.2 up through 4.2, the latest version.
  • JNBridgePro now supports cross-platform access of protected object and class members. Previously, only access of public members was supported. This will provide more extensive support for extending Java or .NET classes on the other platform.
  • Java code can now call .NET methods that contain ref or out parameters, thereby making even more .NET code accessible cross-platform. While this was previously possible through a workaround, it can now be done directly.
  • The JNBridgePro installers are now signed. This will help enterprise users whose IT organizations’ policies require signed installers.

The new JNBridgePro v6.1 is available immediately for download.

The full announcement can be found here.

Software Development and the Bitness Challenge

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.

Build 2013 Impressions

I recently came back from Microsoft’s Build 2013 conference in San Francisco, where Microsoft’s latest technologies are introduced to developers.  Much of the conference was devoted to technology related to Metro/Modern Windows/Windows Store apps, and also to Windows Phone, neither of which are relevant to JNBridge’s mission.  However, there were a few things that caught my eye, and which are worth mentioning.

First, Windows 8.1 (formerly, Windows Blue) was unveiled.  It’s definitely an improvement for desktop users.  We currently run Windows 7 on our development machines and do our Windows 8 tests on virtual machines.  While nothing I saw at Build regarding Windows 8.1 will change that, it’s definitely getting closer to being a system that I would feel comfortable using every day.

Visual Studio 2013 was introduced during the Build keynote, and I was quite impressed with the new code navigation features, including the enhanced scrollbars and the look-ahead capability that allows developers looking at a method call to open a mini-window containing the text of the called method.  I can certainly see using these features in our future development.

It appears that the JNBridgePro Visual Studio plugin should work just fine with VS 2013, although we realize that this is a very early version of the software, and things could change.  We will certainly be tracking that.  Similarly, the new version of the .NET Framework that will be released with VS 2013 seems to run JNBridgePro just fine.

Finally, given our interest in interoperability issues relating to Hadoop, we were intrigued to see this talk on Azure HDInsight.  We’ve been thinking of new ways in which JNBridgePro can be integrated with Big Data applications, and the talk suggested some scenarios that we’ll be working on in the coming months.

Were you at Build, and, if so, did you see anything interesting related to interoperability?  Let us know.

Forcing Visual Studio 2013 support for the WCF JMS Adapter

The JNBridge JMS Adapter for .NET is dependent on the Microsoft Windows Communication Foundation Line-Of-Business Adapter SDK. The SDK is released with versions of BizTalk Server, not Visual Studio. This year, BizTalk 2013 was released in the spring, but Visual Studio 2013 was released this fall, so the current version of the SDK doesn’t support VS 2013.   While it would be easy to tell our customers  interested in integrating JMS into .NET that they must use VS 2012 or 2010, it doesn’t provide much for the customers using VS 2013.

For the new release of the JNBridge JMS Adapter for .NET, the solution was for us to explicitly install and configure the WCF LOB SDK for VS 2013, as part of the adapter installation. This consists of four assemblies and registry entries into the Visual Studio registry hive, HKLMSOFTWAREMicrosoftVisualStudio12. Along with the work inherent in getting the SDK to support VS 2013, JNBridge must also explicitly support the SDK for our end-users.

Couldn’t we just wait until the SDK was refreshed by Microsoft? We could, but the point is that by installing and supporting the SDK now, the customer, JNBridge and Microsoft all benefit.