Category: Work

A brief post where I will simply encourage you to visit Ken’s blog and read about this new Samsung cell phone that has some of our software in it.  It seems Engadget covered this same phone just last week, but they didn’t pick up on the fact that IBM’s J9 is inside as Linux for Devices managed to do.

IBM runs an internship (COOP) program called IBM Extreme Blue.  This is in addition to the regular internship (COOP) program, the difference is that the extreme blue program is the “best of the best”.  There are only a few IBM labs that host these projects, but they select students from a very broad base of students who have worked for IBM in previous work terms.

The teams are composed of 3 students focused on technical work, and 1 MBA who handles the business side of things.  Their goal is to take a concept and create a compelling business case for further investment (by IBM).  Think of this as a Start-Up on steroids – they’ve got less than 4 months to do it all.

This week all of the extreme blue students are gathered in Armonk, N.Y. where they will deliver their finely tuned pitches.  The audience will be composed of their fellow students, IBM mentors and most importantly IBM Executives.  Sam Palmisano is usually able to find time to take a brief tour of the booths that the students have setup, with a special stop at one of them for a deeper dive.

The Ottawa J9 team hosted an extreme blue project this year.  We used this to help take one of our prototype concepts further towards a complete business case.  I have to confess this is a bit of a teaser post – since I can’t disclose very much about the project.  You’ll have to speculate wildly based on the following image:

You may want to check out the video clip from the local news station that talks about the IBM Ottawa Extreme Blue expo.

Our team has a long history of hiring our COOP students, its a great deal both ways.  The students know what they are walking into, and we’re got a better idea of what they are capable of.  Even I was a COOP student for the VM team way back when.  Each of the names involved with this project are top notch students -whoever manages to hire them will be lucky (and yes, we’ll be trying to).

Good luck in N.Y. this week guys!

Well, it seems Ron beat me to the punch to blog about this – but allow me to promote the recently published developerWorks article that I had a hand in bringing to life:  Best practices for using the Java Native Interface

Here is the summary:

The Java™ Native Interface (JNI) is a standard Java API that enables Java code to integrate with code written in other programming languages. JNI can be a key element in your toolkit if you want to leverage existing code assets — for example, in a service-oriented architecture (SOA) or a cloud-based system. But when used without due care, JNI can quickly lead to poorly performing and unstable applications. This article identifies the top 10 JNI programming pitfalls, provides best practices for avoiding them, and introduces the tools available for implementing these practices.

Many kudos to Michael Dawson for his wordsmithing and persistence to make this article happen, he really deserves the lion’s share of the credit.

Ron calls out his favorite pitfall as using the wrong JNIEnv.  I’ll pick the one that makes me laugh because it is sad but true:  Choosing the wrong boundary between native and Java code – believe it or not there was a real world example that motivated the sample code.  The customer had decided to go for a “pure java” solution for their embedded application, so the minimal amount of native code was written – two functions that could read or write individual bits (not bytes).  While the example is outlandish, many times the integration of legacy code via JNI is done without thinking of the cost of the boundary.

Let’s discuss the picking the right side of the JNI boundary for a minute.  The NIO implementation is a good example of trying to fix file performance by keeping the data on the “right” side of the JNI boundary.  While NIO provides other functions allowing for tighter OS integration, one key performance win is due to the file data is kept in native buffers.   If you’re trying to get the data into java objects to be manipulated, you are likely defeating the performance win of NIO by forcing all that file data across the JNI boundary.  Where NIO will excel is needing to pull a bunch of data from a file and put it in another file – if you don’t need to hoist that data up into the java object space, you’ll get close to pure native performance.

Please check out the article, or at least bookmark it and send it to people who write JNI code.   Maybe we’ll see fewer false JVM bugs that turn out to be JNI related problems.