1. Eclipse Paolo Gasti

2. The Problem ■ There is the need for a new development environment ■ It has to help software designers and implementers to do their jobs faster and easier ■ There are so many approaches to software development that no tool can be the solution ■ We need to fill the blank left by tools such as Emacs

3. What is Eclipse? “Eclipse is a kind of universal tool platform – an open extensible IDE for anything and nothing in particular.” – eclipse.org Eclipse is more than a Java IDE… “In many ways Eclipse is the Emacs for the 21st century.” – Martin Fowler

4. The Way to Eclipse 1999 2003 200020012002 Eclipse 19981997 Nov Open Source announcement VisualAge/Java VisualAge Micro edition March v. 2.1 Oct v. 1.0 June v. 2.0 June Tech Preview

5. Design Goals Provide an open platform for the construction of tools for application development Support an unrestricted set of tool providers Support tools to manipulate arbitrary content types (language neutral) Seamless integration of tools within and across different content types and tool providers Availability on a wide range of platforms

6. Plug-in Architecture Goals ■ Easy to develop –Java Development Tools + Plug-in development environment ■ Scale-up to hundreds of installed plug-ins –It tries to reduce start-up time –Out-of-the-shelf Eclipse consists of 80 plug-ins –Lazy loading ■ Easy to discover, install, and update –install/update support ■ Easy to manage an installation –managed configurations

7. Why Open Source ■ Many partners can contribute during all the life cycle of a tool ■ It provides less dependency on a single vendor ■ Every partner can implement its own product without the need to stipulate any contract with IBM ■ The community can –provide feedback to the developers –submit patches –answering user’s questions

8. Implications ■ Vendors can concentrate on their own special area of expertise providing higher value ■ Improved integration of tools from multiple vendors ■ The interface can be customized to fit any function, format or style ■ Plug-ins can be free or commercial ■ A flourishing business gravitates around Eclipse (WebSphere etc…)

9. Eclipse Architecture ■ Plug-in, the smallest unit of Eclipse function ■ Eclipse is a platform with a small runtime Kernel and several layers of plug-in built on it ■ Everybody can be a tool smith ■ SWT (Standard Widget Toolkit) offers significant advantages over AWT and Swing Platform Extensible IDE IDE Plug-ins Runtime Plug-ins

10. Eclipse Architecture Java VM PlatformJDTPDE SDK Resources, Team, Debug, Help, Update, SWT, UI,… Compiler, Refactoring, JDT UI, JDT Debug,… PDE Core, PDE Build, PDE UI

11. Eclipse Architecture Platform Runtime Workspace Help Team Workbench JFace SWT Eclipse Project Java Development Toolkit (JDT) Their Tool Your Tool Another Tool Plug-in Development Environment (PDE) Eclipse Platform Debug Update

12. Eclipse Platform Start Up ■ Eclipse Platform Runtime handles start up –Discovers plug-ins installed on disk –Matches up extensions with extension points –Builds global plug-in registry –Caches registry on disk for next time

13. Eclipse Platform ■ The Platform is divided into components ■ The standard components, provided with the installation file freely downloadable from eclipse.org, are –Ant – Universal Compare –Core– Release Engineering –Platform CVS Integration– Debug framework –Platform help system– Text editor framework –Support for Platform scripting – Platform user interface –Integrated search facility – WebDAV integration –SWT (Standard Widget Toolkit) – Generic Team support –Dynamic Update/Install Service

14. Plug-in Architecture ■ Extension point - named entity for collecting “contributions” ■ Extension - a contribution ■ Each plug-in –Contributes to 1 or more extension points –Optionally declares new extension points – programmers can extend good plug-ins to fit their needs –Depends on a set of other plug-ins –Contains Java code libraries and other files ■ Details spelled out in the plug-in manifest –Manifest declares contributions –Code implements contributions and provides API

15. Extension Points Principles ■ Let others contribute to your contributions ■ Lazy loading rule: load extensions only when they are about to be called ■ Contributions do not –override existing behavior –remove or replace existing component –harm existing or future contributions

16. Extension configuration in XML … <page id=“com.example.myprefpage" icon="icons/image.gif" title=“My title" class=“com.example.mywizard"> … Extension contribution Extension point definition

17. Plug-in Manifest <plugin id = “com.example.tool“ version = “2.1.0” name = “Example Plug-in Tool" class = "com.example.tool.ToolPlugin"> <page id = "com.example.tool.preferences" icon = "icons/knob.gif" title = “Tool Knobs" class = "com.example.tool.ToolPreferenceWizard“/> Declare contribution this plug-in makes Declare new extension point open to contributions from other plug-ins Location of plug-in’s code Other plug-ins needed Plug-in identification

18. Contribution architecture My Plug-in class GreyFilter extension-point imageFilters extension contributes ■ Declares extension point: ■ Declares interface: interface IImageFilter { Image filter(Image image); } ■ Contributes extension: …class=“GreyFilter” ■ Implements interface: class GreyFilter implements IImageFilter { } interface IImageFilter calls implements ImageViewer Plugin

19. Contribution architecture My Plug-in class GreyFilter extension-point imageFilters extension contributes ■ Declares extension point: ■ Declares interface: interface IImageFilter { Image filter(Image image); } ■ Contributes extension: …class=“GreyFilter” ■ Implements interface: class GreyFilter implements IImageFilter { } interface IImageFilter Instantiated via reflection calls implements ImageViewer Plugin uses

20. Plug-in Activation ■ Each plug-in gets its own Java class loader and has its own class path –Delegates class load requests to required plug-ins ■ Contributions processed without plug-in activation –Example: Menu constructed from manifest info for contributed items ■ Plug-ins are activated only as needed –When a class is loaded by the class loader  Scalable for large base of installed plug-ins Java UI UI Resources Java Core requires

21. More than a Java IDE Eclipse vs. NetBeans ■ Languages –C# –C/C++ –Python –Cobol –Php –Several UML ■ Programming Tools –ANTLR Parser Generator –Graphical Editing Framework (GEF) –AspectJ tools –Modeling (EMF) –Several DB tools –Jalopy Java Source Code Formatter –Japple – RAD –Jasper report designer –Lomboz –Java Spider ■ Source & configuration mgt. –Perforce –Microsoft VSS Plug-in –Clearcase –Stellation ■ Web development –Sysdeo - Eclipse Tomcat Launcher –WebLogic manager –Several Struts –Spindle for Tapestry ■ Testing / Performance –Resin Plug-in –MockCreator –Solex –Hyades http://www.eclipse.org/community/plugins.html

22. The UML 2 plug-ins ■ There are several UML 2 compliant plug-ins ■ Most of them provide support for –Reverse-engineering of source code (often also from binaries) –Code generation –Code Synchronization –Code analysis –Documentation generation –Automatic diagram altering after code altering

23. Slime UML 2 plug-in ■ Guides the team through all the development process ■ It is very light-weight: only 1 MB

24. Refactoring Support ■ Refactoring is changing the structure of a program without changing its functionality ■ There are many reasons to do refactoring –The team of a project disappears and you need to add/improve the functionality of its (quite obscure) code –A new requirement is introduced because of a design mistake or an iterative approach (such as XP) –Once familiar with this tool, a programmer can generate code in the first place, then use it to conform its code to some standards (such as the use of getter/setter methods)

25. Refactoring Support ■ Eclipse provides three types of Refactoring –Physical organization and renaming –Logical organization at the class level –Change the code within a class

26. Physical organization and renaming ■ Avoid the need to edit many files to update import and package statements ■ Automatically checks the context, not only the names ■ Allows to automatically –Rename fields –Rename variables –Rename classes and interfaces –Move packages and classes

27. Logical organization at the class level ■ While not as useful as the other kind of refactorings, it allows to automatically –Turn anonymous classes into nested classes –Turn nested classes into top-level classes –Create interfaces from concrete classes –Move methods or fields from a class to a subclass or superclass

28. Change the code within a class ■ Allows you to automatically –Turn local variables into class fields –Turn selected code in a method into a separate method –Generate getter and setter methods for fields –Change method signature (doesn’t fit exactly here…)

29. Refactoring Support ■ The power of Eclipse’s refactoring capability is to allow an user to do a safe refactoring with some mouse clicks

30. Eclipse’s Cons ■ Windows-centric (ActiveX, OLE) ■ Slow and often unstable under Unix ■ Forces developers to use its own directory structure ■ Sun does not like it exists, having its own NetBeans (but Eclipse is supported by IBM…)

31. Case of Study: the JavaCard Plug-in ■ It offers the complete class library of the JavaCard platform ■ Allows developers to simulate IBM’s smart card hardware ■ Offers an advanced debugger ■ Lets Eclipse connect to real smart cards ■ Offer complex functionalities

32. Case of Study: the JavaCard Plug-in ■ Offers concrete advantages against the stand-alone version ■ The Java Editor provided with Eclipse is much better than the editor provided with JavaCard ■ Allows the developer to edit and test the code with the same interface ■ Can be used together with other tools such us an UML 2 plug-in ■ Shows the power of the Eclipse platform when developing highly specialized software

33. Summary ■ All functionality is provided by plug-ins and fragments –Includes all aspects of Eclipse Platform itself ■ Contributions are made via extension points –Extensions are created lazily ■ Plug-ins are packaged into separately installable features –Downloadable

34. Summary  Everybody can contribute plug-ins  Every programmer can be a tool smith  Creating opportunities for further extension makes it possible for the tool smith to benefit from the work of others  The same environment can be used to develop applications and to develop tools for itself

35. References ■ Refactoring For Everyone by IBM (http://www- 106.ibm.com/developerworks/opensource/library/os- ecref/) http://www- 106.ibm.com/developerworks/opensource/library/os- ecref/http://www- 106.ibm.com/developerworks/opensource/library/os- ecref/ ■ Eclipse Platform Technical Overview – eclipse.org ■ The Mathaino Project - Department of Computing Science, University of Alberta ■ Eclipse Platform on-line help ■ Omondo whitepaper – www.omondo.com www.omondo.com ■ Eclipse.org plug-ins documentation - http://www.eclipse.org/community/plugins.html http://www.eclipse.org/community/plugins.html ■ OOPSLA 2003 documentation – www.oopsla.org www.oopsla.org