eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
With open-source eclipse gaining ground as a foundation for nonpartisan software development, SlickEdit Studio 2.0 from SlickEdit Inc. demonstrates the opportunities and challenges that Eclipse presents to toolmakers and their customers.
The versatility and power of SlickEdits proven source code editor find a comfortable new home in the Eclipse integrated environment, and the included GNU C/C++ and Java compilers and debuggers enable SlickEdit to offer a complete workshop instead of only a core developer tool.
Released in January for Windows NT/XP/2000, with a Linux version planned for next quarter, the $849 package (including one year of maintenance and support) is not the free lunch that some developers wrongly expect from all open-source offerings. Its cost is competitive, however, with the $1,079 entry-level price of Microsoft Corp.s multilanguage Visual Studio .Net 2003 Professional Edition or the $500 Java-only JBuilder X Developer from Borland Software Corp.
However, SlickEdit Studio doesnt contain the extensive portfolios of project types that populate the palettes of those competing integrated tool sets. To some extent, this is a case of “Be careful what you ask for. You may get it.” In past reviews, eWEEK Labs has remarked on the dramatic shift in the nature of development tools as theyve evolved from weapons that point in any direction to partners in the promotion of specific application platforms and middleware. SlickEdit Studio, like Metrowerks CodeWarrior, is more of a tool for coders who prefer to roll their own or shop the free market for the components of their solutions.
The preconfigured projects that SlickEdit Studio volunteers to jump-start are C/C++, Java, Eclipse Plug-In and the “Simple” project (which is just an empty container). These choices seem surprisingly few and uncomplicated only because weve gotten so used to the more aggressive platform agendas, and their baroque project types, that we confront when we try to do almost anything in todays other high-end environments.
When we started writing code, SlickEdits source code editing engine and Eclipses support environment worked together as if theyd always been a team. Code completion tools were not merely responsive in offering options but informative as well. For example, typing “System.o” in a Java file not only showed “out” as the likely completion but also popped up an explanation that System.out is the standard output stream, offering “System.out.println(data)” as the typical idiom for output in stand-alone applications.
The studios side panels, displaying tree diagrams of application structure and other navigation aids, were responsive to our keystroke-by-keystroke changes to Java source files. As soon as we began a function or variable definition, even before we finished typing its name, the Package Explorer pane was tracking our actions. As soon as we hit the close-paren key after a functions arguments, or the “=” key when assigning a numeric variable, the corresponding piece of our puzzle appeared in the Outline view.
Debuggers and other tools generally lived up to our expectations, although error diagnosis after compilation failures was less informative than what we typically see in modern tools. Product documentation is clearly a work in progress. SlickEdits editing capabilities are extensively explained, but there is not enough project life-cycle documentation.
Technology Editor Peter Coffee can be reached at [email protected].