Migration of Eclipse based products :- Need of time

Introduction
This paper is intended to describe newer features of Eclipse and Eclipse based projects. Paper also describes why one should migrate from older Eclipse runtime to newer one. To explain these points, I will be taking example of our team which is doing migration of our product from Eclipse 3.2 to Eclipse 3.5 runtime.
Motivation
From past three year, our team is working on Eclipse based RCP product. This product has been built on older version of eclipse. Runtime for our product is based on Equinox 3.2, which is implementation of OSGi R4 core framework specification. Our project uses lot of Eclipse based projects, such as EMF, GEF, GMF, etc. All these project plug-in sets are based on Eclipse 3.2 runtime.
Few days back we have decided to migrate our product to Eclipse 3.5 runtime. Before making this decision, we had lot of discussions on migration. We have discussed pros and cons of migration. At one end we could see all the good features of newer Eclipse and at other end changes we might have to make lot of changes in our product. Finally after lot of debate, we have started migration process. Basic motivation behind the migration is “Newer Features provided by Eclipse 3.5”. This paper intended to document reason behind our motivation. In other words, this paper will explain “What's new in Eclipse 3.5”. Please remember that I am not just focusing on Eclipse 3.5 but I will be also covering some Eclipse based projects which we used in our product.
Background
Before going into details of Galileo's (Eclipse 3.5) features, I would like to describe what eclipse is in short. Definition of Eclipse popularly known to everyone is “Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system”. But I personally like other definition of Eclipse, and which is “Eclipse is framework for everything and nothing in particular”.
Most software developer knows that Eclipse is a popular Integrated Development Environment (IDE) for Java. As Eclipse is free and stable, lot of programmers now a days are using Eclipse as an IDE. It is written primarily in Java and can be used to develop applications in Java and, by means of the various plug-ins, in other languages as well, including C, C++, COBOL, Python, Perl, PHP, and others. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C, Eclipse JDT for Java and Eclipse PDT for PHP.
Eclipse began as an IBM Canada project. It was developed by Object Technology International (OTI) as a Java-based replacement for the Smalltalk based VisualAge family of IDE products, which itself had been developed by OTI. In November 2001, a consortium was formed to further the development of Eclipse as open source. In January 2004, the Eclipse Foundation was created. Eclipse was originally released under the Common Public License, but was later relicensed under the Eclipse Public License.
Most people think that Eclipse is only a Java IDE, but it's not just an IDE, it is complete framework. It is based upon OSGi (Open Service Gateway initiative) standard. This standard defines specification for creating component based architecture over java runtime environment. Eclipse has implemented OSGi specification using Equinox project. Eclipse supports plug-n-play architecture and it allows bundle or plug-in to load on demand. In programmer's jargon, it is called as lazy loading.
There are lots of project build over Eclipse platform. Most popular projects are EMF (Eclipse Modeling Framework), GEF (Graphical Editing Framework), BIRT (Business Intelligence and Reporting Tools), etc. All development toolkit, such as Java Development Toolkit (JDT), PHP Development Toolkit (PDT), C/C++ Development Toolkit (CDT), etc is also based on eclipse framework.
So remember Eclipse is not just an IDE, but it is framework containing some built in tools.
Drivers for moving to Eclipse 3.5 :
As our older product was on Eclipse 3.2 runtime, we faced some limitation while implementing new features.
a) User Interface:
For development of basic user interfaces, we were using SWT 3.2. SWT (Standard Widget Toolkit) is cross-platform graphical widget toolkit for use with the Java platform. In newer SWT versions, eclipse has improved / added lots of user interface component. Improved StyledText widget, new system tray support, new Date widget, improved color schemes, new line drawing capabilities, effective drag-n-drop, effective browser support, improved copy paste support, etc are just some instances of improvement in SWT. In these three years lot of SWT APIs are changed for providing better control. Apart from these UI changes, SWT has improved lot on platform portability. Now SWT runs perfectly on newer Windows OS (operating system) versions, Linux, Mac OS, Solaris, HP-UX, etc. Now SWT runs on almost all bits of operating systems.
Eclipse has developed a framework called JFace on top of SWT. JFace is a UI toolkit that provides helper classes for developing UI features that can be tedious to implement. It is a layer that sits on top of the raw widget system, and provides classes for handling common UI programming tasks. It brings model view controller programming to the Standard Widget Toolkit (SWT). As the underline SWT widgets have improved, JFace is able to extract better support from SWT. Improvement in SWT leads to improvement in JFace.
Eclipse workbench is built up using SWT. Using newer version of SWT, Eclipse has improved workbench's look and feel. So by using newer graphical plug-ins of Eclipse, we are able to improve the look and feel of our application.
Migrating our product to newer Eclipse Runtime, user interface of product has improved. Also due to use of new graphical library, we can implement newer widgets and improve existing user interface.
b) Restricted upgrade support:
Eclipse 3.2 was using Upgrade manager to upgrade eclipse plug-ins. Upgrade manager was also used for installing new plug-ins. In newer versions, Eclipse has come up with a new way for upgrading and installing plug-ins, which is called as p2. P2 stands for Provisioning Platform. Provisioning is a process of providing users with access to data and technology resources. The term typically is used in reference to enterprise-level resource management. P2 replaces the upgrade manager with simplified workflows. So it will be a lot easier to install new plug-ins and keep them managed. P2 also comes with concept of 'Bundle Pooling'. That means you can share plug-ins across multiple Eclipse instances. By using Bundle Pooling, you can reduce considerable amount memory and disk space. P2 automatically find out all the dependent plug-ins for running particular functionality and installed those automatically.
So by incorporating p2 in our product, we can provide better support for upgrade. Philosophy behind p2 project was, user should not install-uninstall eclipse multiple times, user should only upgrade existing eclipse. We wanted to have same principle in our product.
c) Incompatible newer plug-ins:
Eclipse 3.2 has been released in the June 2006. It was just third release of Eclipse using OSGi specifications. Now after three years Eclipse has come long way. In year 2007-08 Eclipse got lot of popularity. Lots of enhancement has been done in Eclipse. Lots of new project has been started in Eclipse Release Train. For example, Mylyn, BIRT, Eclipse RT, etc. Now a day’s Eclipse comes in lot of flavors such as Eclipse for J2EE, Eclipse for PHP development, Eclipse for Mobile platform(Pulsar), etc. Most of the newer projects or frameworks are not compatible with Eclipse 3.2 runtime. Also older Eclipse projects have came with lots of new features and enhancements. Most of these new features does not work in Eclipse 3.2. Also most of the new projects are not making their projects compatible with Eclipse 3.2. This has been biggest handicap for us. We were unable to include newer plug-ins or projects in our product. Migration to Eclipse Galileo enabled us to use newer Eclipse projects and frameworks.
d) Unavailability of Task management:
For providing task management, new project , called Mylyn, has started under Eclipse projects. It's open source implementation of the Task-Focused Interface. It provides an Application programming interface (API) for tools embedding the task-focused interface. Generally developer works on lots of modules simultaneously. Most of the tasks are need to be revisited. For example, in my project I have written code for writing file in simple text format. After one month my manager asked me to write all the files in XML format. To add this functionality, I have to modified code which write file in text format. Also I may need to modify all the references which are getting affected by change. In my projects there are lots of source files and thats why my most of the time will went in finding out right code to be modified. Mylyn would be helpful in such situation. Using Mylyn, I can create task (such as Text file writing operation) before working on that task. This task gets stored in my workspace. Mylyn records all the files or code fragment which are used while working on code. So whenever I want to modify any particular task, I can simply activate that task. After activating task, Mylyn will show only those code fragments which are added or modified while working on task. So you don't have to iterate over all the code to search right code. This is very good feature if you are working on large code base. You can integrate bug management system like Bugzilla, Trac, Redmine, JIRA, etc in Mylyn. This helps to integrate your bugs and code in one development environment. Also Mylyn allows you to share your tasks with other developers. So Mylyn focuses on improving productivity by reducing searching, scrolling, and navigation. By making task context explicit, Mylyn is also meant to facilitate multitasking, planning, reusing past efforts, and sharing expertise.
In our product, user has to manage lot of files and projects. So use of Mylyn could be beneficial for user. But lots of Mylyn features are not available in Eclipse 3.2. That's why task management becomes one of the reason for migration of our product to Eclipse 3.5.
e) Extended platform support :
As we already know, Eclipse is a platform independent framework. Although it is said to be platform independent, it doesn't support all the platforms. Eclipse 3.2 was supporting very less number of platforms. Also on some platform, Eclipse 3.2 was not providing all the functionality. There is a drastic improvement on this front in newer Eclipse. Now Eclipse has started supporting all the newer Windows OS, most of flavors of Linux, Mac, Solaris x86, S390, S390x, HP-UX. Now it also started supporting most of 32 bit and 64 bit platforms. Now due to newer implementation of OSGi specification using Equinox project, Eclipse has started running on most of mobile OS and embedded devices. This helps Eclipse to become more portable and platform independent in true means. It also helps in increasing acceptability of Eclipse.
Currently our product only runs on Windows OS. To increase the portability and acceptability of our product, we have to deploy our product on newer Eclipse runtime.
f) Generics support :
In our product, we have embedded lot of Eclipse based projects such as Eclipse Modeling Framework (EMF), Graphical Editing Framework (GEF), Graphical Modeling Framework (GMF), etc. Eclipse Modeling Framework (EMF) is an Eclipse-based modeling framework and code generation facility for building tools and other applications based on a structured data model. Our product uses EMF 2.2. But this EMF does not supports Generics. Newer version of EMF supports generics and it generates model code, which consist of Generics. But newer EMF version (EMF 3.5) doesn't maintain backward compatibility with Eclipse 3.2 runtime.
In our product, we have to use Generics feature to upgrade some of our existing tools. But for Generics support, we have to upgrade to EMF 3.5 and ultimately upgrade to Eclipse 3.5 runtime.
g) Zest :
Eclipse has started really promising project under Graphical Editing Framework (GEF) called Zest. Zest - Eclipse Visualization Toolkit, is a set of visualization components built for Eclipse. The primary goal of Zest is to make graph based programming easy. In our product, we have lot of graph like structures and we wanted to present these using better user interfaces. To fulfill this requirement, we can use Zest project. But as Zest doesn't support Eclipse 3.2, we have to migrate our product to Eclipse 3.5.
h) Better memory management :
Eclipse is based on plug-n-play architecture. That means only those components, in Eclipse's word Plug-ins, are loaded which are required. This makes Eclipse, memory efficient. But still Eclipse is having lots of memory related issues. Once plug-ins are loaded, they can not be unloaded at runtime. Eclipse manages all the system resources through Eclipse File System (EFS). So resource accessed through some Eclipse API need to managed properly and must be unallocated after use. In older Eclipse API, resources accessed through EFS was not memory efficient. But lot of improvement has been made to handle these memory leaks. Newer versions of Eclipse manages memory in far better way. Improvement in Eclipse API drives Eclipse based projects to work on memory management. For example, in EMF 2.2 one EObject was taking 120 bytes of memory but in EMF 2.5 one EObject is only taking 12 Bytes.