(via my java.net blog)
This is a long blog entry … you have been warned.
Big conferences like JavaOne are always accompanied by the introduction of new books. This time’s no exception.
I stopped by the JDOCentral booth to visit my friend Patrick Linskey of SolarMetric, and he surprised me with a free copy of Bitter EJB, the new book he wrote with Bruce Tate, Mike Clark, and Bob Lee. I’m very pleased to have it, because early glimpses of some chapters have been posted on The Server Side, and it looks even better than Bruce’s original Bitter Java.
With apologies to Patrick, the first chapter I turned to was Mike Clark’s “Bitter Tunes,” about performance tuning for EJBs. Mike and I have an interesting history. Last year I gave a talk at JavaOne called “Stalking Your Shadow: Adventures in Garbage Collection Optimization,” and about two months later I gave the same talk at a No Fluff, Just Stuff symposium in Dallas. The talk may sound extremely technical and arcane, but it’s actually a “stealth agile” talk, in which I use the complexity of GC interaction and optimization to advocate a tightly iterative approach to optimization—avoiding both premature and “way too late” optimization by developing iteratively and building performance testing into your development process.
In the talk, I recommend using a package called JUnitPerf to automate performance testing and integrate it into your build and test process. In Dallas, I got to that slide and heard “Thanks! I’ll pay you later” from the back of the room. That’s how I met Mike Clark, the author of JUnitPerf. And I’m glad I did, because he’s one of my favorite folks in the industry.
Mike and I independently began delivering the same message: although the hazards of premature optimization are well known, it’s also possible—easy, in fact—to wait too long, and only learn about performance issues at a stage when they’re so deeply embedded in your architecture that it’s all but impossible to eliminate them. JUnitPerf is designed to help with that, making automated performance testing an easy and repeatable task, so that you can find performance problems as soon as they appear and deal with them before it’s too late.
The first antipattern in Mike’s “Bitter Tunes” chapter is “Premature Optimization” (and rightly so, because many developers still need to hear that message). But the solution to premature optimization isn’t to just wait ‘til the end of the project; it’s to wait until you see real performance problems, and then attack them as soon as possible. So the second of Mike’s antipatterns is “Performance Afterthoughts,” and the solution is “Plan Early and Often” (a title I really like). Mike’s advice applies not just to EJB projects, but to all software projects.
I’ve focused here on one chapter of Bitter EJB, but from what I’ve seen, the rest of the book is just as great, and our industry has needed a book like this for quite a while now. You owe it to yourself to buy a copy.
(via my java.net blog)
I remember being at JavaOne in 1999 (I think) when I first heard the terms “J2SE”, “J2EE”, and “J2ME”. I understood the reasoning for such a move, but at the same time I hoped they wouldn’t go too far with the distinction.
It was both amusing and refreshing to hear Jonathan Schwartz acknowledge in this morning’s keynote that Sun has been guilty of pushing multiple, separate platforms rather than emphasizing Java as a single platform. He promised that they would do better.
Of course, they aren’t in a full retreat from the multiple editions, and such a retreat wouldn’t make sense anyway. There are real distinctions between those environments, and the facilities available on them need to reflect that. But I do hope they spend more time focusing on what all the editions have in common.
Unfortunately, for those of us who like to stay informed about what’s coming in future releases, it’s necessary to pick an edition. This afternoon at 3:30, the “Overview and Roadmap” sessions for J2SE and J2EE are scheduled opposite one another.
Sun’s finally ready to really support a free and open community of Java developers in a real way (or so it seems). Check out java.net.
“Oh. That’s not your baby … that’s the Stevie Ray Vaughan boxed set.”
One more thing about the typing debate in today’s expert panel. Dave Thomas said, at one point, “Java and C++ have equated an object’s type with it class, and that’s wrong. The type of an object isn’t its class; it’s what the object can do.”
I agree with that, and I think it’ll be interesting to go revive a four-year-old piece I wrote as part of a WikiWikiWeb debate on the merits of multiple inheritance.
I think multiple inheritance is relatively unimportant and rarely useful, and I’m happy to be working in a language (Java) that does not support it. In part, I’ve come to believe that inheritance is given far too much importance by most OO languages, designs, developers, and pundits.
My thoughts about inheritance have been evolving since I learned Java. The revelations I’ve had may not seem like much to a Smalltalk programmer, but they represent a complete shift in my thinking.
Nearly every introduction to OO concepts I’ve ever read or seen has dealt with inheritance very early, and then moved on to a cursory discussion of “polymorphism” as a sort of nice side-effect of inheritance. Partly as a result of this (and partly because of the underlying misunderstanding) the word “inheritance” is usually used to refer to some combination of behavior inheritance and subtyping.
Java is the first language I have used that mostly separates those two concepts. Extending or implementing an interface represents a subtyping relationship, whereas extending a class represents the more traditional combination of subtyping and behavior inheritance. The process of using and designing with interfaces has brought subtyping out of the shadows and into the foreground of my thinking.
I’ve begun teaching the concepts of inheritance and polymorphism the other way ‘round: polymorphism and interfaces come first, as the fundamental issue, and behavior inheritance comes later, as a nice facility (more, but not much more, than a convenience) when two subtypes share significant portions of their behavior or implementation. It seems to work well. Many of the common inappropriate uses of inheritance never occur to programmers who learn it this way. I’ve found that the method also helps in the explanation of abstract classes and when to use them.
Consider a language that makes the separation even more clear: subtyping uses one mechanism, and behavior inheritance can be specified without also producing a subtype relationship. (I’m speaking hypothetically, but I won’t be surprised to learn that such a language actually exists.) Behavior inheritance becomes a kind of specialized composition or delegation facility. Some of the traditional objections and implementation complexities of MI disappear.
My conclusion, then, is that the strongly-typed OO community may have been going down a side path for most of its history, conflating two concepts that are actually separate. Perhaps, once we’ve corrected that misdirection, the time will come for MI to move back to center stage. For now, though, I’m pleased that Java avoids MI, if only because having to do without it has helped me to understand the fundamental issues more clearly. (From talking to colleagues, I believe it is having a similar effect on others, too.)
I realized almost immediately after posting that that Smalltalk and its ilk (including, for example, Ruby) have essentially the characteristic I was talking about, where subtyping and inheritance are separate concepts. With those languages in particular, that distinction is present because there is no subtyping at all … the notion really doesn’t exist in those languages, because typing as Java and C++ folks think of it doesn’t exist.