1.2 Options

There are many possible solutions for dealing with the bloat in Java. Head-on is but one possibility. It takes courage and energy to take on the bloat, and you may not wish to fight this battle. You've got alternatives, each with a strong historical precedent:

Change nothing; hope that Java will change

This strategy means letting your productivity and code quality slide. Initially, this is the option that most developers inevitably choose, but they're just delaying the inevitable. At some point, things will get too hard, and current software development as we know it will not be sustainable. It's happened before, and it's happening now. The COBOL development model is no longer sufficient, but that doesn't keep people from slogging ahead with it. Here, I'm talking about the development model, not the development language. Java development is just now surpassing COBOL as the most-used language in the world, begging the question, "Do you want to be the COBOL developer of the 21^st century?"

Buy a highly integrated family of tools, frameworks, or applications, and let a vendor shield you from the bloat.

In this approach, you try to use bloat to your best advantage. You may put your trust in code generation tools or frameworks that rely on code generation, like EJB, Struts, or Model Driven Architecture (MDA). You're betting that it can reduce your pain to a tolerable threshold, and shield you from lower-level issues. The idea has some promise, but it's dangerous. You've got to have an incredible amount of foresight and luck to make this approach succeed. If you previously bet big on CORBA or DCE, then you know exactly what I mean.

Quit Java for another object-oriented language.

Languages may have a long shelf-life, but they're still limited. For many, the decision to switch languages is too emotional. For others, like author Stuart Halloway, the decision is purely pragmatic. The long-time CTO of the respected training company DevelopMentor and tireless promoter of their Java practice recently decided to choose Objective C for an important project because Java was not efficient enough for his needs. Alternatives are out there. C# has some features that Java developers have long craved, like delegation, and C# hasn't been around long enough to suffer the bloat that Java has. Ruby is surprisingly simple and productive, and works very well for GUI prototyping and development.

Quit object-oriented languages for another paradigm

Every 15 to 20 years, the current programming model runs out of gas. The old paradigms simply cannot support the increasing sophistication of developers. We've seen programming languages with increasingly rich programming models: machine language, assembly languages, high-level languages, structured programming languages, object-oriented languages. In fact, today you're probably noticing increased activity around a new programming model called aspect-oriented programming (see Chapter 11). Early adopters were using object technology 15 years before it hit the mainstream. Unfortunately, new programming paradigms traditionally have been very difficult to time. Guess too early and you'll get burned.

Spend time and effort becoming a master craftsman.

An inordinate amount of bloated code comes not from people who know too much about writing software, but from people who know too little. The temptation when faced with a problem that you don't fully understand is to put everything and the kitchen sink into the solution, thus guarding against every unknown. The problem is that you can't guard against unknowns very effectively; frankly, all the extra complexity is likely to generate side effects that will kill the application. Thoroughly understanding not just your problem domain but the craft of software development as well leads to better, smaller, more focused designs that are easier to implement and maintain.

Each of these techniques has a time and a place. Research teams and academics need to explore new programming models, so they will naturally be interested in other programming paradigms. Many serious, complex problems require sophisticated enterprise software, and the developers working on these problems will look to complex frameworks that can hopefully shield them from the bloat. Small, isolated development projects often have fewer integration requirements, so they make effective use of other programming languages, or paradigms. But for most day-to-day Java applications, the alternatives are too risky. My choice is to actively fight the bloat.