Finding Bugs in Java Native Interface Programs Requires Research

Kondoh San and Ondera San from IBM Research Tokyo outline in a research paper some techniques to find bugs in JNI programs. Read their research! JNI is itself not intractably complex to program but some of the problems it can throw up in real systems can seem intractable. Also read up on IBM Research Tokyo. Research areas include Systems Software and Microdevices.

Sun's Bloggers Get Bored of Blogging on JMX (And who can blame them)?

JMX is a monitoring technology. JMX is part of Java platform from J2SE 5.0. JMX can be used in conjunction with jconsole. Also check out Daniel Fuchs blog on JMX and SNMP (though lately - and to his credit! - he seems to have lost interest in it). A fundamental concept of the JMX API (which I think of as Java Narnia) is managed beans or "mbeans". Creating an mbean is as simple as creating an interface and an implementing class where each of the class methods represent an operation on the mbean - what could be simpler? The interface for the implementing class must be the name of the class with the suffix MBean added to it. It sounds very silly. That's because it is. Things become more interesting maybe when we start to talk about JMX agents.

The Sceptics Guide to Spring 3.0

The 50MB download of Spring Framework 3.0 has begun. More comprehensive REST support and a codebase fully updated for Java 5 await. What more could a Java aficionado desire?

Want to pry into the mind of a Spring-meister? Don't ask me, let Rod Johnson be your guide. Spring feels so much like the next JBoss. I'm not saying Spring and JBoss are equivalent, their completely not, but the whole upstart, hyped-up nature of Spring is just so reminiscent of JBoss, which points hard to its inevitable obsolescence. Given this outlook, why even bother trying to learn Spring? Well, because it is a "thermometer of our times" and the software concepts in Spring may well find life in some future products so the learning effort, we might assert, will not be entirely wasted. If we can overcome this emotional antipathy towards Spring, and overlook its incongruous rhyming nature with another, very familiar Java toolkit (Swing) we might be able to make some headway in terms of learning this technology.

To comprehend the incredible complexity of Spring, you need to first walk the path of dependency injection and "inversion of control". Nobody likes jargon, least of all pretenious, newly-coined terms like "inversion of control", but alas, one needs to have an acquaintance with aforementioned terms as a prerequisite to proceeding with Spring. It is just one of those rites of passage. Think of it as a bridge that once crossed will render the perceived complexity of Spring powerless.

Dependency injection is a specific example of "inversion of control" (which is a very vague general term that can be used for a lot of code patterns). Fowler prefers the term dependency injection in order to be more clear. Dependency injection, to put it crudely, is storing settings in an xml config file which can be read into a Java object (I will not use the term POJO as it sounds ridiculous imho) which is then used to initialise other objects. Dependency injection is no different from what you see in any software application that has configuration information. It's just another word for "config".

Dependency injection is like any other design pattern, a fancy name for something programmers have been doing all along.

Eclipse RCP

There is a slew of awesome commercial RCP applications available, check out the online application inventory. Among them is SpiderMonkey for online SEC filings.

Here is a tutorial to get started (by Ed Burnette).

"Linking" to Third Party Jars in Eclipse (the Correct Way using Java Build Path)

How

Select Project->Properties in Eclipse.

Alt-P (Project Menu) -> Pause -> P (Properties)

Select "Java Build Path" from section on left. Choose "Libraries" tab and "Add External Jars".

Does it make sense to talk about "linking" to a jar

We are just referencing code, but then again, isn't that what linking is.

Creating Jars in Eclipse

Frequently we may wish to build an open-source Java library and export it as a JAR. Asssuming we have created a new workspace in Eclipse, e.g. Apache Commons, composed of multiple projects e.g. Lang (which we have imported into Package Explorer using "Create Java Project from Existing Ant Build File") we can create a JAR for the Lang project as follows:

1. Right click on Project in Package Explorer
2. Select Export..
3. Select Java/JAR file
4. Enter a name for the file e.g. project name and version number, like commons-lang-2.4.jar

Once the JAR is built (by default it will be in the directory for the current workspace), you can inspect the file as follows:

jar -tvf commons-lang-2.4.jar | grep class | wc -l

will return a count of 127 class files.

Apache Commons - A Staple in the Java Open Source World

Apache Commons is a staple in the Java open source world.

commons-beanutils.jar (contains everything to do with beanies)
commons-collections-3.2.1 (contains apache commons collections)
commons-lang-2.4.jar (contains additional classes for java.lang)
commons-logging.jar
commons-CLI.jar (command-line parsing)

There is also a Commons sandbox of projects-in-the-making. Amongst these are:

CLI2 - redesign of Commons CLI
CSV - module for reading/writing CSV
OpenPGP - for signing and verifying data using OpenPGP
Javaflow - to capture the state of an application. Means of "checpointing" an application using the idea of "continuations" borrowed from Scheme.

Commons dormant contains stuff no longer maintained, like Clazz for introspection, and Cache for object caching services.