Java News from Thursday, November 23, 2006

Petr Nejedly has released Insane 1.11, an open source tool for performing postmortem memory leak analyses. According to Nejedly,

When doing performance work, one often faces questions like "how big is this structure", "what happens if I register one more thing here" and so on. When chasing some hard-to-reproduce memory leak, one often needs to come to a long-running full-heap application and analyze its heap without restarting it. There are several approaches to these problems, but none of them seemed optimal:

• Profiling structures using profiler needs complicated instrumentation and is hard to perform automatically from memory regression tests.
• Long-term running the application in the instrumented environment significantly reduces its performance and you need to prepare instrumentation in advance.

This lead me to the development of the Insane technology, quite simple solution for reflective inspection of heap from inside of running VM.

Where did the name came from? OK, I consider it quite insane to introspect the whole heap from inside of the application doing the introspection. I consider dumping the whole heap image to a XML file hundred megabytes long even more insane. And finally, how would you call a person trying to parse that XML file?

Sun has posted the early draft review of JSR-246 Device Management API to the JCP. According to the draft:

JSR 246 Device management API is an optional package for the Java Micro Edition (JME). It provides a generic interface to the Device Management implementation in the device, to enable device management via natively implemented Device Management protocols. The API provides the possibility for Java applications to access parameters that can be managed remotely using the Device Management protocols, and that are physically stored by the implementation. It enables the use of the underlying device management implementation. It also provides mechanisms to control additional functionality in the Device Management subsystem, such as triggering management sessions, notifying the application about DM Tree changes etc.

The API's focus is on the widely available Device Management protocols SyncML/OMA DM and WAP/OMA Client Provisioning. The API is a high level API that provides a common set of management commands that are available in management protocols.

Sun has released the final draft of JSR 208, Java Business Integration (JBI). According to the spec,

Enterprise application integration (EAI) and business-to-business integration (B2B) solutions have traditionally required the use of non-standard technologies to create functional systems. This has required end users to either “lock in” to a single vendor of such technologies, or create their own. Each approach has disadvantages. No single vendor can cover the vast functional space of EAI and B2B (consider the thousands of applications and protocols to be supported). This leaves users of integration technologies in the uncomfortable position of selecting less than ideal solutions to their integration problems, and paying dearly for them.

Java™ Business Integration (JBI) seeks to address this problem by creating a standards-based architecture for integration solutions. This infrastructure allows third-party components to be “plugged in” to a standard infrastructure, and allows those components to interoperate in a predictable, reliable fashion despite being produced by separate vendors. It is anticipated that this ability to interoperate will create a multivendor “ecosystem” which will give rise to large pool of integration-related technologies that can be sourced by end users. In addition, this ecosystem will foster new innovations in integration technologies, since it will permit innovators to concentrate on a particular technology or problem area, without having to worry about providing all the other pieces needed to build a complete integration solution.

Every integration problem is unique; an appropriate combination of JBI-compliant components will provide a solution that is sized appropriately to the problem at hand. By avoiding lock-in to a particular vendor of integration technologies, the user is free to choose components that provide the particular functions that he or she needs, and be assured that a functional integration solution can be assembled from those pieces.

In the past, attempts to compose third-party components into systems that have the attributes required of enterprise systems have not been very successful. JBI addresses this by adopting a service-oriented architecture (SOA), which maximizes the decoupling between components, and creates well-defined interoperation semantics founded on standards-based messaging. The SOA approach creates many other benefits that are applicable to enterprise integration solutions.