email article printer friendly

Tooling of the Java Trade
IDEs and abstractions engender vigorous discussion and a range of views at the 2006 Java Technology Roundtable
Moderated by Simon Phipps

June 9, 2006

Ted Farrell, Oracle: "The problem all along is this top-down drill has gotten everyone into this generation hell."

Without question tools and their platforms generate a lot of interest and spirited discussion in the Java community. The popularity of Eclipse, Sun Microsystems' rejuvenated enthusiasm around NetBeans, and the loyal following behind IntelliJ IDEA—in addition to other IDEs, such as JBuilder and JDeveloper, that maintain respectable market share—all demonstrate innovation that has fueled a renewed interest in feature-packed IDEs that help streamline application development.

Any discussion of developer tools will stimulate a variety of viewpoints and perspectives. The industry thought leaders who participated in the 2006 Java Technology Roundtable during day two of the JavaOne conference delved deeply into this topic in an effort to define today's tools for not just developers, but for building applications in enterprise environments concerned with solving complex business problems. Here is a portion of the panel's lively discussion in which IDEs and other tools-related issues were discussed during the first hour of the Roundtable.

Fixing a Leak
Simon Phipps: I've heard people talking in the keynotes and elsewhere around JavaOne about how important tools are to the environment. I've heard people criticize Web services as a technology that no one can use without the tools written by the guy that invented the spec. I wonder, is it a good thing that we're moving into a world where the tools are so tightly coupled to the platform that you can't use the platform without the tools? Are there advantages and disadvantages? We've been talking here as if it's the programming language that matters, but I wonder whether there's a sense in which the languages are irrelevant and what matters is actually the IDE you're using. I'd be interested in people's views. Is Java easy enough to use on its own? Is it too dependent on tools hiding the ugliness from you? What's the future?

Frank Cohen: The problem with the tools hiding the ugliness right now is that they implement all sorts of scalability and performance profiles into the finished application that the developer doesn't know a thing about. Three years ago I did a study of SOAP RPC encoding implementation across all the popular tools and showed clearly that SOAP RPC encoding—basically the encoding type 5 of the spec—wasn't scalable. And yet there's still these toolsets out there that will choose RPC encoded by default, and most of the developers don't know a thing about this. I've been telling developers, "know your toolset. Know it at a protocol level what the tool's actually doing."

Tim Bray: It depends on how confident you can be that your abstractions are leaky or not. TCP/IP isn't leaky. You open a socket, that's all. What's happening underneath doesn't come and get you. Relational databases are hard to abstract away; the abstraction gets leaky. A message passing over the Internet is really hard to abstract away. If you believe you can de-leak the abstraction, then you can hide it in the toolkit—sometimes. I've gotten to the point where I feel that the term "SOA" is starting to become actively harmful because there is a mindset there of papering over what feels like really, really leaky abstractions to me that are going to get us all in a lot of trouble.

Dave Chappell: I would agree that there are lots of implementations of tools and infrastructure that don't put an emphasis on performance and scalability. And if you're not careful about what the tool's doing, then you're going to run into trouble. You have to be very selective about what's under the covers there and understand what's going on there. A lot of vendors don't put emphasis on it, and as was mentioned somewhere, developers don't think about that either.

Mike Milinkovich: I think it really depends on what you mean by the word "tool," right? At Eclipse I sometimes say we're in the rope business. You can use a rope to carry heavy loads, or you can use it to wrap around your throat and kill yourself. Part of it, when we're talking about tools here in this conversation, it's tools [that] are either generating code or tools [that] come with an associated runtime, which is over in this intermediate layer between the underlying real system and the system that you're building. Those kinds of tools can definitely, if you're not careful, cause harm. Not all tools fall into that category.

Chappell: Don't blame the tools for bad runtime infrastructure choices.

Milinkovich: I think where we get into trouble is where somebody says, "It's a tool, don't worry. It's just a tool," but really what it's doing is it's either generating a bunch of completely stupid code or it has 14 layers of abstraction. The abstraction is not leaking anymore because it's so obfuscated that no one knows what's going on. Then those kinds of things can definitely get you into trouble, but not every tool fits that description.