Tooling of the Java Trade

In any discussion of Java and the Java platform, tools can't be ignored. See what the expert panelists at the 2006 Java Technology Roundtable had to say about IDEs and other tooling issues.

• By Simon Phipps
• June 9, 2006

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.

The Joke's on SOA
Rob Gingell: Earlier you [gestures toward Chappell] were mentioning the need for governance in the SOA thing. A term I thought you might have been about to use, maybe you're including in governance, is architecture. One difference between SOA-like environments and some of these earlier IT environments, where the peasants sort of rose up against the dominating IT organizations, is now we're talking about building environments in which the pieces get integrated with each other in a way that isn't a matter of competing with, it's living inside of in a funny kind of way.

What you need in the aggregate of your tools is a sense of the architecture and structure of the thing that you're building, right, and these tools can introduce stuff into the system [that] is architecturally untenable, things that will forever doom you to mismatches and layers about how things work. Effectively, SOA means everybody's building the C library or the Java, and how long would that work if everybody just had a different idea of how that was going to work? It wouldn't have worked very long.

Chappell: Right, and that's exactly what I was saying earlier about having an enterprise architecture means you have to standardize on a set of infrastructure and technologies that you're using.

Bray: Does it bother you that a lot of people, particularly in the Web framework, hippie rattle, now use the term "enterprise architecture" as the punch line of jokes?

Chappell: No, that doesn't bother me at all.

Milinkovich: Back to Simon's original question, I think one of the acid tests should be, if your tools appear on your architecture diagram, that's probably a problem.

Sam Pullara: In many ways I think that the bad tools that exist today are a fault of the standards that they were built on top of. In a sense, if you're trying to build something and you're building it on infrastructure that isn't sufficiently general or isn't designed such that someone can purely declare a Web service without making all kinds of additional hints, and notes, and code to make it a scalable system, I think that is where it breaks down. With the tools that exist today a lot of the times they end up having to co-generate multiple layers of the system to build an application, as opposed to, "here's a nice tool that lets you start at the high level." If the runtime can get enough information from the tool without the tool having to build it, I think you're a lot better off.

Phipps: But isn't the solution to that to use an architecture that doesn't have many layers that need wrangling in the absence of the developer? Is the argument to make REST versus WS-*, rather than tool vs. tool?

Ted Farrell: Well, I think it's philosophy. I think a lot of the tools, to Sam's point, are written from the top down, starting with the abstractions and not really figuring out how they map to the end runtime. You'll always be going down, hitting a point where you're in this nasty generation part. We've made a policy across the board, which is there's no deploy-time generation. We build design-time abstractions. Because of it you can pick any tool you want, but when you're in it we're able to do some really cool abstractions, and sure there's going to be a set of users that are at a higher level that might not appreciate the differences between the protocol that we pick or the packaging, but the nice thing is that someone who does know the difference can go right down into the level, and the guts, and it's just the standard stuff.

Phipps: So you're saying that WS-* is just an interesting complexity to keep the developer's life more varied.

Farrell: No, I think the standard's important because I think you need the interoperability, and hopefully the standards also lead to better trains and a bigger pool of developers that understand the technology. It doesn't mean you can't take that [and] build a design time on top of it that appeals to people who don't necessarily understand the technology. I think the problem all along is this top-down drill has gotten everyone into this generation hell. I think the tools are really important because it's not just about Java today. To Dave's point, it's about XML, it's about the SOA standards; it's not just about Java. You can't do it as a single tool.

Glory Days
Chappell: And I think tools don't always have to dictate as code generation it happens either. Tools should be more about configuration rather than coding, especially if you're describing dependencies between these heterogeneous environments.

But I'd like to respond to something Tim said a little while ago about enterprise architecture being the brunt of jokes. And I agree with you; I think there's been a backlash in the industry because there've been enterprises spending years in trying to determine what's the best enterprise architecture in terms of what are our canonical data models that we're going to use across our enterprise? Let's define everything from one end to the other, and it hasn't been successful. I think what has been successful for those who are adopting SOAs today are enterprises that can identify smaller more attainable projects, yet accompany that with a longer-term vision so that you can build repeatable success patterns that can be carried from one project to the next. I agree it's not just about the, as you put it, Web services hippies, but I think that conventional people also have felt a backlash in that too.

Ari Zilka: I was going to say two things on what Tim said as well. I would recharacterize leakiness as abstraction layers, and I would say that the classic examples to me of good tools and bad tools are Visual C++. I want to write a graphical application; I think I'm in C++, and there are bracketized macros here and there, and I have no idea. I can't open up a raw, empty file and start VIing and write a Windows application. I just can't do it. To this day I've never figured out how. I have to have the tool. I don't know what it's doing. I don't like it.

Farrell: That's your bad example?

Zilka: That's my bad example. That's abstracting me from a ton of code that no one understands, essentially. Then the abstraction on the opposite end is, in the Web services case, being able to plug in my transport layer would be a nice thing. When writing a service I don't really need to know how the information is going to get moved. I need to solve a business problem at a point somewhere in a network of interconnected, business functions. It's all about abstraction layers to me; and at the same time I think that calling enterprise architecture a joke is accurate because it bugs me that there is a difference out there in the world between enterprise Java and whatever nonenterprise Java is.

To me enterprise Java means an IT shop comes in, spends a bunch of money on reliable sands and networks and fault-tolerant systems and two-phased commit, optimistic concurrency. These are things that I think fit below the abstraction barrier. I think O/R mapping is a great tool. I think things like CJDBC are really cool. Deciding how many databases are under me, stuff like that. So the notion of enterprise architecture being a joke, and leakiness, and abstraction barriers are all commingled. And Frank's point—not knowing what a tool does—comes back to the same problem. Java should be the language, not a different language for a different company or a different language for a different problem space. It should be the same programming language that I can go buy a book like K and R (Kernighan and Ritchie), understand the language, and then go solve business problems.

Larry Cable: It's a fait accompli, it's not a question. I remember the tools I first started developing with: an IBM card punch, a line printer dump of main memory…

Phipps: Oh, we used to dream of an IBM card punch… [laughter]

Cable: When life got tougher Texas Instruments programmers calculated to do the register offset map. Then I spent the bulk of my career thinking that the height of sophistication was VI in one X terminal and DBX in another, and I spent a lot of software on that and was quite productive. Then I moved over to the current generation of IDEs a few years ago and got orders of magnitude more production. Could I today go back from an Eclipse or NetBeans environment and build a Web service, a two-and-a-half–tier Web app, anything like that? Would I want to? Is it possible? Probably. Do I want to? Hell no. Does anybody else? Hell "expletive" to the nth power no!

Milinkovich: I was talking to a guy yesterday. He said Emacs and...

Cable: Yeah, well, he's the exception.

Pullara: I was an Emacs user up until 2001 or so.

Phipps: Even James Gosling has switched off Emacs.

Swine Makeup
Pullara: Now I use IntelliJ and Eclipse and NetBeans, depending on what I'm trying to do. That generation of Java IDEs has fundamentally changed what it is to program versus any other. When someone from some other scripting language camp says, "Oh, but look how verbose it is," one of the things I'd like these things to tell you is you know you wrote this many lines of code and did this much stuff. How many keystrokes did I actually do? How many clicks did I do? Because the speed at which development goes today and the speed of being able to refactor your code is at least two orders of magnitude. There are things we do in a day that we would have been like, "Okay, we're going to have to spend two quarters… "

Some of it's the IDE; some of it's testing. I think that the fact that testing has grown: You can now believably do an isomorphic transformation and you know nothing's changed. The question is, would Java be where it is today without these IDEs? Would people have stopped using it if scripting languages come out and now you're competing keystroke up to keystroke against a scripting language? I think that's a really interesting thing to ask yourself. Is it a valid question to say, "I want to just open up a thing and start typing Java in Emacs, and that's going to be my measure of how good the language is"? I'm going to say, "No." I think that the tools now have become like a card catalog. Would you build a library without one? Well, you could but…

Bray: It's not controversial to say what Larry just said, that IDEs as they stand today are categorically a good thing. There are a few people who resist, but they're basically wild-eyed crazies. One reason is they're not putting lipstick on a pig, right? What they're building on top of, the basic structure of Java and classes and objects and packages and so on, is a good, sound, extremely robust foundation. I think that's a great robust foundation to build on. When I look at some of the tooling that's being built around things like Microsoft WCF and so on that's being built around WSDL and all that stuff, it kind of seems like it's putting lipstick on a pig. And I'm just not sure that it's ever going to become as good as IDEs.

Milinkovich: I guess following your analogy then, where I see the future of Eclipse going is it's going to be the same lipstick on every pig.

Chappell: You know what, an IDE is not always just about developing the code at a specific endpoint or a specific application. Speaking from our point of view, an IDE can be based on Eclipse but really focused on building end-to-end, SOA-based business processes and all the associated things that you have to do when you're doing that. Taking that same paradigm of edit, compile, run, debug—we debug more often than we like—and moving that to the kinds of things that someone does when they're building a set of distributed services and putting them in an automated process, an IDE is a very comfortable environment for that kind of thing too.

Milinkovich: Arguably, you couldn't build those kinds of systems without one.

That Smarts
Bob Blainey: I think we got off the original question, though. IDEs are indisputably a good thing. I don't think anybody would argue with that. I think the issue really is that you don't want the tools inventing new abstractions. You've got to have extremely high fidelity from development through debug through to operations, and if you lose any of that fidelity, that's where you get problems.

Cohen: What do you think about annotations?

Blainey: To the extent that we all agree that they're part of the programming model and not decoration, I think they're a good thing. [When] we all start to invent our own little annotation syntax, they're a bad thing and probably akin to macros in C and C++ where you can go and invent a whole new language and end up in a world of hurt. As I say, I think if you're consistent about the abstractions that you present and you're consistent through the whole development cycle, I think it probably doesn't matter whether it's embodied in a tool or in the runtime, as long as the developer sees the same thing.

Pullara: How do we differentiate between these two different types of tools when we talk about them? They can both be called tools; they can both be called IDEs, but there's a fundamental difference between using an IntelliJ, or Eclipse, or NetBeans where my transformations are fully concrete. There's no abstraction layer between me and the adjustments that I'm making to the code versus something that I'm doing that's indirectly doing something else that maybe indirectly is doing something else. How do we define those so that we can talk about them?

Blainey: But you're always dealing with abstractions, right? Even when you're fiddling with half the code you're dealing with abstractions.

Pullara: I think this goes back to the continuing failure of UDDI, you know the dynamic place where you find all of your stuff, when, at the end of the day, people like to talk to salespeople and choose a vendor and have drinks with them, and then go and use their service. And the last thing IT wants to do is deploy a service that just goes and finds the zip code look up and execute it. Web services are used by the enterprise that wants everything configured.

Farrell: I don't think you can write off Web services. Dynamic binding, forget about Web services, is just no one writes software that way. Even in places where you have a choice of which vendor to use or something, it's all programmatic choice. I think Web services is more about interoperability than it is a dynamic binding.

Chappell: Before we write off UDDI, though, I think there's a value of business directories when working internally in conjunction with a solo-management platform to enforce governance of who's allowed to promote a particular version of a service out to…

Farrell: Internal and at design time.

Pullara: I totally buy it for both those situations.

Cohen: In the argument for IDEs it allows us as professionals to codify a means to understand how to write software. Parallel into the Web services world is these description languages. They're kind of like a way to codify how to write software.

Jon Bostrom: Well, they're kind of an institutional memory. It is a way to capture that, capture the principles, capture the processes so that you both reduce the tedium and you reduce the learning curve. With the people we have coming on board today as developers we need to reduce the learning curve all we can.

What Now?
Cable: I think there's an interesting question that kind of faces the industry, which I think Tim has kind of touched on a couple of times. There are these scripting languages and dynamic environments that are appearing now that seem to suggest there is a simpler path to solving the same problem that we seem to be solving with what appear to be more complex frameworks and environments. I'm not sure if that's true; I'm not sure if there's a simpler way to do this. But there are some interesting examples I think that are coming over the horizon to see if there's a competition, is there a winner; is there a loser.

Example: Take a look at Ajax. What's the Ajax client/server computing model? It's not question mark WSDL generates some JavaScript on the client side to issue SOAP requests and transform them. It's basically suck a bunch of arbitrary XML over an HTTP connection, write a bunch of JavaScript that wanders the XML document structure and then does some JavaScript transformations from that into the document object model in the browser, changes some CSS, bang. Okay?

What happens if Ajax takes off and we've got this massive Web services stack infrastructure in the server tier, and all the Ajax developers look at it and say, "thanks, but you know, no thanks. I can do my job much easier without that level of complexity and abstraction." What happens then?

Bray: How did we get here? Heterogeneity is a fact of life, and we have to get stuff working across this. We tried to do that, that was CORBA, and it didn't work that well. And Microsoft tried to do it with DCOM, and it didn't work that well. Then the Web came along, and it kind of did all that; it scaled across a heterogeneous environment and it just worked, and people said, "well, let's try and do that." They started sending XML messages back and forth across HTTP, and it kind of worked. Then they said, "Wait a second, didn't we used to have .H files that declared what was there so we could use it?" And that led down the path to WSDL and friends, and something went wrong along the way.