By Jon Byous
The new Java Tools Community (JTC) was founded to solve several challenges faced by development tool users and tool vendors. Their quest for "tool friendly" standards, tool interoperability, and open communications within the tool community should help us all.
Here, several JTC members describe what they want to achieve.
The JTC was formed in January, 2004 by a long list of tool vendors, including BEA Systems, Compuware, Embarcadero Technologies, Iopsis Software, JetBrains, Oracle Corporation, Quest Software, SAP AG, SAS Institute, and Sun Microsystems.
But broad participation hasn't blurred their focus. The JTC web site claims: "The JTC is not be a legal entity, does not hold IP, nor will it endeavor to develop code, TCKs, certification suites, nor standards of any type beyond activities related to the Java Community Process (JCP)."
The JTC is sticking to the task of driving easier-to-use, interoperable Java tools supported by a collaborative community. As part of that effort, the JTC works directly with the JCP on targeted Java Specification Requests (JSRs) to support not just developers, but any tool user in the lifecycle, for example, those involved in or affected by Java Specification Request (JSR) 77 (Management) and Java Specification Request (JSR) 88 (Deployment).
Ted Farrell, Chief Architect and Director of Strategy for Application Development Tools at Oracle, says that the JTC is really focused on three things:
First, the JTC promotes "toolability" -- a measure of how easy it is to build tools around a particular technology. "Too often, not enough thought is given to how developers actually use tools and integrate them into the development process," says Farrell. "Making the standards more aware of the tool -- more toolable -- will help all J2EE developers, and that in itself is a big part of the JTC."
Second, the JTC promotes interoperability. Here, Farrell describes how the tool landscape should be able to take advantage of the same type of standards the server landscape enjoys: "Servers have a standard set of APIs, and the vendors compete through their implementation of those APIs. But development tools have traditionally been vendor-specific rather than API-based. So tool vendor interfaces aren't standardized, limiting their interoperability. The JCP Java Specification Request (JSR) 198 will work to standardize tool interfaces, just as is done in the server area."
The third focus of the JTC is communication. Farrell says, "We want to reach out to the customer base, regardless of whether they are JCP members, and hear the opinions and voices of both tool vendors and tool users." The idea is to foster communication and collaboration to develop standards that will better suit tool users and builders -- furthering toolability.
JSR 198 was submitted by Oracle in November 2002 to standardize interfaces for IDEs, so a developer can write an extension for an IDE to a set of interfaces and have it work with other vendors' tools.
"While that falls under the area of JTC, it's only a small part," says Farrell.
The desired outcome of JSR 198 is a standardized way for developers to use Java programming tools from multiple tool vendors in a single IDE, with access to each tool provided through a standard interface.
Typically, developers use a mix of tools from different vendors while developing an application. But currently, because there are no standards for IDE integration, they have to write separate "add-in" modules for each tool vendor's environment.
JSR 198 would define a standard IDE Extension API that allows developers to implement most, if not all portions, of their IDE add-in modules once and have their feature run with any IDE supporting the standard specification.
However, there are a number of other "interoperability" options that JSR198 does not address, where the JTC may provide value. The first is in gaining broad agreement on Java meta-models, where projects developed with one tool could be picked up by others. In addition, there is an opportunity to develop portability of user preferences between tools. Either way, plugin compatibility is only a first step.
Right now, Eclipse, the newly independent open source tools group, is undergoing changes quickly. But it's not a competitor of the JTC.
Oracle's Farrell, like many other vendor representatives, is a member of both. "Eclipse is a tool, and the JTC will help Eclipse by making the standards easier to build tools around," says Farrell.
"The perceived conflict and overlap isn't really there. At some point, Eclipse could join the JTC. The initial feedback on that idea is positive."
In fact, the Chairperson of Eclipse, Skip McGaughey, is quoted in the JTC press release saying: "Eclipse supports any industry activities that support tool integration and interoperability. And I see the JTC as a strong industry initiative to achieve those objectives."
The success of JTC will come down to who participates, and currently, the momentum is growing through both large and small community members.
While the JTC activities will not formally become part of the JCP, many of the JTC members are active members in the JCP who work on various JSRs. Aaron Williams, the JCP Executive Committee relations manager, hopes the JTC will continue to attract more small developers from the tools community to participate in the JCP.
"I think the JTC will definitely benefit the JCP and the overall Java ecosystem," says Williams. "To me, it's a sign of maturity when companies band together to make sure their interests are being met in a community. Their shared-interest community can now help ensure that there's a tool component in a wide variety of JSRs. That's good for the JTC, it's good to have many voices in the JCP, and it's good for the Java ecosystem. It's important that interest groups spring up and get what they need, so we want to encourage and support them."
In strong agreement with the JCP's Williams is Ken Oestreich, Sun's Java Business Strategist.
He has a cartoon of a school of small fish that have gathered together to look like a shark, and together they're chasing a predator fish away. He sees Microsoft as the predator.
It's going to take a lot of work, but he believes the JTC is doing it right, from a position of strength. "We're getting more tool vendors involved in the standards process, and we are able to bring more of the voice of the customer into the process, through them," Oestreich says.
As for the companies not directly participating, Oestreich says, "That's OK, they'll miss out on the discussion, but they'll still enjoy the benefits of standardization."
SAS is a JTC member, and their Director of Java Development Environments, Rich Main, sees the value in customer terms, with benefits for SAS. "Java technology is a strategic platform for SAS because our customers deploy their critical enterprise solutions on a wide array of hardware and software platforms -- Java technology is everywhere that they want to be," he says. "In order for us to be able to satisfy our customer's business requirements as quickly and efficiently as possible, we need a solid underlying Java platform and a robust set of tools on top of the platform. We need the right level of support in the platform and tools for development and deployment of enterprise business solutions. We see the JTC as a valuable mechanism for collecting real-world customer requirements and driving them down into the JCP. In this respect, the JTC will help to make the Java standards process better, stronger, and faster."
Looking forward, Main believes the JTC will help shape the future of the Java platform to better serve the needs of SAS, its customer base, and the Java developer community. "Through participation, we can avoid what I call the "Death of a thousand cuts" -- being forced to implement what should really be done in the platform or tools," he says. "We want to eliminate that burden so that we can focus strictly on solving our customers' critical business problems. In addition, we see the JTC as a way to give back to the Java community by sharing some of our expertise regarding the enterprise business market. So, it's clearly a win-win situation."
Steve Stover, CTO Development Solutions at Quest Software, talks about his company's involvement. "Since its humble beginnings, Java technology has advanced into many directions through the efforts of the JCP, of which Quest Software has been a long time member. The specification process typically focuses on the run-time aspects of Java technologies. While the run-time characteristics of the Java programming language are important, little focus is directed toward design-time aspects in the specification process. In order to encourage more rapid adoption of Java technologies, developers must be empowered to build high quality and easily managed applications in increasingly smaller amounts of time."
How does a tool vendor benefit from participation in the JTC? Stover says, "The main benefit of Quest's participation will be better products for our customers because of the enhanced toolability and tool interoperability focus that the JTC will bring to the specification process. In addition, it gives Quest Software another opportunity to work closer with our peers and partners in the Java community, such as application server vendors and IDE vendors."
Changes are occurring at the JTC, JCP, and Eclipse all at the same time. While it's impossible to predict an outcome, at least the direction of each shows promise for Java technology developers -- sort of a community of communities.
The way to keep it moving your direction is to get involved and let your opinions be known and your ideas implemented. That's what communities are for.