Skip to main content

Can we all work together

Posted by daniel on January 12, 2004 at 8:40 AM PST

The newly formed Java Tools Community web site announces "The JTC will promote the creation, adoption and advancement of Java(TM) Specification Requests (JSRs) for 'toolability' and interoperability in the design-time area."

A quick search of online dictionaries showed no entries for 'toolability'. The alternative 'salability' was suggested with the corresponding definition The quality or condition of being salable;salableness from Webster's Revised Unabridged Dictionary. This corresponds to the JTC definition that Toolability is a measurement of how easy it is to build tools around a particular standard or technology.

I am having a hard time understanding much of the content on the Java Tools site. The about page describes some of the goals of the community. For example, "the JTC helps provide long-term insurance against fragmentation or weakening in the Java industry by helping maintain diversity, establishing compatibility, and focusing on customer needs. By aligning the design-time community, the overall design ecosystem can better agree on standards and compete on implementations while strengthening the overall Java platform and JCP."
Feel free to use the feedback below to explain what they're saying or otherwise comment on the JTC.

Actually some of the specific goals of the JTC are interesting and worthwhile. They intend to set up a facility for commenting on and helping with appropriate JSRs. In fact, the site points out explicitly that companies may vote differently in opinion polls on the JTC site than they do as members of the JCP executive committee on the same JSR. Specifically, their page details the following activities.

  • JSR Initiatives -- identification and proposal of suitable tool and design-related JSRs for submission to JCP
  • JCP Expert Group Liaison -- designation of individual members to provide two-way cognizance between JTC member organizations and JSR leads
  • JCP Expert Group Observer -- an observer mail list associated with "JSRs of interest" to ensure JTC member company awareness of JSR development (pending permission by JCP rules)
  • Approval/Disapproval polls -- a tool for the JTC to signal approval/disapproval of a given JSR with regards to toolability and tool interoperability in an open, yet non-binding polling vehicle
  • User / Member voice -- facilitate member, participant and advisor feedback / commentary on tools and design-related topics to the vendors themselves

With the revision of JCP, the process will become more open - here at java.net we have some plans of our own. One of the things we're struggling with is creating a space where everyone feels welcome to contribute. What started this discussion of the Java Tools Community off for us was an item from the Java Patterns community in Projects and Communities. The PatternsCentral post Java Tools Community - Can We All Work Together? takes a look at the recent formation of the JTC. The author writes that "Having a common API among Java tools would give them a much bigger pool of plugins [ but] without either Borland or IBM/Eclipse on board, the JTC will not be going anywhere fast."

A Java Tools Community without Eclipse or JBuilder. Take a look at the various web services initiatives and see how participation of one or more key members in a specification is enough to guarantee its success over competing specs. Java Tools includes BEA, Compuware, Iopsis Software, JetBrains, Oracle, Quest Software, SAP, SAS, and Sun Microsystems. To get these companies to join in a common effort is laudable. But the question remains, how successful or effective can an organization dedicated to unifying Java toolability be without IBM and Borland?

Although IBM is not participating, the JTC web site was able to obtain the following quote from Skip McGaughey, Eclipse Chairperson. "Eclipse supports any industry activities that support tool integration and interoperability, [a]nd I see the JTC as a strong industry initiative to achieve those objectives." As for JBuilder, George Paolini explains on the Borland Developer Network site that "Borland has been involved with the organization since September 2003 and was instrumental in encouraging the strong alignment between the JTC and JCP. To date, however, the relationship between the JTC and JCP is vague at best. There is no mechanism by which the JTC can actually influence any part of the JCP process, without some set of changes to the JCP structure itself. Consequently, Borland has decided to await a formalized roadmap and process between the JTC and the JCP before making a decision to join."


Also featured in Projects and Communities today, the Java Communications community spotlights Mobicents: Instant Messaging Portal which "enables IM with subscription policies, inbound filters, forward broadcasting or rotation, as well as pattern triggered URL calls. [For example, ] When a new article, blog, or website has been updated, Mobicents can send out a IM notification based on user profiles and access."


In today's Weblogs , David Walend writes about Coupling in Software Architecture . He has a nice summation about different approaches which he introduces by saying "Coupling in software architecture seems to form a spectrum, based on what has to change to make the system do something different. At one end of the spectrum are dissociated ubiquitous services, like those envisioned by JXTA. At the other end are the highly-coupled systems of architectural nightmares. In between I've identified configured services, component systems, and client-server systems. Are there other styles in the spectrum? Is this a valid view of them, or should I be thinking about something else entirely?"

John Mitchell points to an article and asks if it is true that "women in technology remain invisible" and asking, if so, how we might address it in Talibanism in Technology? In her trackback, Helga points to Some Smart Women You have never heard of.

In Is Client-Server Dead, Steve A. Olson writes "In the old client-server days, we used only two layers: data (based on SQL) and the user interface, which was proprietary. Is that approach now dead? Or are there times when this old fashioned approach to application development is applicable?