Paul Brown: Java

Mini-Review of Bitter EJB

Sat, 16 Aug 2003 20:01:19 GMT

This post (and this weblog) has a new home.

Thanks to CrazyBob, I received my copy of Bitter EJB before it hit the bookstore shelves. (As far as I can tell, I'm the Paul Brown who got a thank-you in the introduction, since I assume that it's neither the hair care products nor the football coach; now I just have to figure out why...) Thanks to my schedule, I just got around to finishing it, so I can write a review. (I acquired a fondness for How-Not-To exposition from my PhD advisor, e.g., a classic paper on the PoincarÈ Conjecture.)

How-Not-To books serve as an analog to the communal knowledgebase that early cultures must have maintained of the local berries that were poisonous or emetic, bad-tempered animals, and medicinal herbs. (Nonetheless, it's usually a nasty case of indigestion that is the best teacher.) Living off the land also requires knowing what to eat, since starvation is equally deadly, and this is the pitfall that presents itself to authors of anti-pattern or Bitter X books.

Fortunately for all involved, Bitter EJB does a good job of balancing warnings with advice. The perception that J2EE and EJB are synonymous is damaging to both, as is the related belief that using EJB is a required piece of using an application server. The biggest service that Bitter EJB performs is providing concrete criteria for would-be EJB users as to when the technology is appropriate and when it is inappropriate, how to use it and how not to use it.

Bitter EJB is definitely a worthwhile read for current and potential EJB users.

Ruminations on String Matching and Switch Statements

Wed, 18 Jun 2003 22:26:22 GMT

This post (and this weblog) has a new home.

I'm not really a grumpy old fart, but sometimes I feel like it... I can't let discussions (and some comments from Bob Lee) on string comparison go by without at least chiming in with a history lesson.

Perfect Hash Functions

My first comment is on perfect hash functions and probably lies off the beaten path for people who didn't have a hard-core CS education. A perfect hash function is pre-constructed based on a known (at compile time) set of keys and has the property that the function returns a distinct values for distinct keys. (If you plug in a string that is not part of the initial set, you could (and probably will) have a collision.) Java usage in a switch statement can be done in a non-awkward way:

public class PerfectHash {
  public static final int FRANK = f("FRANK");
  public static final int BEANS = f("BEANS");
  
  public static int f(String s) {
    ...
  }
}

And then to use it:

...
  public foo() {
    switch(PerfectHash.f(s)) {
      case PerfectHash.FRANK:
        ...
        break;
      case PerfectHash.BEANS:
        ...
        break;
    }
    ...
  }
}

The somewhat awkward part comes in generating the hash function in a convenient way (from the perspective of the IDE or build system) and this almost certainly counts as premature optimization.

The following is (probably) the easiest way to get an int to switch on:

 
  public static final int FRANK = 0;
  public static final int BEANS = 1;
  ...
  
  public static final HashMap _map = new HashMap();
  
  static {
    _map.put("FRANK", new int[] {FRANK});
    _map.put("BEANS", new int[] {BEANS});
    ...  
  }
  
  public static int f(String s) {
    Object o = _map.get(s);
    return (o == null) ? -1 : ((int[])o)[0];
  }

The use of int[] is simply a personal preference over java.lang.Integer.

The fact is that Bob is probably right most of the time — the hashcode() is a perfect hash function under many circumstances, but it will require pre-checking to ensure that there are no collisions.

String Comparison Algorithms

My second comment is about string comparison algorithms. Equality checking is straightfoward: every character must be checked at some point, and while there are various heuristics (Java hashcode, length, etc.) that can be applied to determine non-matches early, there is no way to do better than O(s.length()). For Java purposes, using the intern() function is a good idea in the context of a reasonable (i.e., known and finite) number of strings. (In fact, most modern XML parsers automatically intern() all Names (element names, attribute names, etc.). See the relevant SAX feature.) The only issues occur because there is no way to mark a function to indicate that it returns an intern'd string as opposed to a generic string.

The problem of containment is more interesting. It's a relatively old topic and is well-studied, e.g., in the classic Knuth-Morris-Pratt and Boyer-Moore from 1977 (making it older than several FiveSight employees...), which give linear O(s.length() + t.length()) (KMP) and sublinear O(s.length()/t.length()) (B-M) algorithms for searching for s as a substring of t. (Here is a comparison from the horse's mouth, as it were.) Last time I looked (JDK 1.4), the Java String.indexOf(String) function used the naive method for matching a substring which takes O(s.length() * t.length()) but requires no pre-computation. I'll have to Google for an implementation that computes and caches workers that search for specific strings.

Syscon Radio Inteview / JavaOne Impressions

Wed, 11 Jun 2003 18:26:11 GMT

This post (and this weblog) has a new home.

My interview on Syscon Radio is up. Have a listen for some of my perspectives on BPM, Java development, and XP/agile methodologies.

The JavaOne show as a whole was pleasant but, as others have already noted, felt a lot smaller than previous years and had a huge presence for mobile devices. The marketing-oriented split in the on-line presence for Java, i.e., the java.com/java.net split, has me a bit confused. On the java.com side, I understand the Mars rover tie-in, but someone will have to explain to me what Christina Aguilera and Nelly have to do with Java... On the java.net side, it is refreshing to see a change in Sun's licensing and reference implementation posture, as evidenced by the commitment to release the reference implementations of JAXB, SAAJ, and JAXRPC as royalty-free open source. (Nonetheless, the licensing terms have not yet been determined.)

I did have a chance to connect with Mike Loukides and some other friends and to pick up some scuttlebutt from the some of the vendors. The two most interesting items were some information from the JSR-112/JCA 1.5 committee (they've fixed some of the items I regarded as problems in the last public draft; the changes are not yet public...) and a great chat with Kevin Liu from SAP about pragmatic perspectives on WSBPEL and other web services choreography initiatives. (Kevin is on the WSBPEL TC and on the W3C Web Services Choreography and Web Services Description working groups as well.)

FiveSight SysCon Radio Broadcast from JavaOne

Thu, 05 Jun 2003 20:50:04 GMT

This post (and this weblog) has a new home.

I'll be out in the Bay Area for a couple of days next week, a mixture of knocking around JavaOne, doing a quick spot (11:45) on SysCon Radio on Tuesday, seeing some customers, and visiting the IBF VC 2003 conference.

Better Living and Poor-Man's Delegates through Byte Code Engineering

Tue, 03 Jun 2003 16:34:22 GMT

This post (and this weblog) has a new home.

A recent ONJava article by Steven Lewis and Wilhelm Fitzpatrick on delegates caught my interest. Delegation is the ability to treat methods as objects, and the usual application is casting an object to a delegate for one of its methods to get a uniform invocation across an enumeration or collection. Delegation should also be regarded as a potential cross-cutting concern.

Motivation

One of our developers came across a delegation-like problem working with Castor for XML binding. The classes that Castor generates all have marshal(...) and unmarshal(...) methods, but the classes don't implement any common interface that would allow the classes to be dealt with in a uniform fashion (that doesn't rely on reflection). (I don't know if this is a sin of omission or comission on their part; omission is my guess.) The desired operation would be:

((Marshallable) foo).marshal(...)

If we had delegates to work with, this wouldn't be an issue, but we don't.

Background

The overall application is a content management system for technical documentation that includes some Struts-based wizards for generating simple documents. (FiveSight Business Process Integrator and X-Hive/DB do the heavy lifting for the CMS as a whole.) The object model for the wizards is generated by a combination of Ant tasks that use James Clark's excellent Trang and some XSLT to feed XML Schemas to Castor, which then produces Java source code.

The challenge then is:

Given the Java source generated by Castor and an interface, mark the classes with the interface where appropriate. The solution should be an Ant task and integrate with the overall build.

Solution

The solution was to use BCEL to post-process the Castor-generated classes after they are compiled to byte code, as follows. I'll omit the packaging for the Ant task. (It is left as an exercise for the reader...)

The first step is to read the methods off the marker interface named iface:

String iface = _iface.replace('.', '/');
JavaClass marker = null;
try {
 InputSgftream is =
 new ClassPath(_classes.getAbsolutePath())
 .getClassFile(iface)
 .getInputStream();
 ClassParser cp = new ClassParser(is, iface);
 marker = cp.parse();
} catch (IOException ioe) {
 throw new BuildException(
 "Error searching for marker " + iface
 + " in "
 + _classes.getAbsolutePath() + ": "
 + ioe.getMessage(),
 ioe);
}if (!marker.isInterface()) {
 throw new BuildException(
 "The marker " + _iface + " is not an interface.");
}
 
HashSet methods = new HashSet();
for (int i = 0; i < marker.getMethods().length; ++i) {
 methods.add(marker.getMethods()[i].getSignature());
}

(The variable _classes is the directory containing the compiled classes for the marker interface(s).)

The next step is to scan the classes to be marked and determine if they can implement the interface. This is the fragment of code that processes the class named name from the directory base. (The directory walking code is left as an exercise for the reader...)

JavaClass jc = null;
try {
 ClassParser cp =
 new ClassParser(base.getAbsolutePath() + 
 File.separatorChar + name);
 jc = cp.parse();
} catch (IOException ioe) {
 throw new BuildException(
 "Unable to read in " + name + " from "
  + base.getAbsolutePath() + ".",
 ioe);
}
 
HashSet mtds = new HashSet();
Method[] arr = jc.getMethods();
for (int i = 0; i < arr.length; ++i) {
 mtds.add(arr[i].getSignature());
}
 
File target =
 new File(_outputDirectory.getAbsolutePath()
 + File.separatorChar + name);
 
if (mtds.containsAll(methods)) {
 ClassGen cg = new ClassGen(jc);
 cg.addInterface(_iface);
 try {
 cg.getJavaClass().dump(target);
 } catch (IOException ioe) {
 throw new BuildException(
 "Unable to dump marked class "
 + name
 + " from "
 + base.getAbsolutePath()
 + "into "
 + target.getAbsolutePath()
 + ": "
 + ioe,
 ioe);
 }
} else {
 // copy the class to the destination unaltered
}

That's it, up to packaging.

Application to Delegates

The application of this technique to delegates is straightforward: Create a one-method interface for the desired delegate, and then let the build take care of applying it to the compiled classes.

Visual Tools vs. Coding

Tue, 22 Apr 2003 12:10:43 GMT

This post (and this weblog) has a new home.

With WS-BPEL going mainstream and a corresponding upswell of interest in executable business processes, the choices between coding, modeling, scripting, and visual design are going to be presented to many potential technology adopters. There are valid arguments for any of the above with the complexity of the deliverable, the skills of the target users, and the degree of obscurity of requirements all bearing on what the "right" choice would be.

My experience has been that a mixture is best. (The maxim "One size fits none." is apt.) High-level modeling at the outset of a project to facilitate communications and extract requirements. Identification of available technology assets and some initial work in low-level Java or other languages to wrap those assets as deployable resources (e.g., JCA adapters or components for a visual design environment). Visual assembly of components and objects into processes with scripting and some light custom code to fill the gaps. In an ideal world, the executable visual artifacts are identifiable as more detailed renditions of the original high-level models and provide value as a mechanism for inspection and incremental modification.

For visual design of executable processes, the oft cited and touted benefits are strongly dependent on the objects on the canvas, the mechanisms of combination and composition, and the means of deployment. This is true as well in service-oriented architecture, where the selection and sizing of services as well as communications and wire protocols determines the level of benefit provided to the adopting organization. For web services orchestration and web services, the issues of sizing in the design environment and sizing in the execution environment coincide.

With over three years invested in building visual programming tools in and for Java, FiveSight is not new to the visual programming space as far as process execution, web services, etc. goes, but in the grand scheme of things, we are absolute newbies. The reason being that the concept of visual programming is not at all new. The first dataflow tool dates from 1965(!), and reasonably useful languages, e.g., ProGraph have roots back in the early 1980s.) From the time that we launched the first version of our product in early 2000 to present, we've worked our way through a variety of different paradigms (data flow - like an electric circuit, control flow - like a flowchart), levels of representation (more coarse, more fine), fanciness of wizards, and different contracts for types and objects that can be used in the design environment. Throughout, our experience has been that there is an economical object size for visual widgets that varies by the customer and project. In some cases, it's individual operations against an SAP implementation, in others it's high-level operations against a content management system (check-in/check-out of a document, approval/sign-off), in others it's wrappers around scripting constructs such as XSLT or XQuery. Ensuring that a product provides a good variety of starting points and hooks for extension at different levels is the responsibility of the vendor in designing the software. Ensuring that a project selects and works with econonmically-sized objects for its goals is the responsibility of training and implementation support.

For the low-level developer, visual tools are also useful as a point of aggregation for information derived from an existing or evolving codebase. One of the coolest visual tools for Java that I've seen recently is Code Logic from LogicExplorers (although an evaluation version that's usable for 5 minutes at a time isn't much of an evaluation version). Small Worlds is another personal favorite. I don't expect to be programming a la Tom Cruise in Minority Report anytime soon, but I wouldn't mind.

A Thought on Software for Software Development

Sat, 19 Apr 2003 03:55:53 GMT

This post (and this weblog) has a new home.

The maturation and growing ascendency of Maven in the Java open source community and recent JDJ article by Franz Garsombke have me thinking about build systems and more generally about software development process and quality. (Never mind my recent displeasure with JDJ for dropping the integration category of the "Reader's Choice" Awards at the last minute and moving our business process integration product into the application server category without so much as a whisper to let us know; we asked to be removed from consideration instead of competing in an inappropriate category.) Franz's article is a nice overview of the build/continuous integration system that he put in place at Global Healthcare Exchange, and it sounds like the build system that we've built-up over the past few years.

There is an opportunity to create a build system product, and I know that there is a long line of people willing to pay for the perfect build system. Perhaps something like Maven will fit the bill, since the necessary level and frequency of customization would demand an open source (but not necessarily free) product. (I'm waiting for good documentation on the Reactor plug-in, since we work in a multi-project environment, and it looks like it's finally there.) We've passed our internally developed build system on to some of our larger customers for use on their own projects.

I can boil the abstract idea of the ideal build system down to three principles:

A software application should be the output of an autonomous program.
The program and its inputs should themselves be the output of an autonomous program.
A version-controlled object and the "get version" program are the only initial inputs.

"Autonomous" is used in the sense that the program should return exactly the same output when provided with the same input. The "get version" program might be a check-out or it might be something like downloading a specific Java version.

These principles would be satisfied by something like a CVS checkout that retrieves a version of Ant, a version of Java, and an Ant script that then performs additional check-outs, compilation, etc. The third principle is subtle but extremely important. For example, a newer version of Ant shouldn't be used to compile an older version of the software application.

Personal Reverie on the Perfect IDE

Fri, 18 Apr 2003 13:25:47 GMT

This post (and this weblog) has a new home.

As a user of both IntelliJ IDEA and Eclipse, I could easily take either side in the debate as to which is the better IDE for Java development. Ant, JUnit, CVS integration in the IDE are all Good Things, what I really want is IDE integration in Ant and not the other way around.

More concretely, instead of being able to run Ant against a set of Java source files with defined classpaths and other environment settings, I would like to work with either a set of Java source files appropriate to a specific Ant task or Ant target with classpath and other parameters drawn from the build file.

Microsoft's Not All Bad

Fri, 18 Apr 2003 03:40:40 GMT

This post (and this weblog) has a new home.

As a strong Java advocate, I take a few (deserved) pot shots at Microsoft's forays into enterprise software when the opportunity presents itself, but I have to say that when it comes to "office" suites and rich user applications, no one does it better. I've been using the Office 2003 beta for a while, and it is very, very nice. (I wouldn't be the first to compliment InfoPath or OneNote - which can only be truly appreciated on a TabletPC - but the improvements in Outlook are the most important feature to me, personally, so far.)

To a point, with reasonable XML support and accessibility through web services added to the product, it doesn't bother me (much) to have Microsoft own the desktop applications because it is now possible to build solid integration with the Office products from a generic environment. (In fact, we've got a neat demo using web services support to plug Excel-based financial models into processes implemented in our Java-based BPI platform.) The former state-of-the art for integration with Office was either at the file-format level (e.g., through POI) or through a Java/COM bridge (e.g., for free through something like JACOB or for pay through something like J-Integra (the JCA support is a nice touch)).

That isn't to say that I wouldn't jump at the chance to have similar high-functionality applications on a Linux platform (although Cygwin fully satisfies my occasional craving for sed, awk, find, and their ilk). Even though IBM's going to make a run, it appears that OpenOffice and Corel are the only options for SMB and SOHO users, and that means that Microsoft will still get my money.