Historically, development tools have been tied to a specific operating system. Yet, some vendors have seen success in building products that target multiplatforms. A new phenomenon, a modular open-source project called Eclipse, is now changing the way things work. In fact, it's forcing vendors of IDE tools to adjust their long-term plans to take advantage of, or compete with, Eclipse.
This doesn't mean that Eclipse will have an easy ride (Fig. 1). Well-established products like Wind River's Tornado, Green Hills Software's Multi, MetroWerks' Code Warrior, and Microsoft's Visual Studio will definitely give Eclipse a run for its money. They're optimized for the environments that they support and have a large following. Wind River's Tornado and Microsoft's Visual Studio dominate their target operating-system (OS) markets. For Tornado, it is Wind River's VxWorks users, and for Visual Studio, it is Microsoft Windows.
Products like Green Hills' Multi and MetroWerks' Code Warrior cover a range of target platforms. This includes various processors and OSs, such as Linux, VxWorks, and Windows. Developers prefer this multiplatform approach because their experience transfers well to new projects. This holds particularly true when the target OS remains the same but the underlying target hardware changes.
Eclipse is also target agnostic, and, like most integrated-development-environment (IDE) products, programming-language agnostic. Eclipse's Java roots also make it host agnostic. This is one place where Eclipse differs from most alternatives. Eclipse is written in Java, so a host platform must run Java to support Eclipse. On the other hand, most IDEs are written in C/C++. Therefore, the IDE is portable to most systems that support a C compiler. Unfortunately, this is only part of the host requirements. A graphical user interface is also necessary, so at this point, Java's platform portability will come into play. Eclipse requires SWT (Standard Widget Toolkit).
Moving an IDE from a Windows host to a different graphical environment like X-Windows on Linux can be daunting at best. It's one reason why most IDE vendors support a small number of host platforms, often limiting that number to one—Windows. This is also why the success of Eclipse is so important to the Linux realm. It's not surprising that Linux companies, like TimeSys, are utilizing Eclipse as their system-oriented IDE.
IBM uses Eclipse as the development tool for its WebSphere product line. This is actually where the Eclipse project started before being turned into an open-source project.
IBM had a long track record of building flexible IDEs, including those that support SmallTalk. The SmallTalk programming language didn't become as hot as C++ or Java. However, many features in the SmallTalk IDE system found their way into Eclipse, such as the ability to extend the IDE. IBM also uses Eclipse to cover a range of languages and target environments from Web servers to embedded Java applications.
Eclipse started out as a Java IDE implemented in Java. It was an alternative to Sun's successful Sun ONE (Open Network Environment) Studio. The two provide similar services and run on most systems that support Java. But, Sun ONE Studio uses AWT (Abstract Window Toolkit), while Eclipse employs SWT (Standard Widget Toolkit). Another big difference is that Eclipse supports a range of programming languages, including C/C++ and many OSs, while Sun ONE Studio specifically targets Java.
Requirements for IDEs are now much more demanding than in the past. At one time, a basic IDE included a text editor, a project build system, and a debugger. The current IDEs have the same core tools, but even the simplest IDE exhibits numerous enhancements that reflect today's development environment.
For example, many programming languages are used for embedded developments like C++ and Java. These have class hierarchies that can be presented in a tree structure, showing developers the capability of classes. Also, the graphical interface is often enhanced so that source code for a particular method or procedure within a class can be easily viewed. Some systems can even view code where the method or procedure is employed. As with many new IDE features, this approach performs actions that were manually handled by the developer by searching text files for a particular string. Having the IDE do the job often works better because it can take context information into account. For instance, a function foo for class X and Y will be different. A text search for foo finds all instances, but a context-sensitive search could isolate functions for class X and ignore those of Y.
IDE project management refers to the collection of files and build procedures necessary to create an application. On the other hand, project management of the developers would keep track of implementation milestones and developers' time. The former is included in most IDEs, at times reaching very high levels of configurability. For example, multiple debugging and test run configurations can often be created for a project, allowing a developer to quickly test changes under different conditions.
Most IDEs have hooks for the time-oriented project-management tools as well. In fact, some systems are starting to incorporate more collaboration tools, giving developers the ability to make the IDE the center of the development universe.
Another component that makes this centrist view apparent is source-code version management systems. CVS (Concurrent Version System) is one example. In many cases, IDEs come with their own version control system, but they typically support third-party products as well.
This growth in IDE complexity has resulted from the increased complexity of application environments. Interacting with an OS is rarely a matter of a few dozen application-programming-interface (API) definitions. Instead, an extensive framework is typically presented to a developer, who can then choose from a subset of APIs to deal with. The scope of these frameworks can be extensive.
The Java 2 Enterprise Edition (J2EE) and Microsoft .Net are two major frameworks that application developers can work with. Both have an enormous number of classes that provide thousands of functions. Taking in an entire framework of either of these platforms is an immense task, but luckily the majority of developers can deal with a subset. Most IDEs help by providing a hierarchical view of services so that developers can pick and choose those needed for their current programming chores.
OPEN PLUG-IN INTERFACE
The hooks to provide many of the IDE features are often formalized for a particular product. Eclipse is based on this idea of plug-in extension, but it's not unique. For example, Green Hills Software's Object Structure Awareness (OSA) Toolkit provides an interface to Green Hills' Multi debugger, allowing access to OS and application internals through a scripting or browser interface.
Most sophisticated IDEs have this feature to some degree, although it's often available only to a vendor's partners. Average programmers couldn't create plug-ins for the latter, but they can and do when the standards are public.
The Eclipse plug-in architecture is public and well documented (Fig. 2). There's even a plug-in development environment (PDE) that's part of the Eclipse package. It uses XML files to define the interfaces and configuration. The actual coding is created in Java. Of course, a plug-in can be an interface to a separate application written in any language.
Right now, the Eclipse plug-in architecture is the closest thing to an open standard. Microsoft's plug-in architecture is a standard for its very popular Visual Studio. The plug-in interface description is available, but the source to Visual Studio is not.
Plug-ins can bring a new feel to an IDE. For instance, UML (Universal Modeling Language) vendors I-Logix, Telelogic, and IBM's Rational have or will be delivering plug-ins for Eclipse. Already, they have similar support for other IDEs like Visual Studio.
CUSTOMIZATION AND CONVENIENCE
Whether provided by plug-ins or as part of the base IDE, the number of features in today's IDE continues to grow. What used to be considered a new feature is now standard fare on most IDEs. For example, color-coded text editing and parenthesis matching is supported by most IDE editors. They make code writing more accurate, as many of the usual syntax errors are caught before a program is compiled. Even spellchecking is done to make sure variables are defined.
Context-sensitive tips are common now as well. This feature puts up a list of options based on what part of a word was entered. For example, if a function name is typed followed by a left parenthesis, the tip in a pop-up window will be a list of arguments for the function. Likewise, when typing the definition of a function, the tip that pops up would be a list of data types that can be used for the first parameter. Such a feature is a more flexible version of the templates originally available in some IDEs.
Context is everything when programming and views are added to many IDEs, such as Eclipse. A view is a named collection of windows. Default views typically include text editing, debugging, and project management. Typically, the user can create new views and put together any windows that would be useful to perform a specific task. For instance, testing views may have different windows than debugging views. Different test views allow the IDE to be customized to test various parts of an application. A window might also be provided through a user-created plug-in, which would provide testing facilities or show results of a test in a form not readily available using the standard test or debug tools.
Views can be even more useful when multiple monitors are employed. This type of development environment is becoming more common now that a single system can easily support this configuration and the price of the hardware is lower. As any developer will tell you, screen real estate is always at a premium Þ there's never "too much."
There's never too much documentation either, although it tends to be one area that's always deficient when it comes to creating it. The rise of frameworks has generated gobs of information about APIs, objects, and how things interact, all of which require sophisticated indexing systems to navigate the morass. Most IDEs now can incorporate help and documentation information from third parties. This is key when a plug-in architecture is used, because almost everything is added and there's very little in the base.
Luckily, documentation development tools are becoming easier to use. This is not to say that developers will use them, but professionals are more aware of the importance of good documentation for subsequent support and enhancements.
LICENSING IS IMPORTANT
It's worth discussing licensing details because of the way that Eclipse can be used. Most IDEs are owned by a specific company and they jealously guard the source code and distribution rights of the IDE, which is not the case with Eclipse. It has an extremely liberal licensing policy, allowing it to be turned into a closed-source product or a mixed-source product where proprietary components are distributed in binary form only. This can have a number of benefits for developers, as the proprietary components should work with any Eclipse implementation. Likewise, plug-ins designed for the generic Eclipse platform should work with the proprietary implementation.
IDE vendors using Eclipse benefit as well. Eclipse may not be at the top of the list for third-party plug-in developers right now, but it will be eventually. Previously, getting third-party support of an IDE took a good deal of negotiation and support on the part of the IDE vendor. This tended to limit the number of plug-ins available.
Finally, Eclipse can be used as an application platform. In many instances, companies might not want to distribute the source code for Eclipse or for their customization. The Eclipse licensing allows this to happen. In fact, many companies will want to take this approach not to keep things private, but to reduce tech support calls from overzealous users with programming experience. Still, it can be a useful bargaining tool if the source can be made available upon request.
LITTLE IDEs STILL SURVIVE
The type of IDEs discussed thus far are what most developers employ for 32- or 64-bit platforms. Some 8- and 16-bit IDEs retain the simplicity of earlier tools, foregoing integration with more advanced plug-ins. These are often used when projects are smaller, such as a single developer working on a single 8-bit microcontroller.
In other cases, these IDEs are a stepping stone to more functional products that can be utilized when a project becomes larger and more complex. For example, Microchip's PICkit 1 is a starter kit with the MPLAB IDE. It's possible to move to more sophisticated toolsets that include ICE (in-circuit emulation) support.
More compact IDEs aren't always spartan text editors. Features like color-coded text and real-time, context-sensitive tips are always creeping in. Still, one reason for these IDEs is the limited resources available to create them. Another is the availability of open-source IDE platforms like Eclipse and KDevelop.
Proprietary IDEs remain important because of features they provide. For instance, many DSP IDEs offer data graphing facilities like Texas Instruments' CodeComposer Studio (Fig. 3). These types of features will eventually find their way into other IDEs, but until more companies move to open platforms like Eclipse there will be a need for vendor-specific IDEs.
Most developers tend to prefer the flexibility of the larger, more robust environments like Eclipse. It will be interesting to see how other IDEs will fare versus Eclipse given its open-source nature and the support it's received. Developers are already pressed for time, so the ability to use the same development environment for a number of projects can have significant benefits.
|Need More Information?|
Green Hills Software
QNX Software Systems