Today we’re excited to announce JNBridgePro 7.0, with two new major features: support for Mono, and the elimination of “bitness” issues. These improvements will enable users to expand the reach of their applications, and simplify the development and deployment process.
JNBridgePro 7.0 can now run on Mono
One of the most common questions about JNBridgePro that we’ve had to say no to is “Can it run on Mono?” Starting today with JNBridgePro 7.0, the answer is yes. As a user of JNBridgePro, you’ve created applications that combine .NET and Java code, where the .NET code runs on Windows machines, and the Java code runs in a JVM. Now with JNBridgePro 7.0, the .NET code can also run on Linux machines, using the Mono runtime. (As always, the Java sides of the applications can run on any platform that can run Java.)
Why use Mono? Here are four examples:
- You want to move your existing .NET & Java application onto a commodity Linux server for business or technical reasons.
- You want to create greenfield applications on Linux platforms. In this example, you can build an application that combines an ASP.NET Web application with Java EE code running on an application server, and have the entire result run on a Linux server.
- You want to move your .NET & Java application to a Linux-based IaaS cloud provider.
- As an ISV, you want to expand your.NET&Java application’s footprint beyond Windows to support for Linux:
No code changes are necessary to move your .NET & Java applications that use JNBridgePro from Windows to Linux, just some possible configuration file changes, so your existing applications will just work.
JNBridgePro 7.0’s current Mono support is on Linux, on the Ubuntu, openSUSE, and Debian distributions currently supported by Mono, as well as on Windows. We’re considering extending JNBridgePro’s Mono support to additional platforms, based on customer feedback. JNBridgePro will work on Mono in both the .NET-to-Java and Java-to-.NET directions using the TCP/binary communications mechanism, and in the .NET-to-Java direction using the HTTP/SOAP communications mechanism. Future releases will fill in the gaps in available communications mechanisms, so you will be able to use any mechanism on any platform.
Unified 32-bit and 64-bit
Ever since we’ve introduced support for 64-bit platforms, customers have sometimes been confused by “bitness” issues. In JNBridgePro 7.0, we’ve eliminated bitness-related confusion by unifying our 32-bit and 64-bit distributions into a single release.
First, customers no longer need to decide ahead of time whether they need 32-bit or 64-bit JNBridgePro – now, there’s just a single installer containing the components and tools that will work for you regardless of whether you’re creating 32-bit or 64-bit applications. That means that there will be no more situations where you first download the 64-bit JNBridgePro installer, then need to go back and download the 32-bit version.
Second, you can now create “Any CPU” applications that work with the shared-memory communications mechanism. “Any CPU” applications will run as 64-bit processes on 64-bit systems, and as 32-bit processes on 32-bit systems. Since the JNBridgePro shared-memory components contain native code and come in 32-bit and 64-bit flavors, there used to be situations where users would create an “Any CPU” application using shared memory that ran fine on a 64-bit machine, but that threw an exception on a 32-bit machine (or vice versa). In such cases, the user would have to go back and create separate 32-bit and 64-bit builds using the proper shared memory components. Now, you can create a single “Any CPU” build that contains both the 32-bit and 64-bit shared memory components, and the correct ones will be used depending on the bitness of the currently-running process. This increases flexibility in deployment, speeds up the time spend building and testing, and eliminates potential errors.
Download the new version
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.
We’re honored to included in the 2012 SD Times 100, in the APIs and Integration category. While the announcement was made a few short months ago, SD Times just came out with the supplement that profiles all the winners. The SD Times 100 names companies and organizations of all sizes who have demonstrated leadership and innovation that contributes to the advancement of the software development industry over the past calendar year. It’s great to be included among these innovative companies.
The latest 3.0.1 versions of the JMS Adapter for .NET and for BizTalk Server now support Oracle AQ. You can download them here, or take a look at the documentation for using the JNBridge JMS Adapter for BizTalk Server (pdf) or for .NET (pdf) with Oracle AQ.
Past versions of the adapters didn’t support Oracle AQ, as they relied on the standard JMS 1.1 specification, including JNDI. Instead of JNDI, Oracle AQ uses its own proprietary API. The adapters now include a JNDI scaffold, which is basically and implementation of JNDI on top of the proprietary Oracle AQ JMS calls. Also included are guidelines for configuring WebLogic.
This effort grew out of some specific requests to support the Oracle Retail Integration Bus (RIB) with .NET and BizTalk Server. Try it out for yourself, and let us know what you think!
As part of our 10 year celebration, we had this video made. It was a pretty amazing process: something like 30,000 stills got photographed and distilled into this 3.5 minute short story.
Can’t see the video in your feed? Go here: jnbridge.com/videoscribe.htm.
Share and enjoy!
Join us, we’re celebrating: JNBridge is 10 years old! And what a decade it’s been. We’re going to celebrate all year, but to kick it off we’ll start with a brief retrospective of 2002.
Ten things that happened 10 years ago:
- In January, Sun and Microsoft settled their suit. Sun had sued Microsoft for incompletely implementing the Java 1.1 standard. Microsoft paid Sun $20 million, and agreed to phase out their version of Java.
- J2SE 1.4 was released on February 6, 2002.
- Microsoft .NET Framework version 1 was released on February 13, 2002.
- JNBridgePro version 1.0 was released June 3, 2002. Version 1.0 was a one-way bridge that allowed .NET to call Java.
- JNBridgePro version 1.1 was released on August 9, 2002, it added support for J2EE.
- JNBridge’s press releases early in the year instructed the reader how to pronounce .NET (“dot net”).
- JNBridgePro version 1.2, released November 8, 2002, added “one-and-a-half-way” bridging, allowing implicit calls from Java to .NET.
- The first commercial application using JNBridgePro pulled media advertising information from a Java-based system for a search engine company. A version of that application is still in use today.
- The second commercial application using JNBridgePro enabled a financial call center to strip Java-based telephony information and pop it into .NET-based screens. That application has been performing flawlessly for almost 10 years.
- We started bidding on “Java” and “.NET” keywords in Google AdWords in September. .NET was so new that Google search didn’t know what to make of it yet, so our initial campaigns included lots of negative keywords such as fish and fishing.
- Going to 11, ten years ago the JNBridge logo looked like this. Good grief!
JNBridge has had a presence at JavaOne every year for the last six years, from giving talks to exhibiting. They’ve been good years: we’ve greatly appreciated and value the face-to-face conversations about solving real world problems. Back in 2005 we even got to hang out in Microsoft’s booth, and watch the shock and awe as hard-core Java developers witnessed fences starting to mend.
2010 brought a huge transition to JavaOne, as it morphed from its own event in the Moscone Center under the auspices of Sun to a satellite event of Oracle Open World, relegated to a rabbit warren of hotels around Union Square. Despite all the resulting downsides, we had a good show, as we got to engage with what became new customers and help them quickly solve their interoperability pain.
This year, the downsides have tipped the scale, and we decided to pull out. This decision wasn’t taken lightly — backing out of a commitment is a serious, angst-raising business around here. It wasn’t any single thing, but a whole lot of small things that pushed us away.
We don’t wish to sound snarky or petty, but little things matter, a lot. Despite signing on the dotted line to exhibit in 2011 at the 2010 show, we, like the rest of the world, were left in the dark to interpret bits of speculation in the media about whether JavaOne 2011 would even happen. When it was announced last April, we were left to discover the news on the web — somehow we’d fallen off of the exhibitor email distribution list, and we stayed off. When we finally woke up and realized what had happened, it was too late — the desirable hotels were booked, and the stress level of trying to get the team into decent housing was the final straw. This was on top of the hay pile of stuff we experienced last year. No media services: the media room was way off in the bowels of the Moscone Center, journalists and analysts either couldn’t find us or couldn’t fit the 15 minute trek uphill into their crowded schedules.
Other downsides weren’t exclusive to us, they impact all attendees. Relegating JavaOne to the outskirts of Oracle Open World forces it to be a bastard step-child — there’s no way a show of what’s now reduced to 3000 attendees can get the attention it deserves while competing for resources against a 40,000 attendee show. Many services, like extended registration hours and evening events, are that 15-minute walk away. The physical location is a rabbit warren – making both sessions and the exhibit floor difficult to find, so everyone struggles just to figure out where they are going. Gone are the chance confabs in the hall. Gone is the ability to walk up to anyone at the party and ask “so, what do you think?”, as in all probability are they are attending a very different event. We maintain that the Java community deserves better.
Finally, we recognize that we embarked upon a costly experiment some years ago. Would spending our resources and our time on trade shows be fruitful? It’s a tough and rather subjective thing to measure. In retrospect it was probably the right decision. But times have changed, and we now need to experiment with other ways to engage. Look for us in other venues in the coming months and quarters. If you have a preferred way of interacting, we’re all ears!
So, farewell JavaOne. We wish you, and the Java community, much success.
Addendum: Wayne Citrin, our CTO, will be wandering the halls the first two days. Give him a shout at @waynecitrin if you’d like to hook up.