Blog

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.

Navigating Product Support on Windows 8

Plenty has already been written about the pros and cons of Windows 8’s new Metro interface and Start screen. We don’t plan to rehash that here, but we are starting to think about how we will support it.

Prior to Windows 8, the users have had access to the Start menu, and we’ve made good use of it. There are multiple subfolders under the JNBridgePro folder in the Start menu that point to files like demos, documentation, and Java EE configuration guides. It’s not uncommon for us to refer a user to something like Start->JNBridge v6.0 ->Using JNBridgePro with Java EE->Using JNBridgePro with IBM Websphere. However, that’s not an option with Windows 8, Metro, and the Start screen. The menu is no longer available.

So what are our options?  The Start screen only shows the top level items that the installer would have added to the menu, so the document in question wouldn’t appear on the Start screen anyway. Even if it did, what would we tell the user? “Scan the Start screen until you find ‘Using JNBridgePro with IBM Websphere”? That would be very inefficient.

I suppose there are two options.  One would be for the user to do a search (using the right-side Search charm) for “Using JNBridgePro with IBM Websphere” or some substring. Another method would be to tell the user to go to the desktop and then to look for <JNBridge installation folder>\demos\J2EE Examples\WebSphere6ExampleInstructions.pdf. Neither of these approaches seem particularly user-friendly.

If you’re a software developer preparing a release targeted toward Windows 8, what are you planning to do?  And if you’re a potential Windows 8 user, what would you expect to see in a situation like this?

Build 2012 Recap

We were in Redmond last week for the Build conference, where Microsoft offered deep dives into their latest technologies. Unlike last year, where the emphasis was on in-depth looks at lower-level technologies like Windows RT, .NET 4.5, and Windows 8 internals, this year’s conference concentrated on higher-level application-oriented APIs like Microsoft Account (formerly Windows Live ID) and Windows Store, as well as more peripheral (to us) technologies like Windows Phone 8. In fact, if we had seen the list of sessions in advance, we might have decided to skip the conference and watch any relevant sessions online (although it was nice to receive the Surface RT, Nokia Lumia 920, and 100GB of SkyDrive capacity that all attendees received). Even so, there were a number of interesting sessions that were relevant to our work on interoperability. (All Build sessions can be seen here: http://channel9.msdn.com/events/build/2012.)

There was an interesting session that unveiled details of Microsoft’s previously announced Hadoop on Windows Azure offering (now called HDInsight). Since the offering has been by invitation only, there haven’t been too many details. It’s interesting to contrast Microsoft’s approach to Hadoop/.NET integration, which uses .NET streaming but conceals it with the artful use of wrappers, with our approach of direct API calls through JNBridgePro (here and here). Each approach can be useful in certain situations.

Microsoft offered more details on their new Windows Azure Virtual Machines, which brings to Windows Azure the capabilities already found in Amazon’s EC2. Microsoft claims advantages over Amazon’s offerings, particularly in the areas of administration and automation. For us and for our users, this is interesting because it makes it even easier to create applications that use JNBridgePro and deploy them to Windows Azure. It had been possible, but there were a number of complexities in setting up and starting the applications in the cloud; now it’s as easy in Windows Azure as it’s already been with Amazon EC2. In addition, Microsoft will be offering virtual machine images containing BizTalk Server 2010 R2 CTP, and you will be able to use JNBridge’s JMS adapter for BTS with those images.

A talk on the evolution of .NET covered both the history of the platform, including all of the earlier milestones, and possible future directions in which the platform can go. The speaker made the very interesting point that the typical PC of 1998 (when the .NET project began) or even 2000 (when it was unveiled) is very different from the typical PC of today, in terms of processing power, memory and storage, user interface, and connectivity, and any future .NET implementations will need to reflect that. We can only wonder what that will entail, but it’s encouraging to learn that Microsoft still considers .NET to be an essential platform for their future offerings.

One of the more surprising things we learned had to do with Windows Phone 8, which we really hadn’t been tracking, since it didn’t seem relevant to our mission. Windows Phone 8’s runtime is actually a version of the .NET CLR called CoreCLR, which is really based on the existing SilverLight CLR. We haven’t supported SilverLight, both because of its slow adoption, and because it has been constrained in what it can do, but we were interested to learn that in response to requests from developers, the CoreCLR will allow Windows Phone 8 applications to access existing native (read C++) gaming engines. Since Java Runtime Environments are also native C++ libraries, does that mean that a JVM can be hosted in a Windows Phone 8 app’s process? If so, it might be possible to support shared memory interoperability in Windows Phone 8 applications. It’s certainly something we’ll be looking into. Will it be possible to do something similar in Windows 8 “Metro” apps? That remains to be seen.

Did you attend Build, or watch sessions online? If so, did you see something that you’d like to call our attention to? If so, please let us know in the comments.