Past, Present, and Future

My first experiences with Eclipse stretch back to the days of IBM WebSphere Studio 3.0 (based on Eclipse 1.0) when it was just starting to migrate from the then-current Visual Age for Java development environment. I can still remember the frequent patches that were applied, and the fact that every time you added resources to a project, you had to perform a manual refresh to pick up the changes.

A lot has happened over the last five years. Some of the more notable highlights for me were:

• Linux being supported as of Eclipse 1.0
• Mac OS X being supported as of Eclipse 2.1
• Transition to OSGi and creation of RCP as of Eclipse 3.0

In short, the Eclipse platform just keeps getting better and better with each release; and this is just the core platform. The other toolsets (Data, CDT, WebTools etc.) are coming along in leaps and bounds too.

Eclipse itself is not the only thing that's developed. The community has grown over the years; various EclipseCon and other conferences have been run; there's a healthy supply of questions (and answers) on newsgroups and mailing lists alike. Who could have predicted the success of companies as diverse as NASA and Adobe using the Eclipse platform just a few years ago?

Eclipse has also been one of the forerunners in the development of consolidated application platforms: the ability to have two or more applications (or sets of functionality) blended into a single install. The Rational suite of tools suite of tools exemplifies this; even a few years ago, the tools for bug reporting, use case management, and UML design were all separate applications that couldn't easily talk to each other. Now, they are based on Eclipse (or will be in the future) and you can (technically) mix and match the functionality in the same application. Of course, they're focused at the developer level -- but user-level applications like Lotus Notes are going to make it much easier to integrate other Eclipse-based functionality (instant messaging, VoIP, news readers) into a client desktop application.

I've often noted in the past that Mac application development is successful because of a very robust application framework (AppKit). Java has never had such an application framework (unless you count java.applet.Applet) to bring flexibility and functionality. Even the advent of Swing didn't bring an application framework; it was merely a UI framework, and emulated the worst of the Windows UI with its MDI-type JDesktopPane interface. (Remember StarOffice using it and forcing everyone to have their own desktop/navigator? Remember how successful that wasn't?). Now, we have platforms like Eclipse (and NetBeans) that provide a more holistic view -- including basics like document and resource manipulation combined with user interface controls and selection services. Had we had this level of functionality for general applications five years ago, Java on the desktop might have succeeded instead of being dominated by Windows APIs. It's only because of these client-side platforms that Java applications on the desktop are starting to take off again; this time, though, with stiff competition on .Net and more recently AJAX-based web applications.

One of the unique things about Eclipse is that as it's based on a highly modular architecture from the ground up. It's possible to create applications that are either text-based or GUI-based, but still use the same code underneath. This gives Eclipse-based systems a strong advantage over others. It's possible to have the same code running in a fat client, or on a server; and more recently, to generate not only web-based UIs but also heavy AJAX applications. With the advent of GWT, you only ever need to know Java, too. And as it's all Java, it can run on any platform you care to throw at it. Compare that with .Net applications, which tend to be implemented in C# on the client and then often switch languages by speaking XML to a Java-based server.

So what will Eclipse do for the future? Here's some important things to watch out for as they grow over the next five years:

• Server-side Eclipse/OSGi applications. Servers must be up all the time, and most application servers support the idea of hot deploying new versions of code without taking the server down. There's still relatively few server-side applications (as a proportion of all Eclipse-based systems) but IBM has migrated its WebSphere Application Server to run on OSGi, and several open-source application servers are in the process of investigating OSGi. This market will probably eventually be huge, possibly larger than Eclipse/RCP in the future.
• Toolkits for AJAX-based web applications. OK, so not directly an Eclipse phenomenon, but I fully expect to see this taking off further in the future. I don't believe that all applications will necessarily become web-based, although I do use web-based apps like Google Reader and Google Mail frequently. The reason I don't think everything will be AJAX based is that there's still a need for disconnected applications (I'm sitting on a train writing this, for example) as well as ones which can interact with local data (files, databases) without the need for configuring a server. But what we will see, in the next few years, are design patterns emerging (like the birth of the Servlet API) that will allow data and application paths to be represented as Eclipse components, with an AJAX layer computed on the fly. For example, it should be relatively simple to create a JFace TreeViewer AJAX front-end; and then the code I create should work in both Eclipse/RCP (on the client) or via a TreeViewer-AJAX bridge (via a web browser). Tools like GWT are a starting point towards that goal.
• Mobile devices. There's probably more power in your mobile communicator clipped to your belt (do people still do that?) or in your pocket than in your first 8-bit computer; possibly more than are based on the Mars rovers that NASA is controlling with an Eclipse app. This trend will continue, but so will connectivity. While dialling up was a slow process even a couple of years ago, these days, devices are connected (or connectable) to the internet most of the time. Connectivity from a mobile device is not dissimilar to dial-up modems prior to broadband, but in the coming years, much faster broadband speeds are going to occur, as are increased speeds to mobile devices, which in turn makes it possible to install and run applications on your mobile device. I'm betting that a cross-platform solution, like eRCP is going to play a strong role in the future. Currently, it's limited to certain types of devices (Windows Mobile, Nokia Series 60/80), although it's being constrained by the lack of a free JVM on most of these devices.
• Distributed computing. The OSGi works well in a single VM, but there's no reason why it can't work in a more distributed environment. It has the advantage that the OSGi engine could easily evolve to support distributed computing; after all, the interfaces between bundles are already well exposed (and the internals hidden), so providing a inter-process mechanism like RMI (except without the constraints of having code-time impacts such as RemoteExceptions) would enable OSGi to scale horizontally.
• Distributed agents. With a distributed architecture, there's no (technical) reason why an OSGi bundle couldn't act as its own autonomous agent. After all, it can be stopped and started on the fly, and the JAR can be transported (let's face it ... that's what the update manager does at present in a simplified form) so why not extend the same to bundles as well? Perhaps more data is needed on a remote machine, or it's connected to better resources, so an agent could move from one OSGi framework to another.
• Embedded devices. There's a lot of technology in the home, but most of it is inaccessible to the end user. I'd expect OSGi to make greater in-roads here, and at the same time, allow devices to be controlled (and communicate between themselves). Look out for the Zigbee and Wibree APIs.
• Server stacks. Amazon's EC² service is an example of making money from renting out computing power as a service. But there's a lot to maintain, and if something goes wrong, you have to fix it yourself. Commodity OSGi application servers, if they become ubiquitous, will allow hosting agents to run many OSGi bundles for a simple charge. Need to upgrade your application? Simply upload a new bundle. Add new spam filters? Upload new configuration for a bundle. And because the API is very simple (unlike, say, the whole J2EE space) it makes it very easy to have little things that do a lot. Security is still one area which will need to be expanded before this is likely to make a commercial impact, but in the not too distant future there will probably be internal departmental OSGi servers to host bundles.

It will be interesting to see what becomes of those predictions; look back in five years time and see how many hit or miss the mark. Whatever happens, though, it's an exciting time to be in the industry.

Until Next Time,
Alex Blewitt
alex@eclipsezone.com