1.2. Boiling Frogs Let's look at it still another way. You've doubtlessly heard that if you put a frog in hot water, it will leap out, but if you slowly bring tepid water to a boil, the frog will die contentedly. And of course, that's the debate that I hope to trigger in this book. Are the waters around us warming? Notice at the end of my introduction, the owl and the ostrich are exactly the same when it comes to consequences. They may not recognize it, but motivations don't matter one little bit. If the water starts to boil, if the conditions on the river change, they'll both die. This past year, I decided to wake up to my surroundings to test the water around me. I learned both Ruby and aspect-oriented programming (AOP) . After checking the temperature, I think the water is actually heating up. It's not boiling yet, and I don't know if it will ever boil. But I do know that I'm going to keep a close eye on the temperature for a while, and I hope to convince you to do the same. Let me tell you why. 1.2.1. Danger Signs A large number of the applications that we write put a web-based frontend over a database, sometimes with additional business rules and sometimes without. Yet, after more than five years of solving this problem over and over, we still can't solve it very quickly in the Java space. Further, most Java framework developers are making incremental changes that won't truly revolutionize web development. Building a new team to solve this problem in the right way is a demanding job. Building a team from, say, COBOL programmers, is nearly impossible. The language is too alien, the frameworks too extensive, and the landscape too unstable. Even with seasoned developers, it takes a surprising amount of code to get even simple applications off the ground. Jason Hunter: The Next Big Thing Author of Java Servlet Programming Jason Hunter works as a lead applications engineer at Mark Logic. He's the author of Java Servlet Programming (O'Reilly). As Apache's representative to the Java Community Process Executive Committee, he established a landmark agreement allowing open source Java. He is publisher of Servlets.com and XQuery.com, is an original contributor to Apache Tomcat, is a member of the expert groups responsible for Servlet, JSP, JAXP, and XQJ API development, and has participated in the W3C XQuery Working Group. He also co-created the open source JDOM library to enable optimized Java and XML integration. Is Java in danger of losing its leadership position? JH: Java's already ended its leadership run. It happened maybe two years ago when the best brains in the industry stopped focusing on Java as a technology and started splitting off into other areas of interest. It's only gotten worse as of late. The departure of Josh Bloch and Neal Gaftner to Google is a high-profile sign of the changing tide. But they're not alone. If you want to push the envelope these days, you don't do it by innovating on Java. You may do it with Java, but not on Java. It doesn't mean Java's dead. It just means Java isn't cutting edge anymore. It's plenty understood, plenty stable, and entirely ready for outsourcing. What's next? JH: What's next? I don't think there's one thing. There's definitely not one language. Java's still the ubiquitous language. The innovation now is happening on top. Exciting areas: web remoting (a.k.a. Ajax), search (a.k.a. Google and XQuery), and folksonomies (a.k.a. flickr tags). I have a very practical way of evaluating what is the hot technology: [determining] what earns you the most money being a trainer of that technology. Java definitely was the hot technology for years. I earned twice what the C++ trainers were receiving. It wasn't that Java was harder, just that there was more demand than supply. If you train on something commoditized (like C++ was and Java is now), you get mass- market rates. If you train on something too bleeding edge, you don't get enough customers. I don't see any movement right now that's got the same huge swell potential as Java had. What are the "alpha geeks " doing, as Tim O'Reilly calls them? Well, James Davidson dug deeply into the Mac. But there's not a huge amount of room for experts in that market. There aren't enough business dollars to be earned. I've gone into XQuery, which I've found a fun and useful way to bring search ideas "in-house" and put you in control of what you find and what you do with it. Mike Clark became an expert on automation. My advice to people without a target yet is to learn Subversion and help companies transition from CVS to SVN. But we're all going in separate ways. We've agreed on the Java base, but are diverging on what we do with that now-ubiquitous standard. Your questions are very focused on Java and "alternatives to Java." The Web wasn't an alternative to Windows. It was different. The tech phase we're in now isn't about an alternative to Java. It's different. We're going to take Java for granted just like we take CPUs for granted: it's necessary. It was once the place where all the money was; now it's more of a commodity. 1.2.2. 1.2.2.1. Complexity Java seems to be moving away from its base. You might solve the hardest problems more easily, but it's much harder to create simple web apps than it ever has been before. James Duncan Davidson calls this problem approachability . When Java was young, you d idn't have to know much to build a basic applet. Now, to build a simple web app using the most popular frameworks, you need to know much more. True, open source tools are changing the productivity of Java dramatically, in the best possible ways. Tremendous tools like Hibernate and Spring can let you build enterprise-strength applications with much less effort. But it can take a whole year to confidently learn how to wield these tools with skill. AOP can also help, by letting you write plain old Java objects (POJOs) for your business rules, and isolate services in prepackaged aspects like security and transactions. These abstractions, though, make an ever-rising river for the novice to navigate. My question is this: how high is too high? I think we're already getting too high for most novices. I no longer feel comfortable telling a client that they can retrain the average COBOL programmer on Java. There's just too much to learn, and it takes too much time. In the past, complex problems drove higher abstraction. When computers got too big for people to code with wires, experts programmed with machine code. When those programs got too big for people to understand, they organized the machine codes and data with symbols in assembler language. Rising complexity led to high- level languages, structured programming, and object-oriented programming. My contention is that this higher river of complexity will flood, forcing us to adopt a new abstraction, sooner rather than later. 1.2.2.2. Rapid revolution There's been an incredible amount of innovation around Java in the past three years. You've experienced a transition from the heavyweight containers like EJB to lightweight containers like Spring. You've likely moved from EJB or JDBC persistence to iBATIS, JDO, or Hibernate. You're possibly seeing the wisdom of moving beyond Struts to something like Tapestry. It's been my experience that most innovation is driven by need. My theory is that revolution increases dramatically when complexity hits a certain threshold. The only evidence that I have to support this theory is circumstantial: The overpowering new mountains of persistence frameworks The proliferation of model-view-controller (MVC) frameworks The growth of containers The rapid introduction of XML-binding frameworks I'm suggesting that inventions usually accompany a need. When we get something that's right or merely close enough, like Ant or JUnit, we leave it alone until it doesn't fit our purposes anymore. Experienced developers likely will not understand the excruciating process of learning enough to build the simplest web application in Java. Many of them will complain that I am overstating this issue. If you're in that group, I challenge you to find a smart, inexperienced Java developer who's learning the whole stack of applications that you need to do enterprise web development, and interview him. The problem is twofold. First, it's hard. Second, the consequences for failure are dire. If you pick the wrong horse once, or get locked up for three years on a big project with dated technology, you'll be just about starting over when you move on to the next project. The implications of the churn are staggering. To me, they may mean that code needs to be happening at a higher level of abstraction, and we've been incapable of finding it in Java. 1.2.2.3. Unnatural stretching Increasingly, you're probably stretching Java beyond its intended directions. It's just a plain fact that the object you code with plain Java is not enough anymore. I made the point in Better, Faster, Lighter Java that trying to code all crosscutting services and all behaviors into business objects is folly, and inheritance does not go far enough. You've got to use tricks, like compile-time byte code enhancement or runtime code generation with proxies, to make the object transparent. You are now stretching Java beyond its intended purpose, and that's good to a point. You're also increasing the barrier to entry. Ask any novice who's tried to troubleshoot a problem with Hibernate's lazy loading, or Spring's proxies. I've also noticed that other, more dynamic languages rarely use things like AOP or dependency injection. Those features solve critical problems in Java, but more dynamic languages like Smalltalk, Python, and Ruby don't have the same level of pain. I'm not saying that these are bad technologies. They absolutely destroy the closest heavyweight alternatives, in terms of simplicity and power. They're solving hard problems. It's just that your mind can learn only so much, only so fast. Java's rapidly becoming an effective tool set for elite developers. Hey, maybe that's where programming is going. I'm just saying that this unnatural stretching is one more clue that it may be time to take the temperature of the water around you. 1.2.2.4. Language evolution Java 5 is strongly touted as perhaps the most innovative major release of Java in half a decade. I do agree that it's going to have a significant impact. I'm not at all convinced that all of the impact will be positive. I regularly attend a conference called NoFluffJustStuff. The experts at the conference sit on a panel and answer questions. One of my favorite questions deals with new features in the language. The whole panel agrees that generics, as implemented, are a bad idea. That usually shocks the audience. If you think about it, the Java generics Java Specification Request (JSR) introduces a whole lot of syntax to solve a marginal problem with no corresponding change to the Java virtual machine (JVM). I'm guessing that the typical Java developer rarely gets a class cast exception. And there are plenty of opportunities. Most of the objects in a typical Java application are usually in collections anyway. Whenever you take them out of the collection, you've got to cast them from Object anyway. At that point, type safety gives you about as much protection as a lap belt in a burning, plummeting 747. Yet, the generics syntax is invasive, and the implementation is worse. In an age when more and more experts assert that dynamic typing leads to simpler applications and productive programmers, Java developers are learning how to build stronger enforcement for static types. Add questionable use of legitimate features like annotations , which can completely change the semantics of your program without conventional code, and you've got all kinds of possible trouble. Does the increase in power offset the increase in complexity and obscurity? Annotations bring a completely new tool, and in many ways a programming model, to the Java community. I don't know enough t o say whether we'll learn to use annotations well, but I do feel comfortable predicting a few major disasters while we learn. I don't want to tip my whole hand too early. I'll talk more about Java limitations in Chapters 3 through 5. Right now, just understand that Java is experiencing some real problems. They may be growing pains of youth, or they might be arthritis in Java's October years. I just don't know, but the temperature is rising fast enough to get my attention. 1.2.3. What's Good Is GOOD I don't mean to say that Java's bugler is finishing the last few notes of "Taps" as you read this paragraph. Instead of spewing doom and gloom, I'd rather tell owls and ostriches alike to pick up your eyes, and watch and listen. Look at it like this: conditions are ripe for a credible alternative to emerge. At the time of printing, Java's still the king of the hill. In fact, powerful and compelling motivations still drive new investment in Java: The Java community is vibrant. You can find talent to attack hard problems in Java. You can also find supporting staff, like salespeople and project managers, who know Java. Most major commercial vendors support Java, or a close derivative (C#). As a result, you can buy applications, servers, components, tools, services, and even management consoles for Java. Open source is a thriving force in its own right, and it is driving incredible innovation daily. Academic institutions teach Java development, and do research on many Java-related problems. I recently worked with a start-up that's working on a tool, born in a university research lab, that can predict Java performance, given a UML diagram. The JVM is a powerful innovation in its own right, and allows unprecedented portability. Some experts believe that the JVM may be more important than the Java language itself. Now, you might believe, as I recently did, that all of this vibrant community trumps any language advantage, in all but the most extreme problems. And even if you did find such a problem, what's the compelling alternative? How will it ever find enough developers to reach a critical mass? You're probably thinking: face it, Bruce, there's .NET and Java, and .NET is, by design, as close as legally possible to Java. Adopting .NET would be like overhauling your diet by swearing off McDonalds, and going to Burger King every day. After that, there's nothing. This much is true. If there is no credible alternative, your best course is to keep looking inside the Java community for answers. In that case, this is a dead book, and you can just let it be. But give me a few more pages, lest you close it too soon. . It was once the place where all the money was; now it's more of a commodity. 1 .2. 2. 1 .2. 2.1. Complexity Java seems to be moving away from its base. You might solve the hardest problems. of complexity will flood, forcing us to adopt a new abstraction, sooner rather than later. 1 .2. 2 .2. Rapid revolution There's been an incredible amount of innovation around Java in the past. happening at a higher level of abstraction, and we've been incapable of finding it in Java. 1 .2. 2.3. Unnatural stretching Increasingly, you're probably stretching Java beyond its intended