September 30
thand October 1
st, 2010 - Savona , Italy
Proceedings
Savona University Campus, University of Genova Via A. Magliotto, 2 - 17100 Savona, Italy
Abstract. The Eclipse Integrated Development Environment is a widely used platform for the development of Object Oriented Applications. Besides, Eclipse is an open source community and ecosystem whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across its lifecycle. The Eclipse-IT 2010 workshop is the fifth yearly meeting of the Eclipse Italian Community which includes both Universities and Industries, with the aim of joining researchers and practitioners, students and professionals, around the common interest in experimenting, extending, and supporting the Eclipse platform. Due to a special interest and running project, this year, the Conference hosts a special session on the Jazz cooperative development environment, based on the Enforcing Team Cooperation (ETC) Project. ETC involves many universities with the aim to bring together teams of students in order to develop software in a cooperative way. Based on the success of the previous editions, the Eclipse-IT 2010 will host four tracks (regular, student, industrial, and JAZZ applications) and three types of contributions are accepted: technical papers, student demo papers, experience in public institutions (P.A.) or industrial demos.
Organized by:
DIST - Department of Computer, Communication, and Systems
Sceince, University of Genoa
IBM
Eclipse Italian Community
Sponsored by:
IBM
Eclipse Community
S.P.E.S. S.c.p.a.
Published by: Eclipse Italian community Editor: Mauro Coccoli
coordinator:
Workshop Chair: Giovanni Adorni, Università di Genova Student track Chair: Gianni Vercelli, Università di Genova Industry track Chair: Domenico Squillace, IBM
Workshop Co-Chairs:
Mauro Coccoli, Università di Genova and Paolo Maresca, Università Federico II Napoli
Program committee:
The Program Committee is composed by both academics and experts: Giovanni Adorni Università di Genova
Marco Aimar Opera21 S.p.A.
Marco Brambilla Politecnico di Milano Andrea Calvagna Università di Catania
Fabio Calefato Università di Bari
Mauro Coccoli Università di Genova
Andrea De Lucia Università di Salerno
Giacomo Franco IBM
Rosario Gangemi IBM
Angelo Gargantini Università di Bergamo
Ferdinando Gorga IBM
Filippo Lanubile Università di Bari
Paolo Maresca Università Federico II Napoli
Enrico Oliva S.E.I.C. s.r.l.
Patrizio Pelliccione Università di L’Aquila Elvinia Riccobene Università di Milano Patrizia Scandurra Università di Bergamo Giuseppe Scanniello Università di Basilicata Vittorio Scarano Università di Salerno Carmine Seraponte Opera21 S.p.A.
Domenico Squillace IBM
Lidia Stanganelli Università di Genova Rodolfo Totaro Energeya Italia s.r.l. Gianni Vercelli Università di Genova
Regular Papers 1 Collaborative Mind Maps
Furio Belgiorno, Delfina Malandrino, Ilaria Manno, Giuseppina Palmieri,
Donato Pirozzi and Vittorio Scarano 2
An Eclipse-based IDE for Featherweight Java implemented in Xtext
Lorenzo Bettini 14
Using Domain Specific Languages for platform-based software development:the case of Android
Antonio Natali and Ambra Molesini 29
Design and Development of an Extensible Test Generation Tool based on the Eclipse Rich Client Platform
Angelo Gargantini and Gordon Fraser 41
A probabilistic approach for choosing the best licence in the Eclipse community
Pierpaolo Di Bitonto, Paolo Maresca, Veronica Rossano, Teresa Roselli,
Maria Laterza and Lidia Stanganelli 53
Eclipse Jazz 65
Adding collaboration into Rational Team Concert
Furio Belgiorno, Ilaria Manno, Giuseppina Palmieri and Vittorio Scarano 66 Apprendimento collaborativo fra team universitari in progetti didattici
mediante l'uso di RTC
Paolo Maresca and Lidia Stanganelli 78
Enforcing Team Cooperation Using Rational Software Tools into Software Engineering Academic Projects
Mauro Coccoli, Paolo Maresca and Lidia Stanganelli 90 On the downscaling of the Jazz platform Experimenting the Jazz RTC
platform in a teaching course
Angelo Gargantini, Guido Salvaneschi and Patrizia Scandurra 104 Enhancing team cooperation through building innovative teaching
Ferdinando Gorga, Paolo Maresca, Carla Milani and Giorgio Galli 126
Student Papers 138
An Eclipse Plug-in for Code Search using Full-text Information Retrieval Engine
Andrejs Jermakovics and Francesco Di Cerbo 139
Collaborative GeoGebra
Emidio Bianco, Ilaria Manno and Donato Pirozzi 143 Enforcing Team Cooperation project: student opinion
Lidia Stanganelli and Diego Brondo 147
Industrial Demos 151
Eclipse Equinox: the adoption of the OSGi standard in Enterprise solutions
Antonietta Miele 152
FishStatJ, an Eclipse-RCP based application for statistical data mining and analysis
Fabrizio Sibeni and Francesco Calderini 153
Rich Client Application framework based on the Eclipse platform
Paolo Giardiello 154
Un sistema di monitoraggio ambientale realizzato con Eclipse
Alessandro Burastero, Paolo Campanella, Fabio Pintus, Cosimo Versace
and Adriano Fedi 157
Eclipse RCP come piattaforma di integrazione
Vincenzo Caselli and Francesco Guidieri 158
Configuration, Change & Release Management for internal and external development with Rational Team Concert
Alessandro Moro and Michele Pegoraro 159
Processo di sviluppo in SECSERVIZI: la metodologia JMC
Regular Papers
Chair: Giovanni Adorni
Dipartimento di Informatica, Sistemistica e Telematica, Università di Genova [email protected]
Collaborative Mind Maps
Furio Belgiorno, Delfina Malandrino, Ilaria Manno, Giuseppina Palmieri, Donato Pirozzi, and Vittorio ScaranoISISLab
Dipartimento di Informatica ed Applicazioni “R.M. Capocelli” Universit`a di Salerno, Fisciano (SA), Italy
{furbel,delmal,manno,palmieri,vitsca}@dia.unisa.it
Abstract. In thefield of Computer Supported Collaborative Work a growing in-terest is going towards the introduction of collaboration features into existing user applications. The key points to make collaborative an existing single-user application are its extendibility and composability: these properties allow to extend the application functionalities (to add collaborative features) and to as-semble or compose that application with other existing software components (for example frameworks that support communication and collaboration facilities). Given these consideration, we believe that the Eclipse architecture can provide a strong support to introduce collaboration in a single-user application. To this aim, we present CollabXMind, a collaborative mind-mapping application, built by adding collaboration functionalities to XMind, a single-user Eclipse-based ap-plication designed to create mind maps.
1
Introduction
Computer Supported Collaborative Work is a research area where the software (archi-tectures, methods and techniques) that allows and facilitate collaboration among users is studied. In this context, one of the interesting directions of the research is how it is possible to “inject” collaboration into existing single-user applications, beyond the functionalities provided by the application itself. One of the key advantages of this technique is the user-friendliness: users, already familiar with the single-user version of the software, have only to learn the (few) additional collaborative features to be able to embed the new collaboration software into their work practice.
In fact, the implementation from scratch of collaborative versions of existing single-user applications is not always feasible: single-users are, often, reluctant to abandon their pre-ferred and well-established application. On the other hand, collaborative features should be, as much as possible, integrated in the application, to avoid the overhead of the man-agement of the collaboration beyond the standard users activities. The implementation from scratch of collaborative systems raises also another issue: for each system the de-signer should face similar problems related to common collaborative functionalities. This aspect is presented in [1], where the authors present a classification framework of the users’ needs in collaborative software. They classify collaboration needs into basic needs, enhanced needs and comfort needs for collaboration. Furthermore, they observe that most systems (re)implement collaborative functionalities by ensuring the
basic needs, and the implementation of the functionalities that ensures the enhanced needs tends to re-implement the basic functionalities. In fact, for most of the systems basic features were createdfirst, followed by enhanced and eventually comfort features. As a consequence, a multitude of systems provide basic features in response to the lower collaboration needs, with few that face enhanced or comfort collaboration needs and,finally, with scarce re-use of existing systems that just provide basic functionalities. The achievement of the comfort functionalities can be helped by designing collabora-tion services by leveraging on existing collaboracollabora-tion funccollabora-tionalities and applicacollabora-tions, so that the design and the implementation can focus on new aspects and problems.
The idea, therefore, is to introduce collaboration functionalities in existing single-user applications by using existing frameworks that are able to support and enhance the development of such functionalities.
In literature several examples exist about the possibility of making collaborative a single-user application. Specifically, an example of use of a toolkit to introduce col-laboration in existing application is presented in [2], where the authors present DistE-dit, a toolkit that is able to convert existing single-user editors (i.e., MicroEmacs and GNUEmacs) into collaborative ones. In this case changes on the source code of the original application are required. Another approach is presented as Shared Windows Systems (also known as Collaboration Transparency Systems) in [3]; in these systems the collaboration features are introduced at the operating system level and are made available to any single-user application. Some example of this kind of approach are SharedX [4], Microsoft Meeting Space [5] and SunForum [6]. This approach does not require changes on the source code of single-user applications, but it is highly depen-dent on the underlying operating system, so it not suitable for multi-platform applica-tions. The Component Replacement approach, used in FlexibleJAMM [7], shifts the focus from the operating system level to the application level, introducing collaboration features by replacing selected components of the application user interface with collab-orative ones. This approach requires accessing the source code even with no changes to it. The Transparent Adaptation approach, used in CoWord and CoPowerPoint [8, 9], uses the APIs of the existing applications to introduce collaboration features. This ap-proach does not require changes on the source code, but application APIs are needed to adequately intercept the input actions from users. The Component Mapping approach presented in [10] maps some user interface components to collaborative ones. This kind of approach requires changes on the source code of original applications.
All these approaches present advantages and drawbacks, and each one seems an-swering to specific requirements (availability of source code, availability of application API, dependence on the OS, etc.). However, in general terms, the idea is to introduce collaboration functionalities in existing single-user applications, eventually re-using ex-isting collaboration frameworks. Given this basic idea, the key points are the possibility to extend a single-user application with new functionalities (the collaborative features) and the possibility to compose the existing application with other software components (the frameworks supporting the collaboration).
These considerations make the Eclipse environment particularly suitable to modify and combine existing (Eclipse-based) applications and frameworks to offer new func-tionalities.
The aim of this paper is to illustrate how the component-based architecture of the Eclipse Platform and the wide set of plug-ins available for the Eclipse ecosystem can support and enhance the process of making collaborative an (Eclipse-based) single-user application. In particular, we will describe how to introduce collaboration functionali-ties in XMind, an Eclipse-based single-user application to support the creation of mind maps.
The rest of the paper is organized as follows. In Section 2 we introduce collabora-tive mind maps and the architecture and features of XMind. In Section 3 we describe the main functionalities of CollabXMind, the collaborative version of XMind, whose architecture and components are described in Section 4. Section 5 will conclude with somefinal remarks.
2
Collaborative mind maps
Amind map[11] is a graph where each node represents an idea or a concept, and each link represents a semantic connection among them. Each idea can be enriched with im-ages, hyperlinks to Web pages or other resources. Mind maps are useful for activities in-volving the organization of ideas, such as note-making, note-taking and brainstorming. Currently, several software systems support the creation of mind maps and the reorga-nization of ideas with drag-and-drop of the nodes. A quite exhaustive list of these kind of applications can be found on the Wikipedia Web site [12], while an experiment has been presented by Shih et al. in [13], in which they analyze the impact of collaborative mind mapping in generating ideas, confirming the advantage of using a collaborative mind mapping system.
The work presented in this paper aims to design and develop a collaborative real-time mind mapping application, namedCollabXMind, that enables multiple users to co-operate in parallel way on a shared mind map. CollabXMind leverages on XMind [14], a single-user Rich Client Application [15] for mind mapping, and on CAFE, part of CoFFEE suite [16], to provide functionalities to support communication and collabora-tion facilities.
XMind is a single-user standalone mind mapping software system that enables the user to create his own mind-maps. XMind is based on the metaphor of a workbook that contains multiple sheets. The user can create his own mind-map on a sheet: around the central topic grows a graphic representing related ideas and concepts. The appearance of each item can be customized with icons, colors and so on. One of the most inter-esting feature is the opportunity to change the structure of interconnected ideas: the structure can represent a map, a tree, a logic chart, afishbone or a spreadsheet. XMind, an open source project designed as an Eclipse-based application, has been named the “Best Commercial Eclipse Rich Client Platform (RCP) Application” in 2008 by the Eclipse community, and the “Best Project for Academia” in 2009 by the SourceForge community. As we will describe later, the Eclipse-based architecture of XMind has al-lowed us to design CollabXMind as a Rich Client Application to support multiple users to collaboratively create mind maps.
CAFE, acronym of Collaborative Application Framework, the core of the CoFFEE suite, has been designed to develop advanced collaboration functionalities and to allow
an efficient integration with other CAFE-based tools (i.e., CoFFEE tools, or any other collaborative tool that uses CAFE as a communication framework).
Both XMind and CAFE leverages on Eclipse, so they inherit the composability of the Eclipse architecture. This has allowed us to arrange them to achieve a collabora-tive version of XMind, without changes on the source code of the original application (XMind) and with advanced features exploited through the use of CAFE. A further re-markable result is that CollabXMind can be integrated with other collaborative tools based on CAFE. This ensures a wide set of collaborative tools which can be used to-gether to support different collaboration tasks.
3
CollabXMind functionalities
CollabXMind is a Rich Client Application which enables multiple users (in the same place at the same time) to share the same mind map. Each user (Participant) can con-tribute in real time on the shared map, while just theCoordinatorcan create the map and manage the policies and the interaction modes (described in details later).
CollabXMind’s user interface is similar to XMind mind mapping application and has some new component to support collaboration features.
The user interface of the Participants (as shown in Fig. 2) offers the same function-alities of XMind, but each action is shown in real time to every Participant. The actions related to the creation/opening/import of collaborative workbooks, are not available to the Participant since are managed by the Coordinator. Further collaboration components added to user interfaces are the Chat tool and the Presence tool, for discussions support and team awareness, respectively.
In Fig. 1 we show the user interface of the Coordinator, as it appears in CollabX-Mind. The classic menu and tool bars of XMind are shown on the top, while in the middle, there is a collaborative workbook with an example of a mind map created with contributions from all available users (the topic, in that map, is about the penetration of social media in our daily life).
As shown in Fig. 1, the user interface components introduced in the Coordinator’s application to support the collaboration are the Control Panel (on the left) and the Chat tool (in the top-right corner). The Control Panel provides a list of all connected Par-ticipants and allows to manages the Floor control (the blocking/unblocking of user in-terface of a specific user, a group of users or all Participants). The Chat tool supports discussion between users, for instance to allow meta-communication about the organi-zation of the activities on the map.
Other widgets are introduced near to the zoom control bar (at the bottom) to manage anonymity and the interaction modes. The interaction modes allow the Coordinator to define when and how users can work on the artifacts. They are related with concept of authorof a contribution: in CollabXMind each node has an owner (the author) and this information is used to apply different policies.
The interaction modes provided by CollabXMind areclone,view,owner editingand open editing. The Coordinator can change interaction modes of Participants at runtime during the collaborative activities.
Fig. 1.User interface of the Coordinator in the CollabXMind application.
Fig. 2.User interface of the Participant in the CollabXMind application.
In theclone interaction mode each Participant has exactly the same view (with the same map) of the Coordinator, but any action is disabled, including the navigation activities like zooming and bar scrolling. Only the Coordinator can perform actions
on the maps and these are reflected in real time on the Participants views (including navigation activities).
In theview interaction mode, Participants can not perform actions on the map, but they have their navigation free: they can zoom or scroll the map on their own. The Coordinator has full access about changes into the map and his/her actions are shown in real time to all Participants.
In theowner editing mode, the Participants have the possibility to add their contri-butions (i.e., nodes and links) on the map, allowing a synchronous collaboration among users. However, Participants are not allowed to change other people contributions: each one can contribute and eventually modify his own contribution, but can not delete or change (that is, perform actions such as editing, change of style, shape color, etc.) con-tribution of other users. This guarantees a minimum control over the users interactions. As shown in Fig. 2, in the owner editing mode, as visual cue, all nodes owned by the Participant on its interface are marked with an icon representing a man with a pencil, to distinguish from other nodes that cannot be edited.
Finally, of course, there is anopen editing modewhere everybody is free to modify every aspect and content of the map.
4
CollabXMind architecture
In this Section we describe the CollabXMind application byfirst introducing an overview of the architecture and then describing each component and the provided functionalities.
As anticipated in Section 2, the CollabXMind application has been designed with the aim of making collaborative XMind, an open source single-user Rich Client Appli-cation. The goal is to add collaboration functionalities to it to allow multiple users to work concurrently on the same mind map. A strict requirement concerns the need to avoid any modification on the source code of the original application, so that to ensure an easier update with successive versions of the XMind software.
The multiple instances of the CollabXMind applications are arranged in a client-server architecture, where the input of each client is passed to the client-server which forwards it to all other available clients. The basic idea is to introduce collaboration functionali-ties by intercepting the users’ input in XMind, their actions on the mind map, and then pass this input to the framework providing communication functionalities.
Fig. 3 shows the architecture of CollabXMind: there is aClient Component (the CollabXMind Clientin Fig.3) and aServer Component(i.e., theCollabXMind Server in Fig.3). We will refer to them as Server Component and Client Component respec-tively, next in this section. However, both components, implemented as Rich Client Applications, leverage on XMind, on their own CollabXMind plug-in and on the CAFE framework. These components provide the following functionalities:
– the CAFE framework provides communication functionalities and advanced col-laboration features; it is present both in the Server Component and in the Client Component
– the CollabXMind plug-in is responsible of intercepting the users’ input and to pass them to the CAFE framework and vice versa; it is present both in the Server
Compo-nent and in the Client CompoCompo-nent, whereas on the server side, it is also responsible of applying policies and access control
– the CAFE tool plug-ins are responsible of connecting the CollabXMind plug-in with the the CAFE framework; they are present both in the Server Component and in the Client Component
Fig. 3.The CollabXMind architecture. From the top to the bottom, both on the Server Component and on the Client Component: XMind, the CollabXMind plug-in (with a Policy controller on the Server component), the CAFE tool plug-ins (server plug-in and client plug-in, respectively) and the CAFE framework.
4.1 The Collaboration Framework (CAFE)
The CAFE framework is the core of CoFFEE [16–18], a suite of Rich Client Appli-cations designed to support collaborative learning in a face to face context. The archi-tecture of CoFFEE is characterized by a server-side component and by a client-side component, the CoFFEE Controller and the CoFFEE Discusser, respectively. It pro-vides a set of collaborative tools integrated in the environment to support a wide range of aims and contexts; a detailed description of CoFFEE and its tools is provided in [16, 18]. Finally, CoFFEE is available since July 2008 on SourceForge [17].
Technically, CAFE is an Eclipse plug-in that provides the communication func-tionalities by exploiting ECF (Eclipse Communication Framework) [19] as commu-nication framework. Specifically, CAFE uses two ECF components, named Container and Shared Object: the Container provides access to the communication protocol (i.e., TCP/IP) and hosts the Shared Objects which provide APIs to send/receive arbitrary messages via the Container. Finally, each CAFE-based tool registers its specific Shared Object with the Container.
Beyond the communication functionalities, the CAFE framework implements a set of services to support and enhance the development of collaborative applications: it pro-vides an automatic mechanism ofServer Discoveryto allow the clients to discover the server on the local area network. This functionality simplifies the initial phase of con-nection of clients to the server. AnAuthenticationfunctionality is also provided by the framework, which supports the initial registration of users (i.e., the Participants), and allows to choose if the connection of users should be free or should be authenticated against a list of known users. Currently, the authentication does not implement any so-phisticated security mechanism, but just a check on a list of names. CAFE also offers a Floor Controlmechanism to allow the Coordinator to selectively block/unblock users: through the Control Panel the Coordinator can block/unblock a single user, a group of users or all the team. TheLatecomers managementprovided by CAFE supports the late joining of clients and the synchronization of their state. Details of this mechanism are presented in [16].
We have to emphasize that the most important feature provided by CAFE is the Tools integrationmechanism: it defines an extension point (a mechanism inherited by the Eclipse architecture) to integrate into the architecture any CAFE-based tool. This integration mechanism allows to detect, at startup, available tools that can be, therefore, launched at runtime.
4.2 The CAFE tools plug-ins
The CAFE tool (server and client) plug-ins allow the communication between the Col-labXMind plug-in and the CAFE framework.
CAFE-based tools are integrated into the CAFE framework through the standard Eclipse extension point mechanism: they extend the extension point defined by CAFE and implement the classes and the interfaces required to launch the tool and to use the communication functionalities. The Java classes that allow the integration of any tool include:
– the class which manages the start up of the tool – the class which implements the Shared Object – the class which implements the UI of the tool
The basic implementation of all these classes is provided by CAFE, so the CAFE-based tools have to provide just their specific implementation details.
4.3 The CollabXMind plug-in
The main goal of the CollabXMind plug-in is to introduce the collaboration function-alities in XMind. The CollabXMind plug-in is responsible of intercepting the actions of users and to pass them to the CAFE framework (and vice versa). The general idea of our approach is to intervene in the implementation of the Model-View-Controller (MVC) pattern provided by XMind and add new components to intercept the requests of users and manipulate them; our components send the intercepted requests to the CollabXMind plug-in on the Server Component, that,first, applies policies and access
Fig. 4.How the CollabXMinds plug-in components intervene in the implementation of the MVC pattern.
control mechanisms (through the Policy controller as shown in Fig. 3), then processes the requests and,finally, sends the generated events to all available clients.
XMind implements the Model-View-Controller pattern through GEF (Graphical Editing Framework) [20], an Eclipse plug-in supporting the creation of graphical ed-itors. The components defined by GEF to implement the MVC pattern are the Model, the View and the EditPart (i.e., the Controller). Our approach adds some components in the GEF MVC implementation to intercept the users’ actions on the map and pass them to our communication framework. Details about this implementation have been described in [21]. The Fig. 4 depicts the details of the architecture built on the GEF MVC implementation, by illustrating the process of the input of a client.
The CollabXMind plug-in, on the Client component replaces the original EditDo-main of XMind (a component that dispatches the request to the right EditPart) with a new component namely CollabEditDomain. This replacement does not require changes on the source code of XMind because it can be done through the APIs of GEF. The CollabEditDomain intercepts the requests going from the View to the EditPart (and prevents the requests to be processed by the EditPart) and sends them to the EditPart of the CollabXMind plug-in (Server-side) through the communication framework.
In the CollabXMind plug-in, on the Server Component, all client requests are en-queued and then processed by the Policy controller, that, on the other hand, checks the user’s permissions and forward the request to the XMind EditPart; it performs the re-quired operations on the Model that notifies the registered listeners (event changes are notified to all clients). In the CollabXMind plug-in, on the Client Component, an han-dler receives these changes and updates the corresponding Model. The Model notifies of the change its listeners, including the EditPart which updates the View.
The process of a request of the user playing as Coordinator is slightly different: its input is normally processed by the XMind EditDomain and then by the XMind EditPart;
when the EditPart updates the Model, it notifies the listeners, including the CollabX-Mind Model Listener which sends the event to all clients.
5
Conclusions
The work of extending a single-user application to make it collaborative is not new, in fact several examples exist in literature about the possibility of building multi-user applications starting from their single-user version. There are several reasons to eval-uate the possibility of introducing collaboration in an existing application instead of developing from scratch new collaborative applications. In many cases, the key point is that the collaborative applications should be, from the provided functionalities point of view, exactly the same of the single-user applications, to preserve the realm of loyal users to those applications, but at the same time, it has to provide additional collabora-tion features.
From the developer’s point of view, it usually means a lot of additional work to re-implement the existing applications preserving their behaviors andjustadding the collaboration features. From the user’s point of view, the user has to substitute the pre-ferred and well-established application with a new one, in order to add collaboration. This is not simple and is often costly and, therefore, most users will prefer to continue to use their preferred (single-user) application, in combination with simple tools for collaboration and document sharing like instant messaging systems and e-mail.
Then, to face needs and wishes of both developers and users, several studies con-sider the solution of extending single-user applications without changes to their original behavior and simply adding new collaborative functionalities. As briefly reported in the Section 1, so far several studies have proposed different approaches, highlighting sev-eral issues depending on the approach and on the target application. A brief review of existing approaches is presented in [22]. The key factors that enable this effective exten-sion are extensibility and composability, which are critical to the success and popularity of the Eclipse Platform.
By leveraging on the Eclipse Platform and on its main features we have provided an example of construction of a multi-user application, starting from a single-user version, without applying any change to the original source code and simply adding groupware features to make it collaborative.
Our result is collaborative software based on a fully-fledged application, such as XMind, a well-known software, whose effectiveness and innovation is witnessed by the multiple awards, within the (quite large) Eclipse community but also from the wider (and more heterogeneous) audience from Sourceforge. We have presented the CollabX-Mind application, a Rich Client Application that allows multiple users to create mind maps as they would by using XMind, but in collaborative way, by exploiting a provided underlying collaboration framework. It must be emphasized that this was possible since the extendibility and the composability of the underlying architecture. The component-based nature of the Eclipse architecture, in fact, allowed us to arrange several compo-nents: XMind, the CollabXmind plug-in and the CAFE framework.
We have used XMind as a plug-in (instead of as a Rich Client Application), and then we have arranged it with CollabXMind, a new plug-in which implements the
com-ponents able to introduce collaboration features in the original application. Also the integration of XMind and CollabXMind with CAFE was possible thanks to the nature of the Eclipse architecture, and to its standard Extension-point mechanism.
A remarkable consideration is that CollabXMind, beyond being a Rich Client Ap-plication, is also a CAFE-based tool, simply thanks to the integration into the CAFE framework. This has an important two-way implication: CollabXMind can be used as a collaborative tool in the CoFFEE suite, but at the same time, CollabXMind as Rich Client Application can use any other CAFE-based tool. This allows CollabXMind to effectively use the CoFFEE tools to support collaboration features like team awareness (with the Presence tool), simple communication (with the Chat tool), structured com-munication (with the Threaded Discussion tool), voting (with Positionometer), and so on. This high level of composability and integration derives from the architecture of CAFE and its implementation based on the Eclipse Platform.
Thefinal valuable result is that any CAFE-based collaborative environment, and then both CollabXMind and CoFFEE, has a wide set of collaborative features inherited from the framework (such as the server discovery, the communication framework, the latecomers management, etc.) and of collaborative tools (all the CAFE-based tools, from a simple Presence tool to a more complex CollabXMind application).
Finally, we are planning to make the CollabXMind application available on Source-Forge as a new project in a short time (likely by next autumn) and to conduct further studies to evaluate the usability and effectiveness of the application.
References
1. Sarma, A., van der Hoek, A., Cheng, L.: A Need-Based Collaboration Classification Frame-work. In: Proc. on Eclipse as Vehicle for CSCW Research, Workshop at CSCW 2004. (2004) 2. Knister, M.J., Prakash, A.: Distedit: a distributed toolkit for supporting multiple group ed-itors. In: CSCW ’90: Proceedings of the 1990 ACM conference on Computer-supported cooperative work, New York, NY, USA, ACM (1990) 343–355
3. Lauwers, J.C., Joseph, T.A., Lantz, K.A., Romanow, A.L.: Replicated architectures for shared window systems: a critique. SIGOIS Bull.11(2-3) (1990) 249–260
4. Garfinkel, D., Welti, B., Yip, T.: HP Shared X: a tool for real time colalboration. HP Journal 45,2(1994) 23–36
5. Microsoft: Windows Meeting Space. http://www.microsoft.com/india/windows/ windows-vista/features/meeting-space.aspx
6. SunForum: SunForum 3.0 Software User’s Guide. http://docs.sun.com/app/docs/ doc/805-4479-12
7. Begole, J., Rosson, M.B., Shaffer, C.A.: Flexible collaboration transparency: supporting worker independence in replicated application-sharing systems. ACM Trans. Comput.-Hum. Interact.6(2) (1999) 95–132
8. Xia, S., Sun, D., Sun, C., Chen, D., Shen, H.: Leveraging single-user applications for multi-user collaboration: the coword approach. In: CSCW ’04: Proceedings of the 2004 ACM conference on Computer supported cooperative work, New York, NY, USA, ACM (2004) 162–171
9. Sun, C., Xia, S., Sun, D., Chen, D., Shen, H., Cai, W.: Transparent adaptation of single-user applications for multi-user real-time collaboration. ACM Trans. Comput.-Hum. Interact. 13(4) (2006) 531–582
10. Pichiliani, M., Hirata, C.: A guide to map application components to support multi-user real-time collaboration. International Conference on Collaborative Computing: Networking, Applications and Worksharing (2006) 1–5
11. Buzan, T., Buzan, B.: The Mind Map Book: Available from Amazon.comShared Visions Unlimited Reviews Home PageHow to Use Radiant Thinking to Maximize Your Brain’s Untapped Potential. E. P. Dutton (1994)
12. Wikipedia: Mind-mapping software. http://en.wikipedia.org/wiki/List_of_mind_ mapping_software(Accessed on July, 2010).
13. Shih, P.C., Nguyen, D.H., Hirano, S.H., Redmiles, D.F., Hayes, G.R.: Groupmind: support-ing idea generation through a collaborative mind-mappsupport-ing tool. In: GROUP ’09: Proceedsupport-ings of the ACM 2009 international conference on Supporting group work, New York, NY, USA, ACM (2009) 139–148
14. XMind: Mind mapping. http://www.xmind.net/(Accessed on July, 2010).
15. Eclipse: Rich Client Platform (RCP). http://wiki.eclipse.org/index.php/Rich_ Client_Platform
16. De Chiara, R., Di Matteo, A., Ilaria Manno, Scarano, V.: CoFFEE: Cooperative Face2Face Educational Environment. In: Proceedings of the 3rd International Conference on Col-laborative Computing: Networking, Applications and Worksharing (CollaborateCom 2007), November 12-15, 2007, New York, USA. (2007)
17. CoFFEE: CoFFEE at Sourceforge:. http://sourceforge.net/projects/coffee-soft (2010)
18. De Chiara, R., Manno, I., Scarano, V.: CoFFEE: an Expandable and Rich Platform for Computer-Mediated, Face-to-Face Argumentation in Classroom. In: In Educational Tech-nologies for Teaching Argumentation Skills. Bentham eBooks (in press)
19. ECF: Eclipse Communication Framework (2010) http://www.eclipse.org/ecf/.
20. Eclipse: Graphical Editor Framework.http://www.eclipse.org/gef/(Accessed on July, 2010).
21. Belgiorno, F., Malandrino, D., Manno, I., Palmieri, G., Pirozzi, D., Scarano., V.: Introduc-ing Collaboration in SIntroduc-ingle-user Applications through the Centralized Control Architecture. Submitted for publication, June 2010.
22. Pichiliani, M.C., Hirata, C.M.: A technical comparison of the existing approaches to support collaboration in non-collaborative applications. Collaborative Technologies and Systems, International Symposium on (2009) 314–321
An Eclipse-based IDE for Featherweight Java
implemented in Xtext
?
Lorenzo Bettini1
Dipartimento di Informatica, Universit`a di Torino, C.so Svizzera, 185 - 10149 Torino, Italy
Abstract. Developing a compiler and an IDE for a language is usually time con-suming; even when relying on a framework like Eclipse, which already provides typical IDE artifacts, still implementing the parser, the model for the AST, and connect all the language features to the IDE components requires lot of manual programming. In this paper we present our implementation of Featherweight Java (a lightweight version of Java which is typically used when formalizing Java-like languages) in Eclipse by relying on Xtext (a framework for development of pro-gramming languages in Eclipse). Xtext eases the task of implementing a compiler and an IDE based on Eclipse by providing a high-level framework that generates most of the typical and recurrent artifacts necessary for a fully-fledged IDE on top of Eclipse, and allows the programmer to customize every aspect.
1
Introduction
When designing/developing new languages, in the context of programming language theory research, the development stage usually comes only after the complete formal-ization of the language and its proof of type safety (especially in a statically typed sce-nario). Indeed the implementation stage, even if only on a prototypical form, is always time consuming, even for toy languages: writing the parser using a compiler generator (like, e.g., Flex & Bison [20] and ANTLR [21]), building the abstract syntax tree (AST), perform all the visits on the AST (e.g., type checking), and finally generate code into a target language or build the interpreter.
However, it would be useful to develop the language implementation while studying the theory of the language so that one can soon test the language features and integrate the experience of the language use in the design stage (apart from possibly finding bugs in the theory while writing some test programs). Thus, having a tool for language im-plementations that makes the development cycle of adding a new feature to a language really rapid is a crucial feature in this context.
Finally, having an integrated development environment (IDE) for the language, while not being a fundamental feature for a language implementation, is something that nowadays programmers are used to. Mechanisms like code completion, program outline, syntax highlighting, and so on, are typical of many professional programming editors, and surely increment productivity. Building an IDE from scratch for a language
With this respect, Eclipse provides an extensible and powerful framework for build-ing programmbuild-ing language editors, thanks to its plugin architecture [15], coverbuild-ing all the aspects of professional IDEs for enhancing productivity. However, the procedure for building a plugin for your own programming language for Eclipse is still quite laborious and requires a lot of manual programming. XTEXT[4], a framework for development of programming languages as well as other domain-specific languages (DSLs), eases this task by providing a high-level framework that generates most of the typical and recurrent artifacts necessary for a fully-fledged IDE on top of Eclipse. In XTEXT, the syntax of the language is defined using an EBNF grammar. Starting from this grammar, the XTEXTgenerator creates a parser, an AST-meta model (implemented in EMF [24]) as well as a full-featured Eclipse-based editor. The plugins generated by XTEXTalready implement most of the recurrent artifacts for a language IDEs, and they can be easily customized by “injecting” (by relying on Google-Guice [1], see later in the paper) our own specific language mechanisms implementations. In particular, as we will show in the paper, the code we need to write for customizing the IDE is minimal.
In this paper, we present the prototypical implementation of FEATHERWEIGHT JAVA (FJ) [19, 23], a lightweight version of Java, which focuses on a few basic fea-tures: mutually recursive class definitions, inheritance, object creation, method invo-cation, method recursion throughthis, subtyping and field access. In particular, a FJ program is a list of class definitions and a single main expression (see the example in Listing 1). Since in FJ the class constructor has a fixed shape (it takes as many pa-rameters as the fields in the class, with the same name, including the inherited ones, and it initializes the fields of the class with the passed arguments, after having passed the arguments for the inherited fields to the superclass constructor), we simplified the language by assuming such constructors as implicit. The minimal syntax, typing and semantics make the type safety proof simple and compact, in such a way that FJ is a handy tool for studying the consequences of extensions and variations with respect to Java (“FJ’s main application is modeling extensions of Java”, [23], page 248). For this reason, we personally used FJ as the starting point for studying language extensions to Java [9, 8, 6, 10, 7] and we felt the need of a rapid development framework for building editors and compilers for our languages.
This paper can be seen as an experience report on using XTEXT for building a fully-fledged Eclipse-based IDE for a general purpose language; although FJ is not a complete object-oriented programming language (like Java itself), still it deals with typical object-oriented features, thus it still requires a wide effort during the imple-mentation. Furthermore, while XTEXT defines itself as a framework mainly for do-main specific languages (DSL), this paper also provides an evidence for XTEXTuse for general purpose languages (with this respect, XTEXT only ships with DSL ex-amples). The implementation of FJ is available as an open source project at http://fj-eclipse.sourceforge.net.
Throughout the paper, we assume the reader is familiar with building eclipse plu-gins; also, a generic knowledge of EMF would be required, though we will sketch the
classAextendsObject{ } classBextendsObject{ } classPairextendsObject{
Object fst; Object snd;
Pair setfst(Object newfst){
return newPair(newfst,this.snd); }
Pair setsnd(Object newscd){
return newPair(this.fst, newscd); }
}
newPair(newA(),newB()).setfst(newA()).fst
Listing 1:An example of FJ program.
The paper is structured as follows. In Section 2 we describe our implementation in XTEXT. In Section 3 we discuss our experience with XTEXT. Related work is discussed in Section 4. We conclude by outlining some future work.
2
Implementing FJ with X
TEXTIn this section, we describe the implementation of FJ using the XTEXT[4] framework for Eclipse. We will not provide all the details of the implementation; for instance, we will not detail how we implemented the type system and the type checker, since they are not interesting in this context. Instead, we will stress what we need to provide to XTEXT(i.e., specific class and method implementations) so that the framework can do the rest of the job in implementing all the IDE functionalities.
The first task in XTEXTis to write the grammar of the language using an EBNF-like syntax. For completeness we show the complete XTEXTgrammar for FJ in Listing 2. The reader who is familiar with ANTLR [21] will note that the syntax of XTEXT gram-mars is very similar to ANTLR’s syntax, though a little bit simpler.
Starting from this grammar, XTEXTgenerates an ANTLR parser [21]. The gen-eration of the abstract syntax tree is handled by XTEXTas well. In particular, during parsing, the AST is automatically generated in the shape of an EMF model (Eclipse Modeling Framework [24]). Thus, the manipulation of the AST can use all mechanisms provided by EMF itself. Note that the automatic generation of the AST by XTEXT already reduces the programmer’s job a lot; furthermore, by relying on a modeling framework such as EMF, the programmer does not even have to create all the hierarchy
grammar org.eclipse.xtext.example.FJ with org.eclipse.xtext.common.Terminals generate fj "http://example.xtext.org/FJ"
Program : (classes += Class)* (main = Expression)? ; Type: basic=(’int’ | ’boolean’ | ’String’) |
classref=[Class] ;
TypedElement: Field | Parameter; Class:
’class’ name=ID (’extends’ extends=[Class])? ’{’ (fields += Field)*
(methods += Method)* ’}’ ;
Field: type=Type name=ID ’;’ ; Parameter: type=Type name=ID ; Method:
returntype=Type name=ID
’(’ (params+=Parameter (’,’ params+=Parameter)*)? ’)’ ’{’ body=MethodBody
’}’ ;
MethodBody: ’return’ expression=Expression ’;’ ; Expression:
TerminalExpression ({Selection.receiver=current} ’.’ message=Message )* ;
Message: MethodCall | FieldSelection ;
MethodCall: name=[Method] ’(’ (args+=Argument (’,’ args+=Argument)*)? ’)’; FieldSelection: name=[Field];
TerminalExpression returns Expression: This | Variable | New | Cast | Paren ; This: variable=’this’;
Variable: variable=[Parameter];
New: ’new’ type=[Class] ’(’ (args+=Argument (’,’ args+=Argument)*)? ’)’; Cast: ’(’ type=[Class] ’)’ object=TerminalExpression;
Paren returns Expression: ’(’ Expression ’)’; Argument: Expression;
later paragraph in this Section and to Figure 1). But most of all, it allows programmat-ically modifying the program by acting on the model representing it, without the need of accessing its textual form in the editor (see the quickfix implementation in Listing 5 in Section 3), which will be automatically updated to reflect the changes in the model.
There is a direct correspondence between the names used in the rules of the grammar and the generated EMF model JAVA classes. For instance, if we have the following grammar snippet:1
Selection returns Expression:
receiver=Expression ’.’ message=Message; Message: MethodCall | FieldSelection ;
MethodCall: name=[Method] ’(’ (args+=Argument (’,’ args+=Argument)*)? ’)’; FieldSelection: name=[Field];
the XTEXT framework generates the following EMF model JAVA interface (and the corresponding implementation class):
public interfaceMethodCallextendsMessage {
Method getName();
voidsetName(Method value); EList<Argument>getArgs(); }
Besides, XTEXTgenerates many other classes for the editor for the language that we are implementing. The editor contains syntax highlighting2, background parsing with error markers, outline view, code completion. Most of the code generated by XTEXT can already be used off the shelf, but other parts can or have to be adapted by cus-tomizing some classes used in the framework. The usage of the customized classes is dealt with by relying on Google-Guice [1], so that the programmer does not have to maintain customized abstract factories [17]. In this way it is very easy to insert custom implementations into the framework (“injected” in Google-Guice terminology), with the guarantee that the custom classes will be used consistently throughout the code of the framework.
The validation mechanisms for the language must be provided by the language de-veloper. In our case, this is the FJ type system. Implementing the validation mechanism in a compiler usually requires to write specific visitors for the abstract syntax tree. EMF already simplifies this task by providing a switch-like functionality to efficiently exe-cute methods with dynamic dispatch according to the actual type of an AST node. Thus, there is no need to add code to implement a visitor structure [17]. Note that this dynamic
1If the reader compares this simplified grammar snippet with the complete grammar in Listing 2 she will note a different rule for method invocation; this is due to the fact that in order to deal with left recursion, which LL-parsing tools cannot handle directly, we need to “left-factor” the grammar [5].
public classFJTypeCheckerextendsFjSwitch<String>{ ...
publicString caseField(Field field){...} publicString caseMethod(Method method){...} publicString caseCast(Cast cast){
TypeResult objectType = typeSystem.getType(cast.getObject()); if(!subtyping.isSubtype(objectType.getType(), cast.getType())
&& !subtyping.isSubtype(cast.getType(), objectType.getType())) return"expression type "
+ objectType.getType() +" and " + cast.getType() +" are unrelated"; return"";
} ...
publicString typeCheck(EObject object){ String errors = doSwitch(object); returnerrors;
} }
Listing 3:The typechecker implementation (snippet).
selection of methods according to the run-time type of the argument (dynamic overload-ing) is implemented efficiently: instead of using run-time type information checks and casts, the code generated by EMF performs aswitchblock using the unique integer identifiers of the classes of the generated EMF model. Thus, this selection basically per-forms in constant time (since theswitchinstruction is implemented in constant time). In order to use this functionality it is enough to inherit from the generated class imple-menting the switch functionality (in our case the generated EMFFjSwitchbase class), and provide the methods for all the model classes we want to deal with (the generated switch functionality provides default cases for the classes for which we do not provide a case and also handles class inheritance in the model class hierarchy). For instance, we used this technique to implement the type checker (the generic parameter of the switch class represents the return type of the case methods) as (partially) shown in Listing 3. In particular, this class relies on other objects (whose classes are not shown here) that we implemented for inferring a type of an AST node (typeSystem) and for checking the subtyping (subclass) relation (subtyping). In our implementation we use strings to return possible type errors, thus, if the method returns an empty string it means that the checked expression is well-typed.
XTEXT leverages this mechanism by only requiring methods with a@Check an-notation in a customized validator, that will be called automatically for validating the model according to the type of the AST node being checked. We thus implemented a method for some classes of the model representing the AST of an FJ program, and we
in IDEs. For instance, the following method in theFJJavaValidatorchecks that the cast expression is correct:
@Check
public voidcheckCast(Cast cast){
String errors = typeChecker.typeCheck(cast); if(errors !=null&& errors.length()>0){
error(errors, FjPackage.CAST TYPE); }
}
Note that the only important things in this method definition are the@Checkannotation and the parameter: the internal validator of XTEXT will invoke this method when it needs to validate an AST node representing a cast expression, i.e., aCast instance, which corresponds to theCastrule in the grammar of Listing 2 (remember that given a grammar symbol, XTEXTwill generate a corresponding class for the AST with the same name). The implementation of the validation in our case simply delegates to the type checker class shown above. If an error is found during the typechecking, then calling the methoderrorwill make XTEXTgenerate the appropriate error marker (and since we specify the element in the AST which did not pass validation, XTEXTis able to put the marker in the right place without any needed information by the programmer).
Binding the symbols (e.g., the binding of a field reference to its declaration) is important in compiler development. When defining the grammar of the language in XTEXT, we can already specify that a specific token is actually a reference to a specific declared element. Going back to the snippet at the beginning of the section, we note that the name of the method in a method invocation is enclosed in square brackets ([Method]). This means that the token representing the method’s name in a method invocation is not simply an identifier: it is a reference to the name of a declaredMethod (see also the complete grammar in Listing 2). For field selection we can do a similar thing (referring to the name of a declaredField). This allows providing more detailed information in the grammar itself, and in the generated EMF model, the name of the method in a method invocation expression will not be simply a string, but it will be a cross reference to an instance ofMethod.
In particular, EMF uses “proxies” to represent references and it can delay the res-olution (binding) of references when they are accessed. XTEXT already provides an implementation for binding references, which basically binds a reference to a symbol n to the first element definition with name n occurring in the model. However, this usually has to be adapted in order to take the visibility (scope) of names in a program into account. For instance, a field is visible only in the methods of a class, such that different hierarchies can safely have fields with the same name. XTEXTsupports the customization of binding in an elegant way with the abstract concept of “scope”. The actual binding is still performed by XTEXT, but it can be driven by providing the scope of a reference, i.e., all declarations that are available in the current context of a refer-ence. Note that this way we can filter out elements according to their kind, e.g., in order not to mix field names with method names if we need to resolve a reference to a field.
publicIScope scope MethodCall name(Selection sel, EReference ref){
TypeResult selectionExpressionType = typeSystem.getType(sel.getReceiver()); Class receiverType = selectionExpressionType.getClassref();
if(receiverType !=null)
returnScopes.scopeFor(auxiliaryFunctions.getMethods(receiverType)); // return an empty scope
returnScopes.scopeFor(newLinkedList<EObject>()); }
Listing 4:Scope provider for a method invocation expression.
we have a ruleContextRuleNamewith an attributeReferenceAttributeNameassigned to a cross reference withTypeToReturntype, that is used by the ruleContextType. You can create one or both of the following two methods
IScope scope<ContextRuleName> <ReferenceAttributeName>
(<ContextType>ctx, EReference ref)
IScope scope<TypeToReturn>(<ContextType>ctx, EReference ref)
The XTEXTbinding mechanism looks for the first method (by reflection), if this does not exist, then it looks for the second. If no such method exists, the default linking semantics (see above) is used. These methods are supposed to return the set of all “visi-ble” elements in that part of the program (represented by the passed context); using the returned scope, XTEXTwill then take care of resolving a cross reference (or issue an error in case the reference cannot be solved). If XTEXTsucceeds in resolving a cross reference, it also takes care of implementing the functionalities Eclipse users are used to, e.g., by Ctrl+clicking on a reference (or using F3) we can jump to the declaration for that symbol.
For instance, in a FJ program, all classes defined in the program are visible (there is no need of specifying the classes in a specific order), thus, when a class reference needs to be resolved in a program, we can simply provide as the scope the collection of all the classes in the program (obtained through some auxiliary functions not shown here; the Scopesclass is part of the XTEXTlibrary):
publicIScope scope Class(Program p, EReference type){ returnScopes.scopeFor(auxiliaryFunctions.collectClasses(p)); }
Instead, if we consider the grammar rule for method invocation illustrated at the beginning of this section, we can drive the resolution of the method name in a method invocation statement in any expression where such statement can occur by defining the method shown in Listing 4 (The code should be understandable without the knowledge of XTEXT).
empty scope, e.g., if the receiver expression in a method call cannot be typed. In that case, the XTEXTframework generates an error due to an unresolvable method name during validation, and an empty code completion list in case the programmer requests content assistance when writing the method name of a method invocation expression. This mechanism is handled by the framework itself, so that the programmer is com-pletely relieved from these issues, once the correct scope provider is implemented.
XTEXTprovides a (mostly) automatic support for file import/inclusion in the devel-oped language by using grammar rules like the following
Import : ’import’ importURI=STRING;
In our implementation we did not use this functionality, but it could be easily added so that FJ programs can be split into separate files, and include other FJ files using the importkeyword. The corresponding dependencies among source files are handled by XTEXTitself. Thus, the EMF model for the AST corresponding to an included file is available automatically in the current edited source. Moreover, the modification of an included file f automatically triggers the re-validation of all the files including f.
Finally, the code generation phase is dealt with in XTEXTby relying on XPAND[3], a code generation framework based on “templates”, specialized for code generation based on EMF models. This generation phase can reuse the lookup functions and the type system functions used during validation. An XPANDtemplate consists of verbatim parts which will be output as they are and of parts to be expanded, enclosed in the special characters « and ». These parts can refer to other template files. For FJ we did not need to implement a code generator (and indeed, this step is completely optional in XTEXT, and the code generation might be carried on also with other tools), since an interpreter would be more appropriate. However, since we wanted to focus on the typechecking part for FJ and on the IDE functionalities, we are still working on the interpreter.
Figure 1 shows a screenshot of the FJ editor; note the code completion functional-ities, the outline and the error markers (note also the folding of multiple line elements, like classes and methods, which is handled automatically). Also the outline view is handled transparently by XTEXT; the default implementation of the outline view is to simply show the EMF model representing the abstract syntax tree of the program. This is not always the right thing, especially for a general purpose language. Again, the out-line view can be customized by not showing specific elements (in our case we do not show the body of methods) and by providing a customized label provider (in our case we show the name of fields and their types and the names of methods with their signa-tures). Besides that, the synchronization between the outline view and the contents of the editor is handled completely by XTEXT.
Fig. 1.The IDE for FJ.
model for validation and code generation. However, after this knowledge is achieved, developing a language compiler and an IDE using XTEXTis extremely fast. Surely it is much faster than implementing an IDE from scratch by only relying on the eclipse framework: as illustrated in Section 2 all the connections among the typical eclipse artifacts for editors, builders, etc., are established and handled by XTEXTdirectly.
As we described in Section 2 by using our own validator, XTEXT can create the error markers in the editor (and also in the “Problem View”) related to the EMF element which caused the error. We can provide our own “quickfixes” by simply deriving from an XTEXTdefault class and providing a method which refers to a specific error detected by our validator. For instance, the code shown in Listing 5 provides a quickfix in case of duplicate classes in a program, by proposing to remove one class3. Note how easy it is to implement that fix: since we deal with EMF model objects, which are connected by XTEXTto the program text in the editor, we can simply manipulate the EMF model (in this case we remove the class from the program) and the program text will reflect this change; in particular, we do not need to manipulate the eclipse text editor document at all. Figure 2 shows our quickfix in action.
XTEXTseems to be the right tool to experiment with language design and to develop implementations of languages. Furthermore, experimenting with new constructs in the language being developed can be handled straightforwardly. It requires to modify the grammar, regenerate XTEXTartifacts and to deal with the cases for the new constructs. Finally, XTEXTallows the programmer to customize every aspect of the developed
lan-public classFJQuickfixProviderextendsDefaultQuickfixProvider{ ...
@Fix(FJJavaValidator.DUPLICATE CLASS NAMES)
public voidremoveDuplicateClass(finalIssue issue, IssueResolutionAcceptor acceptor){ acceptor.accept(issue,"Remove class", ...
newISemanticModification(){
public voidapply(EObject element, IModificationContext context){ Class duplicateClass = (Class)element;
Program prog = (Program)duplicateClass.eContainer(); prog.getClasses().remove(duplicateClass); } } ); } }
Listing 5:An example of quickfix implementation.
Fig. 2.The quickfix in action.
using Google Guice), even though XTEXThides many internal details of IDE develop-ment with Eclipse. Even EMF mechanisms are still open to adaptation. For instance, we developed a customized EMF resource factory for synthesizing the implicit class Object(in FJ the classObjectis implicitly defined in every program, and it does not contain any field or method).
In order to “inject” our resource factory,FJResourceFactory, we simply need to add a specific method in the runtime module of our language plugin (that will be used internally by XTEXT):
publicClass<?extendsXtextResourceFactory>bindXtextResourceFactory(){ returnFJResourceFactory.class;
}
Just adding this binding ensures that when XTEXTmust instantiate a XtextResource-Factoryfor our language plugin, it will actually instantiate aFJResourceFactory. Thus, with Google Guice injection mechanisms we have a consistent use of our cus-tomized classes without needing to implement manually abstract factory or factory
public classCastTestextendsAbstractXtextTests{ protected voidsetUp()throwsException{
super.setUp();
with(newFJStandaloneSetup()); }
public voidtestCastFail()throwsException{ Program program =
(Program) getModel("class B { } class A { } (B) new A()"); Expression main = program.getMain();
String errors =newFJTypeChecker().typeCheck(main);
assertEquals("expression type A and B are unrelated", errors); }
}
Listing 6:The Junit test for typechecking of a cast expression.
StandaloneSetup) for the developed language with all the functionalities to correctly initialize all the EMF mechanisms so that the language can be tested as a stand-alone application (i.e., outside from Eclipse). This way, we can easily test non-UI parts of our language with no need of manually running an Eclipse application, writing a code snippet in our language, and checking that the error mark shows up4. This speeds up the development of the language; for instance, in Listing 6 we show a snippet of the test class for our type checker (compare the expected error with the type checker code for cast expression shown in Listing 3).
We would like to conclude this Section by stressing that XTEXTlets the language developer concentrate on the aspects that are typical of her own language, while relying on the framework for all the other recurrent jobs. Just to mention a fact: for developing our FJ eclipse based IDE, we did not have to write a single extension point.
4
Related Work
There are other tools for implementing both domain specific and general purpose lan-guages and their text editors and IDE functionalities (we also refer to [22] for a com-parison). Tools like IMP (The IDE Meta-Tooling Platform) [2] and DLTK (Dynamic Languages Toolkit) [14] only deal with IDE functionalities and leave the parsing mech-anism completely to the programmer, while XTEXTstarts the development cycle right from the grammar itself. Another framework, closer to XTEXTis EMFText [18]. EMF-Text basically provides the same functionalities. But, instead of deriving a meta-model from the grammar, it does the opposite, i.e., the language to be implemented must be defined in an abstract way using an EMF meta model. (A meta model is a model describ-ing a model, e.g., an UML class diagram describdescrib-ing the classes of a model). Note that XTEXTcan also connect the grammar rules to an existing EMF meta model, instead
of generating an EMF meta model starting from the grammar. Furthermore, XTEXT has also a wizard to generate an XTEXTgrammar starting from a EMF meta model. XTEXTseems to be better documented than EMFText (indeed, both projects are still young and always under intense development), and more flexible, especially since it relies on Google Guice. On the other hand, EMFText offers a “language zoo” with many examples that can be used to start the development of another language. In this respect, the examples of languages implemented using XTEXT, that we found on the web, are simpler DSLs, and not programming languages like FJ. Thus, this paper can also be seen as a report of effective usage of XTEXTfor implementing more complex programming languages.
EriLex [25] is a software tool for generating support code for embedded domain specific languages and it supports specifying syntax, type rules, and dynamic semantics of such languages. EriLex does not generate any artifact for IDE functionalities, and it concentrates on other aspects of language development such as type systems and operational semantics, providing an easy to use syntax for developing these compiler parts (which are really close to the formal presentation of type systems and semantics rule).
MPS (Meta Programming System) [16] is another tool for developing a DSL, and it also provides IDE functionalities, but it does not target Eclipse and its well-known functionalities (it uses its own technology for every language development phases); thus, while it surely is an interesting technology, it probably requires much more time to learn it, in case the programmer is already familiar with the Eclipse plugin technology. Neverlang [13] is based on the fact that programming language features can be eas-ily plugged and unplugged. A complete compiler/interpreter can be built in Neverlang as the result of a compositional process involving several building blocks. Each block deals with a single programming feature and the necessary support code, such as type checking and code generation. With respect to composition functionalities, XTEXT al-lows the programmer to mix grammars (so called “grammar mixins”) and also to reuse recurrent syntax artifacts (like the standard terminal definitions, see the “with” state-ment at the beginning of Listing 2). However, these compositional functionalities are not yet as powerful as the ones provided by Neverlang.
5
Conclusions and Future Work
In this paper we described an implementation of FJ as an Eclipse-based IDE, using the framework XTEXT. Our experience with XTEXTshows that the framework is a rapid tool for implementing a programming language, both from the compiler point of view, and from the IDE functionalities. Our implementation, freely available from http://fj-eclipse.sourceforge.net, was the starting point for the implementation of more involved programming languages, such as SUGARED WELTERWEIGHTRECORD-TRAITJAVA, http://swrtj.sourceforge.net, that we presented in [12], which is based on the calculus presented of [11], formalized by extending FJ.