Today Frank Sommers and I attended NetBeans Day in San Francisco. Two things jumped out at me initially. First, the event was quite packed. It was hard to move around in the lobby between sessions. Second, Sun is clearly serious about NetBeans. Sun has invested in NetBeans and brought it a long way in the past couple of years, and the momentum is strong.

In the afternoon I watched a demo of new features for enterprise applications in NetBeans 5.5 beta, and saw that quite a bit of code generation has been built into the IDE. For example, you can generate EJB3 entity beans from database tables. You can also generate web pages that allow you to do basic CRUD (Create/Read/Update/Delete) operations on those tables. It was somewhat reminiscent of the kind of metaprogramming that's helped make Ruby on Rails popular, but with more of an IDE feel. (There's a wizard dialog that pops up to let you make choices, such as whether the CRUD web pages should be based on Struts or JSF.)

After the demo I asked one of the speakers, Ludovic Chamenois, an architect on the NetBeans project, to what extent the generated code must be maintained by hand after it is generated. He indicated that you have several options. Once you generate an entity bean, for example, you could modify it by hand to add business methods, such as methods that perform data validation. If you do that, then later when you add a field to the table to which the entity is mapped, you can't simply regenerate the entity bean using the Java to DB tool, because you'd lose the hand-added business methods. But you could use the IDE to add a field to the entity bean, and simply select from a list of unmapped fields in the table the one to which you'd like map your new field. Or, instead of adding business methods directly to the generated entity bean, you could subclass it to add hand-written enhancements. Later when you update the schema, you could simply regenerate the entity bean superclass.

We use the latter approach, maintaining a hand-written subclass of a generated class, in our own project at Artima. Which brings me to one of the feelings I got as I watched this demo. Two years ago Frank and I looked at Struts and a few other web application frameworks, and decided that none of them met our needs. Over time, we built our own simple, to-the-point web/mvc framework for our project. In those days, JSF wasn't even on our horizon. Today, we'd definitely look at JSF, but I'm not certain we'd choose to use it for the particular application we're working on. We chose Hibernate about that time as well. EJB2 just wasn't interesting to us, and EJB3 wasn't mature. But even though we like EJB3 today, it still has fewer features than Hibernate at this point, and likely a slower pace of future enhancement.

I believe we made the right decisions two years ago, and I feel there's a good chance we'd make the same choices today even though the options have broadened. But I could see clearly in the NetBeans demo something that I already knew, that by choosing not to use a standard, we give up a lot of advantages in tooling and other kinds of support. NetBeans 5.5 was very conscious of EJB3 annotations, and JSF component to managed bean mappings, and so on. NetBeans 5.5's CRUD generator for JSF and EJB3 is already finished, whereas we're still merely planning to build one for our own framework.

Our home-built framework is going to be better for our project in the long run, because it is more tailor made. Nevertheless, I can't help but feel jealous of the tooling support NetBeans and other IDEs will have for the new standards of EJB3 and JSF.

When is the right time to use a standard versus roll your own custom approach? Bernard Woditschka, Software Architect at Anecon Software Design, gave one answer to this question when talking with Frank and me in a hallway conversation today about SAP. He said SAP's attitude is that you shouldn't customize their software to fit your business processes, you should change your business processes to fit the software. Bernard said,

There's a tendency among business people to use standard software, because there's so much there that you can't write all these features by yourself.

Part of the thinking, according to Bernard, is that SAP has worked with dozens of other companies, and SAP therefore knows more about what your business processes should be than you do. Plus, because of their economies of scale, SAP can offer their de-facto standard software for a fraction of what it would cost you to create a custom system that better matches your current processes.

What do you think? When do you create a custom solution versus use a standard?