In parts 1 and 2 of this series we identified the Eclipse and NetBeans open source IDE platforms as targets for embedded development tools; the difference in how embedded developers are impacted differently from embedded tool developers; how both platforms were initially developed without any focus on the needs of embedded developers, and we explored the reasons embedded tool developers are considering and migrating their development tools to an open source IDE platform.
Both the NetBeans and Eclipse projects began as ava development environments and both evolved into platforms that support a wider array of software products. Both platforms have been actively supported and evolving open source projects that have competed and coexisted together for the past decade and this has led to a level a parity between the two platforms. From the perspective of a tool developer, applications are built the same way on either platform – the difference is in the specific terminology and tools. For example, NetBeans uses modules while Eclipse uses plugins. Both platforms support extension registries with extension points to contribute extensions to the core system. Both IDE platforms require a JRE (Java Runtime Environment) to be installed and running on the host system. Because both IDEs run on a Java Virtual Machine, they are both able to target a variety of operating systems and both platforms are tested against a similar set of operating systems including Windows, Linux (e.g. Red Hat, Ubuntu), Sun Solaris, Macintosh OS, and others.
From the perspective of an embedded developer using a development toolset based on either platform does not require the embedded developer to even know which platform the tool is based on. Each downloadable toolset we tested was only available as a single install package that included all of the necessary core components and needed plugins or modules. By packaging the IDE in a controlled install package (as opposed to providing a set of modules or plugins to add to a set of core IDE versions), the tool developer hides from the embedded developer the complexity inherent in downloading or updating the core IDE along with all of the necessary support plugins or modules. As there is only a single NetBeans-based development toolset at this time, there was no opportunity to compare it with other similar embedded development tools based on the same platform, but the look and feel for the installation of the NetBeans-based toolset was similar to the Eclipse-based tools.
During the process of installing multiple Eclipse-based development toolsets, multiple instances of the underlying Eclipse IDE runtime were installed on the workstation. Each instance appears to act independently of the others such that different settings for one tool did not change the settings in another tool that was based on the same platform. In fact, each development tool was based on a different version of the platform. There was no obvious method for updating the IDE platform underlying the embedded toolset, but this makes sense as each tool provider needs to be able to control the variability of the platform so as to be able to provide competent support across a limited range of configuration.
Another reason for bundling the core components with the vendor specific extensions is as a consequence of the tool developer making changes to some of the standard components of the platform. For some toolsets, the tool developers chose to modify some of the standard components to improve the usability of the tools, most notably those for debugging an embedded target. While a number of tool developers indicate that they have future plans on making their tools available as plugins or modules, it is not clear to us that supporting the explosion in configurations of core IDE, host system, target processor, and plugin versions would make that a practical choice as it is impossible to force all embedded developers to use the latest version of the development tools.
There are three system-level considerations consistently identified by tool developers for choosing either Eclipse or NetBeans for embedded development tools beyond a feature by feature comparison of the two platforms. One system-level consideration is whether the tool provider’s third party tool partners are using the same platform. By providing the tools on the same platform, each of the tools within the development ecosystem gain the integration benefits of using a common infrastructure. The Eclipse platform has a seven year head start over NetBeans in supporting embedded development tools, and the Eclipse Foundation claims that there are over 50 embedded companies using the platform for their development tools. On the other hand, if a single company is providing a complete tool chain for their silicon products or they have coordinated with their tool partners to use NetBeans, then they have the opportunity to rely on the platform that is reported to be easier to learn and to use.
NetBeans is generally acknowledged within the user community to be more focused and easier to learn; in contrast Eclipse is considered a general platform that enables it to better support a wider range of projects. It is a classic simple ease-of-use versus complex flexibility trade-off. Providing complete install packages helps mitigate the configuration complexity for both platforms. The differences in the file, menu, and presentation architectures are open to debate as to whether one is better than the other or they are just different. In any case, there is a learning curve for adopting either platform. This difference between focused and jack-of-all-trades projects plays to the third system level consideration of how will new features work their way into future versions of the platform.
Eclipse has a heterogeneous embedded community that consists of many companies with differing views on how the platform should evolve forward. As a result, ideas and software come from a wider variety of embedded sources into the Eclipse platform, and there will be conflicts in similar approaches that must be resolved. In contrast, by being an early embedded adopter for NetBeans, Microchip gains the benefits of using a more focused IDE platform while providing a dominant voice, even if only temporarily as other tool developers adopt the platform, for establishing priorities for embedded features that should be integrated into the core platform. A trade-off for being an early embedded adopter though is that new innovations for the NetBeans platform will come from a much smaller group of companies than is available for the Eclipse platform.
An important outcome of embedded development tools leveraging either of the open source IDE platforms is that embedded developers have a greater chance to much sooner be able to take advantage of successful new innovations created for application developers. For example, the adoption of IDEs for embedded development tools lagged the application development world by ten years or more. A reason for this lag is that the embedded tool market is greatly fragmented – especially when compared to the application market. Whereas the application market has a handful of operating systems and dozens of processor targets to contend with, the embedded market is supported by over 80 different processor vendors, each with a range of processor targets that optimize and trade-off different performance constraints.
The small audience for each of a wide range of application specific and optimized embedded processors eliminates the practicality of investing precious engineering resources to incorporate evolving IDE functions and features in a proprietary platform. Instead, the open source platform approach allows the embedded development tools to more easily leverage and deliver new features without redirecting the engineering resources needed to improve specific tool features that address the real-time and variable environmental issues that makes developing embedded systems so different from application software. Using an open source platform allows a tools group to avoid expending resources on emerging IDE features and focus more of their resources on creating differentiating engineering features that better target the needs of embedded developers and set their toolset and silicon apart from the rest.