The University of York Department of Computer Science

Submitted in part fulfilment for the degree of BEng.

Supporting an advancedObject-Oriented programming

language in Eclipse

Chris Heald

16th March 2005

Supervisor: Jeremy Jacob

Number of words = 17551, as counted by Microsoft Word’s wordcount.

This includes the body of the report, title page and contents, butnot the bibliography or appendix.

Acknowledgements

A few people were very helpful in the creation of this project and I wouldlike to take this opportunity to thank them. In no particular order:

My supervisor Jeremy Jacob, for providing continual support and assistance,SourceForge.net for hosting the website and providing a bug database etc.,Philipp W. Kutter and A4M for providing the domain www.Scaliptor.org,Michael Houston, Marc Moser, Koen Handekyn and everyone on the Scala

mailing list for testing it,Google.com and CiteSeer.IST.psu.edu for their essential services in finding in-

formation and whitepapers.

Abstract

Eclipse is a plug-in based open source development environment. Scala is a newOO language with multiple inheritance using mixins and traits. This report de-tails the construction of an Eclipse feature to assist in the creation of Scala code,from gathering requirements to implementation and testing. It analyses the ben-efits that Eclipse and Scala bring to a developer compared to their competition.Improvements to Eclipse are suggested and questions are asked about the ideallanguage/platform to base an IDE on.

6

Contents

1 Introduction and Background 91.1 What is an IDE and what are the advantages of using one? . . . . 9

1.1.1 History of IDEs . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.2 Graphical IDEs . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.3 NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Finding the “best” way to write an IDE . . . . . . . . . . . . . . . 121.2.1 Eclipse vs. NetBeans . . . . . . . . . . . . . . . . . . . . . . 131.2.2 Eclipse vs. EMACS . . . . . . . . . . . . . . . . . . . . . . . 141.2.3 Lisp vs. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.4 Object-Oriented versus Functional languages . . . . . . . . 151.2.5 EMACS Scala mode vs. Scaliptor 0.1 . . . . . . . . . . . . . 16

1.3 Scala — The scalable programming language . . . . . . . . . . . . 171.3.1 Mixins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3.2 Higher-order functions . . . . . . . . . . . . . . . . . . . . . 181.3.3 Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3.4 Existing support . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Requirements 232.1 The Eclipse JDT — Java Development Tools . . . . . . . . . . . . . 232.2 Other projects of a similar nature and scale . . . . . . . . . . . . . 242.3 Generated Requirements . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Design 273.1 The Eclipse API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 The Standard Widget Toolkit . . . . . . . . . . . . . . . . . 293.1.2 The basics of a text-editing plug-in . . . . . . . . . . . . . . 303.1.3 User Preferences . . . . . . . . . . . . . . . . . . . . . . . . 313.1.4 Model-View-Controller architecture . . . . . . . . . . . . . 32

3.2 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Implementation 354.1 Scaliptor’s structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Projects and Natures . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7

Contents

4.4 Parsing Scala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Building and error marking . . . . . . . . . . . . . . . . . . . . . . 374.6 Outline View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.6.1 model(File f) . . . . . . . . . . . . . . . . . . . . . . . . . 414.6.2 Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.7 Launching and Debugging . . . . . . . . . . . . . . . . . . . . . . . 434.8 Text-Hovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.8.1 ITextHover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.9 Content-Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5 Evaluation and Testing 495.1 Eclipse development . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 Improving Eclipse . . . . . . . . . . . . . . . . . . . . . . . 505.2 Scala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4 Comparing Scaliptor to other language plug-ins . . . . . . . . . . 51

5.4.1 Eclipse FP: Haskell 0.6 . . . . . . . . . . . . . . . . . . . . . 515.4.2 Eiffel for Eclipse (EfE) 1.0 . . . . . . . . . . . . . . . . . . . 52

5.5 Evaluating against the requirements . . . . . . . . . . . . . . . . . 535.6 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Conclusions 57

A ScalaModeller.java 61

8

1 Introduction and Background

This project details the design and implementation of an Integrated Develop-ment Environment (IDE) for the Scala programming language as plug-ins forthe Eclipse workbench. This collection of plug-ins is known as Scaliptor and isavailable at http://www.Scaliptor.org.

1.1 What is an IDE and what are the advantagesof using one?

An Integrated Development Environment, or IDE, aims to improve the produc-tivity and efficiency of developing software by integrating all the tools neededinto one, easy to use environment. This usually includes at least:

Syntax Highlighting Highlighting keywords in the language used to make iteasier to read.

Compiler “A compiler is a computer program that translates a computer pro-gram written in one computer language (called the source language) intoan equivalent program written in another computer language (called theoutput or the target language).”[Wikipedia.org, 2005]

Debugger “Debuggers are software tools which enable the programmer to mon-itor the execution of a program, stop it, re-start it, run it in slow motion,change values in memory and even, in some cases, go back in time.”[Wikipedia.org, 2005]

1.1.1 History of IDEs

The first IDE was required for the first language designed to be written byusers at a terminal (as opposed to feeding in punch cards), BASIC in 1964. TheDartmouth Time Sharing System (DTSS) [Wikipedia.org, 2005], allowed severalusers to edit and compile source files over basic text-terminals.

Vi and other similar terminal-friendly text editors are occasionally used today,but have largely been replaced by integrated solutions. These text-editors allowsome syntax highlighting and basic editing, using the keyboard to move thecursor around source files. Compilation usually requires switching to anothershell and running a compiler on the current source file, waiting for it to compile,

9

1 Introduction and Background

noting the line number of any errors and then switching back and trying to fixit, ad infinitum, until the program is finished.

EMACS

EMACS was first released in 1980 as one of the first real-time display editors[Stallman, 1980], i.e. it was possible to see what you were typing. It is a veryflexible editor based around lisp functions. These make it highly customisableand indeed after 25 years, there are a lot of plug-ins or modes available with vary-ing degrees of functionality. They generally provide rapid access to the shell/-compiler and perform syntax highlighting as a minimum. However, EMACSis quite different to other editors and does not use most of the common com-mand conventions (i.e. the keyboard shortcuts used in the vast majority of otherwindowed programs like [Ctrl-X] for cut). This is because it pre-dates the con-ventions and has a loyal user base. Unfortunately, this gives creates a long, steeplearning curve. In its day, it was considered big, slow and provided too much un-necessary functionality [internal EMACS documentation]. Current PCs shouldhave no trouble running it and indeed the opposite is now true. It is compara-tively light weight with a minimal GUI. The user interface is especially telling,revealing EMACS’s age.

Despite the latest version (21.3) being released in 2004, it still assumes thatmost people will be using it over an ASCII terminal. Everything is still com-pletely text-based apart from a bare minimum of a tool bar, which makes itfeel clunky and less approachable than modern GUIs that most people will bemore familiar with. Thus, in the course of evaluating EMACS, I was pleasantlysurprised to find that it does support “recent” innovations like a (scroll-wheel)mouse and standard OS open-file dialogues. A quick, informal questionnaire ofComputer Science students reveals a big rift. Of the small number of people thathave attempted to use EMACS, approximately 55% found it too difficult to useand use a more modern editor. The remaining minority, presumably the patientones, admit that it took them a long time to get used to, but now find it veryefficient for editing individual files.

“Despite the advent of WYSIWYG editors and graphical symbolic de-buggers, an easy way to pick a fight in a group of software engineersis to express a preference for one of the two old war horses vi andemacs. Both are horrendously unusable, yet the loyalty remains andthe battles rage on.”[Sellers, 1994]

An interesting comparison of EMACS versus several other Java IDEs can befound by Coleman et al. [2004]. It explains that although EMACS does supporta lot of the advanced features seen in modern GIDEs (see below), it is very ’old-school’, and does not work as fluidly or as easily. However, compared to theGIDEs, it is very fast and very lightweight.

10

1.1 What is an IDE and what are the advantages of using one?

1.1.2 Graphical IDEs

Graphical IDEs are now more common and integrate the different processesmuch more closely. e.g.

Integrated Compilation Avoids continual task switching and repetitive com-mand line use by giving easy access to the compiler and the results. Mod-ern IDEs then usually highlight problems in the source code and may sug-gest corrections.

Source Navigator There is often a tree view of the source code in each file togrant rapid access to each section for faster editing.

Projects Multiple source and other files can be grouped into projects. Thismakes it easier to organise large developments and means that dependen-cies can be looked after automatically.

Common GIDEs available include Microsoft Visual Studio [http://msdn.microsoft.com/vstudio/], KDE’s KDevelop [http://www.kdevelop.org/], Borland’s range [http://www.borland.com/], NetBeans [http://www.netbeans.org/] and Eclipse[Eclipse.org, 2005]. A brief comparison of some of them with regard to RADcan be found in McAmis [2004] and Java IDE comparisons in Neat [2005]. MostIDEs focus on one particular programming language. Some current IDEs sup-port multiple languages and/or use a plug-in system to allow their IDE to beextended with support for new languages. This means that a developer gets aconsistent experience and does not need to learn new tools whilst still being ableto choose a suitable language for each task in a large development. Perhaps thetwo biggest names with this capability are Microsoft Visual Studio .NET andEclipse. .NET uses special implementations of BASIC (VB), (Visual) C/C++ andJava (J#, C#) which compile to an intermediary format for use on various Oper-ating Systems (OSs) with the .NET framework installed. As such, elements canbe cross-referenced by different languages, encouraging re-use.

1.1.3 NetBeans

NetBeans is an open-source graphical IDE for Java. Primarily supported by SunMicrosystems, it is available with the standard Java Development Kit (JDK) dis-tributions and is thus quite well-known.

It is written in Java and suffers from a long startup time as with many otherJava applications such as Jedit [http://www.jedit.org] and Eclipse. NetBeans usesSwing for its UI. While it is not as obvious (ugly) as many other Java applications(see figure 1.1), it is still not up to the standards of Eclipse’s SWT (figure 4.1).SWT is discussed in more detail in section 3.1.1. NetBeans is quite powerful,supporting refactoring and code-completion and all the usual features of a GIDE(projects, source navigator etc.) Errors are marked with red wavy lines withoutthe need for explicit building.

11

1 Introduction and Background

Figure 1.1: Comparing Swing in NetBeans and JEdit

NetBeans includes some powerful visual programming tools for designingSwing dialogues in a similar manner to Microsoft’s Visual Studio. Buttons andother widgets can be dragged into position and then associated to sections ofcode to run when the button is pushed. This greatly simplifies the programmingof user interfaces.

“Eclipse is an IDE for anything and nothing in particular” Eclipse.org [2005]

Eclipse is an open source framework based on plug-ins [Lüer, 2003, OTI, 2003,Clayberg and Rubel, 2004]. It includes powerful support for standard Javawhich is very portable, running on many different platforms including Linux,Solaris, Windows and MacOS. Being open-source and plug-in based allows thecreation of extra plug-ins allowing Eclipse to be used as an IDE for anything.

1.2 Finding the “best” way to write an IDE

What makes a good IDE? How can they be compared and what features should Iaim to include in my implementation in order to produce the best result? The fol-lowing references all compare several IDEs from differing viewpoints. McAmis[2004] focuses on RAD, Neat [2005] compares features for Java and web devel-opment and Coleman et al. [2004] compares an old-school editor, EMACS withits younger competition. Despite these varying views, they all look at a similar

12

1.2 Finding the “best” way to write an IDE

set of criteria and draw similar conclusions. Thus, the important criteria can bededuced:

Ease of use What’s the learning curve like? How convenient is access to com-monly used features? How often does concentration have to be taken offthe source to use the mouse? How easy to remember are the keyboardshortcuts?

Features and functionality How much quicker does it make writing code com-pared to a standard text editor and a command line compiler? How mucheasier is it?

Performance This is especially important in code-completion. It could take along time to search through all the code to find suitable completions butthen it would have been quicker to type it manually, so its value is lost.

IDE Plug-in support The referenced comparisons look at ease of plug-in cre-ation and availability of plug-ins to allow bespoke needs to be met. Forthis project, easy plug-in creation is obviously a real boon.

1.2.1 Eclipse vs. NetBeans

Two popular GIDEs are evaluated and compared below.

Ease of Use Compared to Eclipse, NetBeans is very similar to use. However,it does not offer corrections for errors and useful code generation tools(like creating the skeletons for inherited abstract methods) are hidden inmenus. Eclipse offers corrections and skeleton method insertions automat-ically upon detection of errors and unimplemented methods.

Features The visual design functionality of NetBeans is excellent for creatingAWT/Swing Graphical User Interfaces (GUIs) and Eclipse does not in-clude this ability as standard. However, Eclipse has similar functionalityfrom a plug-in [http://www.eclipse.org/vep/] which also allows creation ofSWT GUIs.

Performance NetBeans provides auto-completion suggestions and the associ-ated JavaDoc exactly like Eclipse. However, it briefly pops up a “pleasewait” message while it calculates the suggestions. This is very brief butshouldn’t be necessary if performance was high enough. The navigatorwhich provides a tree view of the source code is exceptionally slow, takingseveral seconds to parse the code.

Plug-in Support There are far fewer available plug-ins for NetBeans. It makesno claims like Eclipse of being an IDE for anything and focuses on Javaand Web Services development. There are not the high level frameworks

13

1 Introduction and Background

for plug-in creation like in Eclipse and NetBeans plug-ins do not make thesame use of XML files to reduce load times. Buffone [2004] is an introduc-tion to creating plug-ins for the two platforms, noting the differences.

1.2.2 Eclipse vs. EMACS

Using the above criteria, the best of the old (EMACS) is compared to one of thelatest graphical IDEs, Eclipse. Results are shown in table 1.1.

Criterium Eclipse EMACSEase of Use Good for experienced de-

veloper. Overwhelming tonovice. Keyboard shortcutslabelled for most menu ac-tions, uses standard win-dowing conventions (e.g.[Ctrl-X] is cut)

Too many features are hid-den and difficult to find.Many users don’t realisethat it has so many features.Steep learning curve, old-school UI scares new users.Unusual default keyboardshortcuts but configurable.

Features State of the art includingrefactoring and documenta-tion on demand.

Many features comparableto modern IDEs. Code navi-gation could be improved.

Performance Start up times are slow.Code suggestions andtext-hover documentationtooltips are pretty quick.

Very lightweight and veryfast.

Plug-in Support Extensive, totally plug-inbased. Requires XML decla-ration and Java implemen-tation.

Extensive, built aroundLisp functions.

Table 1.1: Summary of comparisons between Eclipse and EMACS

1.2.3 Lisp vs. Java

Coleman et al. [2004] lists Lisp as a disadvantage of EMACS but with no justi-fication. Certainly, trying to code in Lisp without an editor that does bracketmatching is very difficult but otherwise, it is quite an elegant functional lan-guage and its relative, Scheme, is used to teach beginners the principals of pro-gramming at the Computer Science dept. at the University of York, UK and theMIT in Massachusetts. Comparing programming languages is never easy —they’re all Turing complete and hence equally powerful but each have differentstrengths. Some can more succinctly define certain patterns and some are more

14

1.2 Finding the “best” way to write an IDE

readable in certain situations. http://shootout.alioth.debian.org/great/ allows com-parisons of many languages, including many flavours of Lisp and Java, basedon several benchmarks. The weightings for speed, memory use and lines ofcode needed (LOC) are variable. For creating a plug-in, obviously if it can bedone in less lines, it will probably take less time to write which implies it willbe easier. Thus, I tested only the benchmarks to do with parsing (count-words,regex, spell-check, word-frequency) with equal weights (of 4), and assigned thefollowing weightings:

Full CPU time This is the full time it takes to run a program including startinga VM if necessary. This usually makes Java appear very slow. It gives anindication of speed which is very important to provide a fluid UI : 2

Memory Usage Most PCs these days have lots of spare RAM anyway, so this isnot so important : 1

Lines of Code Ease of plug-in creation is essential for this project : 3

It should be noted that none of the chosen benchmarks have been imple-mented in EMACS Lisp so I will compare the standard Java results to the highestscoring Lisp results.

AWK beats all the other languages hands down with a score of 45.99. AWKis “a special-purpose programming language that makes it possible to handlesimple data-reformatting jobs with just a few lines of code” [GNU AWK Home-page1]. This concision is well rewarded in these tests.

Java comes about 2/3 down the list with a score of 19.722 with 3 of the 4benchmarks implemented.

Right behind Java is NewLisp with a score of 18.68 and all 4 benchmarks im-plemented. If the extra benchmark (regex) is ignored, (New)Lisp falls behind alittle further with a score of only 15.84. In this instance, Java would appear to beslightly better. But what if only lines of code are taken into consideration? Thisgives Java a similar lead over Lisp CMUCL. Only considering CPU time alsohas little effect.

Hence, it appears that Java is a superior language for the creation of parsersand thus development support for languages.

1.2.4 Object-Oriented versus Functional languages

An interesting question to ask is “What to do these results say about Object-Oriented and functional languages?” Is it because Java is OO that it beats Lispin the above benchmarks? The Great Computer Language Shootout results arerepeated in table 1.2 in full, rounded and sorted to show only OO and functionallanguages (as determined by Google’s Directory).

1http://www.gnu.org/software/gawk/gawk.html2for details of how the scores are calculated, see the webpage http://shootout.alioth.debian.org/

great/

15

1 Introduction and Background

OO FunctionalLanguage Score Language ScoreOCaml 34 OCaml 34Perl 33 Clean 25Ruby 32 Scheme 23Python 29 Lisp 16Pike 29Eiffel 28 Average 24.5Lua 28C++ 26 Haskell 13Tcl 26 Mercury 12SmallTalk 22PHP 21C# 21Java 20Scala ? Scala ?Average 26.8 Average 20.5

Table 1.2: Parsing benchmark results comparing OO and functional languagesHaskell and Mercury did not complete all the benchmarks and thus have anomalously

low scores. They are included here for completeness.

Firstly, it can be seen how much more popular OO languages are. This mayimply that they are somehow developer-friendlier than functional languages,or perhaps just a current trend. The averages also show a small but not in-significant advantage to OO languages. This would suggest that (using the 2:1:3weightings from earlier) OO languages can more concisely and quickly performparsing type operations. However, Java comes at the bottom of the OO table.

An exciting result is that OCaml which is an OO extension of Caml, a func-tional language, comes at the top of both tables. This has possible implicationsfor Scala, the language that is introduced in the next section. It includes some ad-vanced OO features AND higher order functions. Would this hybrid be a bettersolution to writing parsers/plug-ins? The creators of Scala claim that functionallanguages are better for parsing which is why they added functionals [Oderskyet al., 2004a]. Yet, the results above would seem to disprove this. In which case,is there another reason for OCaml coming top?

1.2.5 EMACS Scala mode vs. Scaliptor 0.1

The first version of Scaliptor had similar features to the Scala mode for EMACSthat is distributed with Scala. EMACS’s syntax highlighting is better than Scalip-tor’s keyword highlighting and it provides some basic access to the interpreter,but this does not appear to work. However, they are roughly comparable and I

16

1.3 Scala — The scalable programming language

will make a comparison on lines of code.EMACS: 3 files totalling 30KiB. Eclipse: 15 files totalling 21KiB.3

Thus, we can see while Java appears to be more concise in terms of LOC, it’salso more complicated as this is spread over a large number of files. This is dueto the greater structuring and abstraction in the Eclipse framework. However,Eclipse should already have abstracted as much common behaviour as possible,so any new work that has to be done for a plug-in is unlikely to be re-used.

But, there is more to the story than mere LOC and number of files. Eclipseprovides the PDE to assist making plug-ins. This feature set includes wizardsand manifest editors to generate some of the necessary code automatically. Tem-plates exist to create example plug-ins that do anything from showing a view,to a full blown XML editor. EMACS does not provide this kind of assistance tocreators of its modes.

1.3 Scala — The scalable programming language

Listing 1.1: Scala says “Hello”object HelloWorld {

def main ( args : Array [ S t r i n g ] ) = {Console . p r i n t l n ( " Hello world ! " ) ;

}}

Scala [http://scala.epfl.ch/] is a new language developed at the EPFL (École Poly-technique Fédérale de Lausanne — see http://www.epfl.ch/Eindex.html) in Switzer-land. As stated by Odersky et al. [2004a], it was designed for greater abstraction,composition, and decomposition to assist in creating component systems. Tothis end, everything in Scala is an object, including values and functions. It isalso designed to integrate with Java and C#, adopting large parts of their syn-tax and type system and compiling to Java class files or .NET IntermediaryLanguage (IL). However, the creators of Scala also felt that object-orientationwas not an elegant solution to the current trend in programming; web servicesand distributed software, particularly with respect to XML (eXtensible Mark-upLanguage — see http://www.w3.org/XML/) processing. Odersky et al. [2004a]claim that functional languages are better at this sort of work, so they createda hybrid Object-Oriented (OO), functional language. Scala has first-class andhigher-order functions, and an algebraic type system (on values) like functionallanguages. The type definitions can also be hierarchical, like OO types, withScala’s mixin and trait compositions allowing path-dependent types, similar toEiffel4.

31 KiB = 1024 bytes as described in the IEC’s standard for binary prefixes [http://physics.nist.gov/cuu/Units/binary.html]

4Bertrand Meyer’s Design By Contract language — http://www.eiffel.com

17

1 Introduction and Background

The above “hello world” example demonstrates some of the similarities anddifferences between Scala and Java. I assume here that the reader has a goodworking knowledge of Java. At first glance, the code appears very similar. Thereis the familiar main method calling println. The usual C-style braces are in theright places and although it can’t be seen here, comments are the same as Javaand C++. However, Scala tries to have a more standard syntax than Java does.Thus, every element begins with a keyword. Notably, even method declara-tions/def initions must begin with the keyword def. Furthermore, arrays arestandard classes that take a type parameter and array accesses are simply func-tion applications and so use normal parentheses. Static elements are replacedby elements in the singleton object. Variables and constants are declared withthe keywords var/val respectively, using the UML5 style id : type instead ofprefix types like Java/C. Since Scala does not distinguish between expressionsand statements, every statement must return a value. So unit is used instead ofvoid.

Most of the new features of Java 1.5/J2SE 5.0 are already in Scala includinggeneric type parameters (as seen in the array above) and enhanced for-loops tomore concisely iterate over array/list elements in a type-safe manner.

1.3.1 Mixins

Mixins are subclasses [Bracha and Cook, 1990] which allow multiple inheritancebut avoid issues like the diamond problem [Wikipedia.org, 2005] where a class,D, inherits from two different super-classes, B and C, which have themselves acommon superclass, A (see figure 1.2). This raises questions about which ver-sions of A’s methods are inherited by D; those implemented by B or those fromC.

Mixins allow you to mix the functionality of a class C in with a class D that isa subclass of B iff C and B have a common superclass (see figure 1.2).

The code in listings 1.2,1.3 shows how Scala’s mixin composition resolves theambiguities possible with multiple-inheritance. All the classes involved in thisexample inherit from the class Buffer[T] and override its definition of the method’forall’. [T] makes the class generic and denotes a type parameter similar to thenew generics and collections in Java 1.5 (a.k.a. J2SE 5.0).

1.3.2 Higher-order functions

Listing 1.2 also demonstrates Scala’s functional nature. forall and exists are higherorder functions with the following type:

(T → boolean) → IterableBuffer → boolean. (The second argument is thereceiving object (the IterableBuffer), not an explicit parameter.)

5Unified Modelling Language from the Object Management Group (OMG) — http://www.uml.org

18

1.3 Scala — The scalable programming language

Figure 1.2: Diamond problem and mixin solution

That is to say that they are functions which take a function as an argument.This argument, p, can then be applied within their definitions.

1.3.3 Traits

“Multiple inheritance is good, but there is no good way to do it.”[Steve Cook, OOPSLA6 1987]

Traits were first conceived by Schärli et al. [2002a,b] to improve reuse in OO pro-grams and managed a 25% reduction in the number of method implementationsand an overall 10% reduction in the size of source code. They aim to provide alevel of structuring between methods and classes when single-inheritance is notenough. Although multiple inheritance and mixins are a partial solution, theypresent issues such as what happens to a class lower in the hierarchy when some-thing changes. Traits are abstract classes that must not contain state, similar toJava interfaces although concrete method implementations are allowed. In thisway, smaller features than entire classes can be reused.

6Object-Oriented Programming, Systems, Languages & Applications conference

19

1 Introduction and Background

Listing 1.2: Example Scala code for an iterable-buffer from Odersky et al. [2004a]c l a s s I t e r a b l e B u f f e r [ T ] extends Buf fer [ T ] {

def f o r a l l ( p : T => Boolean ) : Boolean = {val i t = elements ; var re s = t rue ;while ( r es && i t . hasNext ) { r es = p ( i t . next ) }r es

}

def e x i s t s ( p : T => Boolean ) : Boolean = {val i t = elements ; var re s = f a l s e ;while ( ! r es && i t . hasNext ) { r es = p ( i t . next ) }r es

}}

Listing 1.3: Example Scala code showing how it can disambiguate with multipleinheritance adapted from Odersky et al. [2004a]

c l a s s MyStack [ T ] extends Stack [ T ] / / s u p e r c l a s swith I t e r a b l e B u f f e r [ T ] / / mixinwith ComparableBuffer [ T ] { / / mixin

/∗∗ comp i l e−t ime e r r o r would have been r a i s e d due t o a m b i g u i t y∗ so t h e f o l l o w i n g e x p l i c i t o v e r r i d e i s n e ede d t o d i s a m b i g u a t e∗ /

override def f o r a l l ( p : T => Boolean ) =super [ I t e r a b l e B u f f e r ] . f o r a l l ( p ) ;/ / p a r a m e t e r t o s u p e r s p e c i f i e s which p a r e n t we want t o use

}

“They provide structure, modularity and reusability within classes,but they can be ignored when one looks at the way that classes relateto each other. Traits provide an excellent balance between reusabilityand understandability, while enabling better conceptual modelling.Moreover, because traits are concerned solely with the reuse of be-haviour, and not with the reuse of state, they avoid all of the im-plementation difficulties that characterize multiple inheritance andmixins.”[Schärli et al., 2002a]

Traits in Scala

Because a mixin is just a new way of using a class, they encapsulate state whichmeans that a class A can only be mixed in to another class B if A is not already

20

1.3 Scala — The scalable programming language

used by B as superclass or another mixin e.g. as in the diamond problem (fig-ure 1.2). Otherwise the state would be duplicated and there would consistencyissues. However, there are times when Odersky et al. [2004a] considered thistoo restrictive i.e. when the classes involved encapsulate no state (like Java inter-faces). Thus traits were incorporated into the language. Since they don’t containstate, it is legal for them to appear multiple times in a class hierarchy.

Example, with code from Odersky et al. [2004a] The class IterableBuffer, seenin listing 1.2 cannot be freely re-used. It can only be mixed in to subclasses ofBuffer. However, the functionality it provides, depends only on one of Buffer’smethods — elements, which returns an iterator. So, this could be expressed usinga trait:

Listing 1.4: An example trait

t r a i t I t e r a b l e [ T ] {def elements : I t e r a t o r [ T ] ; / / d e f e r r e d

def f o r a l l ( p : T => Boolean ) : Boolean = {val i t = elements ; var re s = t rue ;while ( r es && i t . hasNext ) { r es = p ( i t . next ) }r es

}

def e x i s t s ( p : T => Boolean ) : Boolean = {val i t = elements ; var re s = f a l s e ;while ( ! r es && i t . hasNext ) { r es = p ( i t . next ) }r es

}}

The methods forall and exists are defined as before in listing 1.2 while elementsis merely declared with no definition. This means that it is deferred, or in Java ter-minology, abstract. This trait can be mixed into any class which must in turneither implement a concrete version of elements or defer it to a child class/-trait/mixin.

“This principle is exploited in the following alternative definition ofclass IterableBuffer:

c l a s s I t e r a b l e B u f f e r [ T ] extends Buf fer [ T ]with I t e r a b l e [ T ] ;

” [Odersky et al., 2004a]

21

1 Introduction and Background

1.3.4 Existing support

The standard Scala distribution includes support for some editors includingEMACS but this is limited to syntax-highlighting, some auto-indentation andinteraction with the interpreter. This project was begun to supply more compre-hensive support for Scala. Learning a new language can be frustrating, espe-cially when the concepts are new. Any help that the tools provide can help toalleviate these issues.

1.4 Methodology

To enable maximum code re-use and least duplicated effort, I have decided touse the open-source bazaar method [Johnson, 2001, Raymond, 2000]. The bazaarmethod is a Rapid Application Development (RAD) method [Martin, 1991] andis ideal for small-scale, time-limited projects. As well as potentially having otherpeople contribute to the code, more importantly, it provides a large user base fortesting. Using Linus Torvald’s idea of, “Release early, release often”, a user canfind the errors for a developer, much quicker than the developer could do it him-self, resulting in a quicker route to high quality code (the interested reader is re-ferred to Challet and Le Du [2004], who demonstrate this). For safety-critical ap-plications, this method would be unsuitable as the programme must be demon-strated to be safe before it could be used in a real situation. However, for anon-critical application like this, it is a logical course of action. The worst casescenario for an error in this project would be that someone may lose some codethat they have been working on. While irritating, it is clearly not a catastrophe.(The usual practices of saving often and keeping backups7 would obviously mit-igate any damage.)

Requirements too, can often be augmented by the users. As they use the prod-uct, they realise what they think is missing and what they would most like it todo. These Requests for Feature Enhancements (RFEs) provide new requirementsor allow a developer to prioritise existing requirements. Combining all of theseelements results in a very rapid spiral development. The 4 stages, Requirements,Design, Implementation and Testing, are repeated very quickly and hence veryoften. This is why open source developments tend to have much longer versionnumbers, as they iterate constantly through the process, releasing often as theyfix another bug and/or release a new feature.

7Eclipse includes integration with the Concurrent Versions System (CVS) [http://www.cvshome.org/] to assist in this endeavour.

22

2 Requirements

The aim of the project is to create a system that integrates with Eclipse and as-sists users in the development of Scala code. Since a very similar system alreadyexists for Java code in Eclipse, it would be ridiculous to create requirementswithout first considering the requirements of this system. The JDT (see 2.1) wasprofessionally designed and implemented by IBM and others in the Eclipse com-munity in an open-source manner. Since this is how I plan to run my project,re-using as much of their successful material as possible is an obvious startingpoint.

2.1 The Eclipse JDT — Java Development Tools

The standard Eclipse distribution includes a feature-set called the JDT, or JavaDevelopment Tools [http://www.eclipse.org/jdt]. This collection of plug-ins al-lows Eclipse to assist in the creation of Java source code, compiling it to bytecode and running and debugging the classes. It is very powerful, includingsuch abilities as:

Refactoring Any Java element ( variable, class, package) can be easily renamedor moved to another class/package. Eclipse will then search the sourcecode for references to this element and correct the code to point to thecorrect location.

Auto-complete When [Ctrl-Space] or ’.’ is typed, Eclipse will generate a list ofpossible completions and fill in the chosen completion. This is most usefulto see the visible contents of a class. The JavaDoc [http://java.sun.com/j2se/javadoc/] documentation is also shown for each option so an informedchoice can be made as to which method/member is appropriate and whatthe parameters for a method should be.

Debugger A comprehensive debugger showing the source code, values of cur-rent variables and the current contents of the stack. Values of variables canbe changed on the fly without restarting the Java Virtual Machine (VM).Small changes to the source code can also be recompiled on the fly into therunning VM.

Package Explorer The workbench includes a view called Navigator which al-lows a user to explore the underlying file system of the workspace and

23

2 Requirements

open files for editing. However, for Java development, this is inconvenientas package names are often long and are represented in the file system asnested folders/directories. The Package Explorer flattens these packagesinto one folder on the screen as well as offering shortcuts to Java orientatedfunctions.

Java Perspective A perspective in Eclipse is an arrangement of views and theeditor window. The shortcuts enabled in the workspace are also selected.This reduces clutter from unneeded plug-ins and makes finding the func-tion you want much quicker.

Self-propagation As Eclipse is written in Java, if Eclipse can develop Java, thenEclipse can help extend itself. The PDE (Plug-in Development Environ-ment) is another feature-set for Eclipse to assist in writing Eclipse plug-ins.It requires the JDT as a prerequisite.

2.2 Other projects of a similar nature and scale

When the Eclipse community created the JDT they had the huge resources ofIBM to throw at it. The current version (3.0) is the result of several years work,many paid developers and thousands of people in the user-base, reporting/fix-ing bugs and requesting features. Obviously, it would be unfair to compare thisproject to the JDT, with its very limited time-frame, one part-time undergradu-ate developer and only several hundred downloads by the open-source commu-nity. There are many smaller scale plug-ins for Eclipse to assist in the creation ofsource code in different languages. These would be more comparable and bettersuited for evaluation purposes. The following plug-ins were done by just oneor two people over about 1 year. This is slightly longer than available for thisproject but is a much better example for evaluation compared to the JDT.

Functional Programming for Eclipse A project to add support for functionallanguages, currently just Haskell (version 0.6) and to a lesser extent OCaml(version 0.1). Approximately 1200 downloads at time of writing (January2005). See http://eclipsefp.sourceforge.net/. Mostly done single handedly byLeif Frenzel (http://www.leiffrenzel.de) since April 2004.

Eiffel for Eclipse A plug-in that adds syntax highlighting and compiling sup-port for Bertrand Meyer’s Design By Contract language. See http://www.eclipse.audaly.com/. Created and maintained by François Audineau andMathieu Hélias since 2004.

24

2.3 Generated Requirements

2.3 Generated Requirements

Due to the nature of RAD and open-source development, requirements are con-stantly evolving, changing and tightening. The list given below is a statementof intent and represents what was hoped to be achieved when the project began.As the project progressed, more specific requirements became apparent and nec-essary. Also as mentioned above (see 1.4), users requested certain features thatwere not originally on the requirements list and were subsequently added if ap-propriate to the project and the time-constraints. Hence the Scala DevelopmentTools’ initial requirements are:

1. Syntax Highlighting for Scala source

a) Keyword and literal Highlighting

b) Advanced, context sensitive syntax highlighting

2. Use of JDT Package Explorer to explore Scala packages

3. Scala Perspective

4. Compiling and error-marking Scala sourceIn ascending order of difficulty depending on time available:

a) Adding a button to call the compiler manually

b) Automatically building on detection of change — must be quick andnot interfere with interface responsiveness.

c) Generate an Abstract Syntax Tree for analysis for 1b, 7.

5. Scala Launcher and Debugger, re-using as much code from JDT as possiblesince Scala compiles to Java byte code.

6. Wizards to assist in generation of new Scala elements

a) New Project

b) New Class

c) New Object

d) New Trait

7. Code Assistance and quick auto-completion of Scala source . As discussedin section 1.2, this must be very quick or it becomes worthless.

a) members of current class

b) visible members of class preceding current ’.’

c) first-class functions with appropriate footprint

25

2 Requirements

8. Integrate with Eclipse’s CVS and Team extensions to assist in distributeddevelopment

9. Preferences as necessary

10. All the above elements must integrate into the standard Eclipse UI andfollow Eclipse best-practices1 as stated in Clayberg and Rubel [2004].

1RFWS — Ready For Websphere Studio, IBM’s validation program for its commercial packageof Eclipse. Recently updated to ’Ready for IBM Rational Software’. See http://www.developer.ibm.com/spc/rfws.html

26

3 Design

3.1 The Eclipse API

The design of an Eclipse plug-in is largely predefined by the constraints of theEclipse API which will be explained below.

Eclipse was designed from the start to be completely plug-in-based. The baseframework without any functionality is called the workbench. The workbenchspecifies Extension Points where functionality can be extended. These can bethought of as sockets into which new functions can be plugged. As such eachplug-in must specify one or more extension points that it wants to extend from.These are specified in the plug-in’s manifest — an XML file which allows Eclipseto be as lazy as possible. One of the few disadvantages of Eclipse is a very longstart-up time. In order to keep this down to a minimum, best practice dictatesthat all work should be postponed until absolutely necessary. This is known asbeing lazy. The plug-in manifest helps in this regard as Eclipse can add all thenecessary hooks and User Interface (UI) components for a new plug-in merelyby scanning the XML file. Only when a button is pressed or some functionalityfrom the plug-in is actually required are the class files loaded and run. Themanifest also helps to maintain the platform independence that Java brings. Allextension points can be extended by more than one plug-in. Plug-ins can alsospecify their own extension points making Eclipse infinitely extensible.

The following XML code is a sample plug-in Manifest for an example plug-in.It extends the view extension point only, therefore it just provides a view. Assuch, it is the “Hello World” example for Eclipse plug-ins. Using the Plug-inDevelopment Environment (PDE) feature of Eclipse, means that much of thiscode is generated automatically or has wizards to make it easier to edit.

Firstly the plug-in itself is declared, including name, version number andunique ID. This ID must be unique for any possible plug-in that could be in-stalled. Therefore the Java package naming convention is used. That is, theID should start with the creator’s internet domain name reversed, for exam-ple, uk.ac.york.cs.pluginName would be a suitable ID for a plug-in called “plug-inName” from the Computer Science Dept. at the University of York.

The runtime section details how the plug-in should be compiled and distributed.The requires section lists other plug-in IDs that are required by this plug-in andthus usually include several from eclipse.org.

Following that is the declaration of the extension point that is being pluggedinto. This, like everything declared in the manifest will have a unique ID as

27

3 Design

explained above. Here, the plug-in provides a view so it extends the org.eclipse.ui.views extension point. The view is placed in a category to quickly find it inthe eclipse menus. It is assigned a name, an ID and an icon.

<?xml version=" 1 . 0 " encoding="UTF−8" ?><? e c l i p s e version=" 3 . 0 " ?><plugin

id=" h e l l o "name=" Hello Plug−in "version=" 1 . 0 . 0 "provider−name=" "c l a s s =" h e l l o . HelloPlugin ">

<runtime>< l i b r a r y name=" h e l l o . j a r ">

<export name=" ∗ "/></ l i b r a r y >

</runtime>

< r e q u i r e s ><import plugin=" org . e c l i p s e . ui "/><import plugin=" org . e c l i p s e . core . runtime "/>

</ r e q u i r e s >

<extens ionpoint=" org . e c l i p s e . ui . views ">

<categoryname=" Sample Category "id=" h e l l o ">

</category><view

name=" Sample View "icon=" icons/sample . g i f "category=" h e l l o "c l a s s =" h e l l o . views . SampleView "id=" h e l l o . views . SampleView ">

</view></extens ion>

</plugin>

For a more complex example, an extract of Scaliptor UI’s manifest is shown inlisting 4.1 (section 4.2). This shows the declaration of the wizards and exempli-fies how a plug-in can plug in. It can also be seen how Eclipse can provide all thenecessary UI components and hooks without having to load any class files fromthe plug-in. The icon, category and description are all contained in the XMLmanifest. When the button is clicked, the named class is loaded and the wizard

28

3.1 The Eclipse API

is launched.An extract of the implementation of the sample view is shown below. The

API will call createPartControl with a Composite widget which will act as thescreen area for the view to occupy. This method creates some data and a suitableviewer (a TableViewer). TableViewers are designed for visualising data as a table.Its constructor requires a parent widget to place itself in and some optional stylearguments. In this example, the viewer has been setup to allow selection ofmultiple items and have vertical and horizontal scroll bars.

A ContentProvider supplies the data in a standard way and a LabelProvider cre-ates a text label and icon for each data element. This separation of data, modeland view is typical of Eclipse structures and is explained in greater detail insections 3.1.4 and 4.6.

Listing 3.1: Extract of hello.views.SampleView/∗ ∗∗ Thi s i s a c a l l b a c k t h a t w i l l a l l o w us∗ t o c r e a t e t h e v i e w e r and i n i t i a l i z e i t .∗ /

public void c r e a t e P a r t C o n t r o l ( Composite parent ) {viewer = new TableViewer ( parent , SWT. MULTI | SWT. H_SCROLL

| SWT. V_SCROLL ) ;viewer . setContentProvider (new ViewContentProvider ( ) ) ;viewer . se tLabe lProvider (new ViewLabelProvider ( ) ) ;viewer . se t Input ( getViewSite ( ) ) ;makeActions ( ) ;hookDoubleClickAction ( ) ;contr ibuteToAct ionBars ( ) ;

}

makeActions() is a method that creates two sample Actions which are simplyempty event triggers with icons and text labels. These get added to the view’smenu in the contributeToActionBars() method.

There are also light weight components called Fragments. These can be usedto extend a plug-in with things like language packs (internationalisation) or OS-dependent code. They define no extra extension points and should not be usedto add functionality, rather just a choice.

Collections of related plug-ins can be grouped together into distributable Fea-tures. Features can be added to an Update Site so that a user can simply input anURL into a dialogue box and Eclipse will automatically download, install andupdate the plug-ins and sub-features contained in the feature. This helps withease-of-use especially when many varied plug-ins are installed.

3.1.1 The Standard Widget Toolkit

Eclipse does not use Java’s Abstract Window Toolkit (AWT) [http://java.sun.com/j2se/1.4.2/docs/guide/awt/] or the Java Foundation Classes (JFC) [http://java.sun.

29

3 Design

com/products/jfc/] (better known as Swing) to create its Graphical User Interface(GUI). Swing applications are instantly recognisable as being Java — they standout from the platform’s native applications and are often considered uglier (al-though it is getting better). IBM and the other Eclipse developers decided touse the underlying platform’s own widgets to create the GUI. This makes it lookmuch cleaner and more integrated with the platform. This new toolkit is knownas SWT — the Standard Widget Toolkit [http://www.eclipse.org/swt/]. SWT wasoriginally designed for use on small J2ME (Java 2 Micro Edition) devices wherememory and processing resources are scarce and thus where Swing cannot beused. Therefore SWT is optimised for direct access to native widgets and haslittle overhead. A brief history of SWT can be found in Clayberg and Rubel[2004, Chap. 4.1]. For a discussion on the relative merits of AWT vs. SWT, the in-terested reader is referred to Marinilli [2003] and Cioroianu [2004]. Some moreadvanced features for handling common UI tasks such as text and structuredviewers, dialogue boxes etc. come from a framework called JFace. SWT main-tains its platform independence by having a different native library for eachplatform/windowing toolkit. When its widgets are used in a Java applicationor Eclipse plug-in, the source is still completely portable.

3.1.2 The basics of a text-editing plug-in

The Eclipse API defines not only the framework for a generic plug-in but alsoprovides a lot of material for source-editing plug-ins [Audineau and Hélias,2004]. Figure 3.1 shows which classes are provided by Eclipse and what must beoverridden. TextEditor provides the basic functionality for editing text. This isprovided with a SourceViewerConfiguration which adds support for syntax high-lighting and content assistance. To perform these tasks, the system must besupplied with information such as:

• the keywords in the language

• the colours in which they should be highlighted

• what constitutes whitespace

Keywords are detected using a RuleBasedScanner. This has rules for detectingwords, end of line comments etc. given an array of the keywords in the lan-guage, the comment symbol etc. The colours are organised in a ColorProviderwhich contains a mapping between sets of keywords and language features andthe colours, typeface etc. that they should be shown in.

As words are typed into the editor, obviously the display needs to be updatedand recoloured. This is where the PresentationReconciler’s role lies. Changes tothe text are recorded as damage that must be repaired. Hence the Reconciler issupplied with several DefaultDamagerRepairers for each content type defined inthe PartitionScanner. This contains some extra rules on how to detect different

30

3.1 The Eclipse API

sections of the document such as method bodies and comments. It also storesthe constants to represent the different content types in the document such askeywords, normal code, comments that are passed around to identify each to-ken.

An optional ContentAssistant can be supplied to the SourceViewerConfigurationto provide auto-complete suggestions. The implementation of this is left opento the developer, as long as it implements the IContentAssistant interface. Someabstract implementations are also supplied however.

Figure 3.1: A simple Scala source editing plug-in. Classes without "Scala" intheir name are supplied by Eclipse.

3.1.3 User Preferences

In order to provide user modifiable options, Eclipse permits plug-ins to con-tribute to the global Preferences pages. To do this, an implementation of a Prefer-encePage must be named in the manifest under the appropriate extension point.Each page is identified separately in the preferences dialogue and pages can con-tain pages, so that many preferences for a single plug-in can be collated together

31

3 Design

and hidden, or plug-ins could contribute pages to other plug-ins.The easiest page is one inherited from FieldEditorPreferencePage as this is al-

ready set up to use the convenient FieldEditors provided by JFace. These lie at alevel of abstraction above SWT and provide a combined cell editor for differenttypes of entry (strings, files, booleans for example) and a label. The values ofthe preferences are saved by the page when the user presses “OK”. This createsa text file with key/value pairs for each preference that is not at its so defaultvalue. Defaults are preserved in the source code for each plug-in or if not speci-fied take on a default default value specified in JFace. These defaults have to beinitialised when the saved file is read and this is handled by a PreferenceInitialiserin Eclipse 3.1. This is called automatically when the plug-in receives a call tofetch a preference.

Accessing preference values is done via a singleton instance (getDefault() is astatic method to return the current instance) of the plug-in’s own class. This re-turns a Preferences object for the plug-in which can then be asked for preferencesof a certain type using the key defined when the preference was created. e.g.

P re fe r en ce s p r e f s =S c a l i p t o r P l u g i n . ge tDefaul t ( ) . ge tP lug inPre ferences ( ) ;

S t r i n g path =p r e f s . g e t S t r i n g ( S c a l i p t o r P r e f e r e n c e P a g e .COMPILER ) ;

Path outputdir =new Path ( p r e f s . g e t S t r i n g ( S c a l i p t o r P r e f e r e n c e P a g e .OUTPUT ) ) ;

boolean debug =p r e f s . getBoolean ( S c a l i p t o r P r e f e r e n c e P a g e .DEBUG) ;

3.1.4 Model-View-Controller architecture

Many features in Eclipse are based on the Model-View-Controller architecture[Sun Microsystems Inc., 2002, Hudson, 2003]. The idea behind MVC is to sepa-rate data from the ways in which it can be used. This promotes better decompo-sition/abstraction and encourages re-use.

Model The model is the persistent data store that represents something in thereal world or whatever domain you are modelling. Usually no assump-tions are made about the model so the developer is free to implement ithowever they consider best.

View A view is the visual representation of the model. A model can have morethan one view.

Controller The controller is the element that ties the model and view together.The model must have a way of notifying the controller whenever it changes.The controller will then update its internal representation and in turn up-date the view(s). When a user interaction or other event changes some-thing in the view, messages/requests are sent the other way i.e. the view

32

3.2 Target

passes the command to the controller who notifies the model that it shouldchange. The model then notifies the controller of the change who refreshesand updates the view.

Figure 3.2: The Model-View-Controller architecture from Hudson [2003]

There should never be any communication between the model and view directly.Everything must pass through the controller to ensure proper separation andconsistency. See figure 3.2.

3.2 Target

When the project was begun Eclipse 3.0 was about to be released and the fi-nal milestones were available for testing. Thus, the early versions of Scaliptorwere targeted at Eclipse 3.0. Soon after the final version of Eclipse 3.0 was re-leased, work began on the next update which would include support for J2SE5.0, Eclipse 3.1. This should be totally backwards compatible with 3.0 but allowsthe use of the new Java features such as generics. Since Scala also has generics,this would be very useful in order to model it properly. Thus later versions weretargeted at Eclipse 3.1 Milestone 4. However, this shouldn’t be an issue as theAPI is compatible with 3.0.

However, in order to maintain full compatibility with Eclipse 3.0, all the codehad to be compiled to Java 1.4 standards which meant that it was not possibleto use the new features of J2SE 5.0. However, where appropriate, the improvedreadability and type safety offered by the latest release was written and com-mented out so that upgrading the code at a later date when J2SE 5.0 is moregenerally accepted will be trivial.

33

3 Design

3.3 Timetable

Following the principles of RAD, I will aim to create working versions often.Rather than the traditional model of creating complete parts that are useless ontheir own and thus only making a useful product when everything is complete,RAD states that is better to create a small ’whole’. It will perform a subset of thefunctions proposed for the final version completely and this ’whole’ can grow asthe project progresses. The following timetable details the rough plan for eachversion.

Version Features Release Datev0.1.0 Syntax highlighting 11.06.2004v0.2.0 Scala Projects and Wizards, build button Internalv0.3.0 Integrated building and error marking 14.07.2004v0.4.0 Improved building, maintenance Internalv0.5.0 Outline view 26.01.2005v0.5.2 Improved Outline and text-hovers 23.02.2005v0.6.0 Content assistancev0.7.0 Maintenancev0.8.0 Basic Debuggerv0.9.0 Improved Debuggerv1.0.0 Final

34

4 Implementation

4.1 Scaliptor’s structure

All Eclipse documentation strongly suggests separating user interface relatedcode and other (processing) code. This aids in abstraction, reuse and readability.The separation should be done at a plug-in level so nearly all ’plug-ins’ are actu-ally a feature consisting of at least two plug-ins. The UI plug-in should requirethe other one but not vice-versa. This ensures there are no circular dependencies.This project is structured as follows:

• Scaliptor Feature

– Scaliptor

∗ uk.ac.york.cs.scaliptor∗ uk.ac.york.cs.scaliptor.scala∗ uk.ac.york.cs.scaliptor.actions

– Scaliptor UI

∗ uk.ac.york.cs.scaliptor.wizards∗ uk.ac.york.cs.scaliptor.ui

· ScalaPerspective∗ uk.ac.york.cs.scaliptor.editor

Thus, the wizards, perspective, outline view and editor are located in theScaliptor UI plug-in and the code for parsing, modelling and compiling Scalais in the main Scaliptor plug-in.

4.2 Wizards

Scaliptor extends the newWizard extension point to provide wizards which as-sist users in the creation of new elements. Currently implemented are: newproject, new class, new object, new Trait.

To provide a wizard, two stages must be completed. Firstly, an implementa-tion of IWizard must be written. If the wizard is intended to create a new resourcesuch as projects and files, it should implement the extended form, INewWizard.

35

4 Implementation

This involves adding WizardPages in a certain order, verification code for the con-tents of the pages and almost certainly writing the pages themselves. This lattertask is simplified thanks to JFace, the collection of useful widgets and form fieldsto create dialogue boxes and preferences.

The second stage is to declare the wizards so that Eclipse can provide the UIelements and integrate them with the platform. For example, if a new wizarddeclaration specifies “project=true” then it should be located under the generalnew project wizards category as well as any other specified category.

Listing 4.1: An extract of Scaliptor UI’s manifest declaring the wizards<extens ion

point=" org . e c l i p s e . ui . newWizards "><category

name=" Sca la "id=" uk . ac . york . cs . S c a l i p t o r . ScalaCategory ">

</category><wizard

name="New Sca la P r o j e c t "icon=" icons/newscprj_wiz . g i f "category=" uk . ac . york . cs . S c a l i p t o r . ScalaCategory "c l a s s =" uk . ac . york . cs . S c a l i p t o r . wizards . NewScalaProjectWizard "p r o j e c t =" t rue "id=" uk . ac . york . cs . S c a l i p t o r . wizards . P r o j e c t ">

< d e s c r i p t i o n >Create a new P r o j e c t with a Sca la Nature

</ d e s c r i p t i o n ></wizard><wizard

name="New Sca la Class "icon=" icons/ S c a l a F i l e . g i f "category=" uk . ac . york . cs . S c a l i p t o r . ScalaCategory "c l a s s =" uk . ac . york . cs . S c a l i p t o r . wizards . NewScalaClassWizard "p r o j e c t =" f a l s e "id=" uk . ac . york . cs . S c a l i p t o r . wizards . Class ">

< d e s c r i p t i o n >Create a new Sca la c l a s s

</ d e s c r i p t i o n ></wizard>

</extens ion>

36

4.3 Projects and Natures

4.3 Projects and Natures

The new Project wizard asks the user for a name for the project and then createsa project with a scala nature. A project is a collection of folders, packages, sourceand binary files and details of required jars etc. that should be in the classpath.A nature describes what type of program the project is collating e.g. Java, plug-in, Haskell or Scala. Each nature can have at least one associated builder so thatbuilders/compilers are only called on appropriate resources.

4.4 Parsing Scala

The JDT includes its own fully fledged compiler and parser and can use this togenerate a complete concrete syntax tree of the code in a Java project. I hopedto do something on a slightly smaller scale for Scala. Once a model exists forthe code, it is not a big leap to visualising the model in the outline view andmarking basic errors.

Unfortunately, the popular compiler creators like Lex/Flex and YACC/Bi-son [http://dinosaur.compilertools.net/] are not capable of parsing Scala [MartinOdersky, Scala mailing list,2004] as it lies outside the LR(1) class of languages.ANTLR [http://www.antlr.org] is ANother Tool for Language Recognition writ-ten in Java. It can parse LL(k) languages for arbitrary k. Following the syntaxgiven in Odersky et al. [2004b], I began writing a Scala Recogniser. Unfortu-nately, ANTLR does not allow left-recursion in language rules. There are sim-ple methods to remove left-recursion [Lewis], but applying them to the severalpages of Scala syntax was not possible in the available time.

The next approach is to make use of the existing Scala compiler and extract in-formation from that. The staff at EPFL were quite helpful in this regard, makingthe source code available to me. Unfortunately, the compiler is not very matureand the code is very difficult to read, making use of special Java compilers suchas PiCo [http://lamp.epfl.ch/~zenger/jaco/], which adds support for extensible al-gebraic types to Java. So I was forced to write my own very basic parser formodelling the structure of the code and using the output of the binary Scalacompiler to find errors.

4.5 Building and error marking

Compilation of Scala code occurs automatically when a source file is edited andsaved using Eclipse’s build framework [Arthorne, 2004]. The save action trig-gers a call to the builder. The builder is supplied with a resource delta whichdetails which file has changed and optionally, how. This allows the compilerto be efficient and cause minimal interruption to the user, as befits a good back-ground process. From this list of changed resources, I used Java’s Process.exec()

37

4 Implementation

method (some code adapted from Hall and Brown [2001]) to call the ScalaC com-piler on each file. This requires that the plug-in know the location of the Scalainstall. This is gathered from a preference (see section 3.1.3). The compiled re-sources (class files) are marked as derived so they do not trigger excess builds.The location these derived files are placed in is also determined by a preferenceand is added to the ScalaC command. For debug purposes the command is alsooptionally appended with “-g” to force the creation of line markers etc. in theclass files.

When the compilation has completed, any output generated to StdErr andStdOut is parsed. This was achieved purely using the methods contained inJava.lang.String.

An example of output from ScalaC:

parsers2.scala:10: not found: type CharParsersabstract class ListParsers extends CharParsers {

^parsers2.scala:26: missing parameter type

val _ <- chr(’(’);^

parsers2.scala:27: missing parameter typeval es <- listElems ||| succeed(List());

^parsers2.scala:28: missing parameter type

val _ <- chr(’)’)^

parsers2.scala:33: missing parameter typeval x <- expr;

^parsers2.scala:34: missing parameter type

val xs <- chr(’,’) &&& listElems ||| succeed(List())^

parsers2.scala:42: not found: type Parsersclass ParseString(s: String) extends Parsers {

^7 errors found

Firstly, the output is split into lines. Each line is then searched for occurrences of“.scala”. This gives a position in the line from which the substring containing thename of the file can be extrapolated. The number after this position gives theline number of the error and the rest of the line describes the error. The next twolines highlight the error and can be used find its column number. This informa-tion is put into markers. Markers are an eclipse feature for editors. They are usedto mark parts of a file to allow quick access from a different view. Problem mark-ers contain line numbers, error descriptions and a severity rating. The severity

38

4.5 Building and error marking

attribute makes it possible to distinguish between warnings, errors and infor-mation points and change the colour of the visual indicators. However, ScalaCdoes not generate warnings, only errors.

The problem markers are collated in Eclipse’s Problems View. This shows allthe problems in the workspace in a table. Filters can be applied to show onlyproblems with the current project, file etc. When double-clicked from the table,the appropriate file is opened and the incorrect line is centred in the editor’sdisplay. A red cross appears in the margin of the line with details of the errorand a squiggly red line underlines the incorrect portion of the line. If the quickhelp feature is implemented, a light bulb will also appear by the red cross which,when clicked on, will offer suggestions to correct the problem. Before the file iscompiled again, all the existing error markers must be removed as these mayhave been corrected.

Figure 4.1: Error Markers in Scaliptor/Eclipse and Scaliptor’s Outline View

39

4 Implementation

4.6 Outline View

Based on the experience gained writing the parser for the compiler errors, Iwrote another line-based parser for Scala files. It is not a complete parser butis merely intended to discover the structure of the file and the names of all theelements in it.

The parser scans each line for certain keywords indicating the declaration of aScala Object, Class, method, variable or constant and creates a tree model of thefile. The parser is called from the ScalaContentProvider as explained below.

Figure 4.2: Classes required for the Outline View

The outline view is based around the Model-View-Controller architecture (see

40

4.6 Outline View

section 3.1.4). The model is controlled by the ContentProvider and the LabelProvider.They both use information from the model to provide a view — a tree view.

Eclipse assumes that an editor will want to implement an outline view andasks it for an adapter to provide a ContentOutlinePage. This page creates a Tree-Viewer and supplies it with a ContentProvider and a LabelProvider. The Content-Provider must update a model of the file as it changes and notify the viewer. Theviewer then requests an updated Label (which consists of text and an icon) andupdates its display.

The parsing is done in the model(File f) static method contained in the ScalaM-odeller class. As each structure is discovered, a new ScalaTree node is created andinitialised with:

name the name of the structure

type one of package, package declaration, import, object, class, method, vari-able or constant.

visibility whether the structure has private, protected or default (public) visibil-ity

offset the number of characters before the beginning of this structure countingfrom the beginning of the file

parent the enclosing structure. This is calculated based on probable/possibleprogramming styles e.g. a method is always inside a class. Scala’s appli-cation model is very flexible and strict rules like this are not always valid,thus this is the source of considerable errors. Improving the parser to de-tect change of scope properly so parent-child relations could be accuratelymodelled was outside the scope of this project, but would be a significantimprovement and should be considered for future work.

The root node is a special empty node representing the file. To reduce screenclutter, imports are folded into a single expandable node, by using an “importroot” node. Only import declarations are added to this node as children. Fur-thermore, this import root is only added to the proper root if import declarationsexist in the file.

4.6.1 model(File f)

The following Java code (listing 4.2) is an extract from the static model methodin ScalaModeller (see Appendix A). This will exemplify how the parsing is per-formed. At this point in the code, the file has already been read and convertedinto a string. This string has been split into lines and this code lies within theloop iterating through each line. The variable vis has been given a value indi-cating the presence of the keyword public, private or protected in the line. Thedefault visibility is public.

41

4 Implementation

Listing 4.2: Extract from ScalaModellerboolean hasScope= f a l s e ;

/ / f i n d t r a i t d e f i n i t i o n sind = l i n e . indexOf ( " t r a i t " ) ;i f ( ind !=−1) {

spc = l i n e . indexOf ( " ; " , ind + 6 ) ;i f ( spc == −1) {

spc = l i n e . indexOf ( ’ { ’ , ind + 6 ) ;hasScope= t rue ;

}S t r i n g template = l i n e . subs t r ing ( ind +6 , spc ) ;Sca laTree c = new ScalaTree (

count , Sca laTree . TRAIT ,vis , template , lastComment

) ;root . addChild ( c ) ;nameCommentMap . put (name( template ) , lastComment ) ;i f ( hasScope ) {/ / i f t r a i t has own scope , add d e f s t o t h i s

parent=c ;}count += l ineLength +1;/ / don ’ t s e a r c h f o r o t h e r t h i n g s on same l i n econtinue ;

}

This extract is the code designed to parse trait definitions. If it finds the key-word “trait” on the line then it tries to find the character after the trait’s identifierand stores this location in spc. If a trait is declared with no definition, then theline will end with a semicolon e.g.

t r a i t example ;

Otherwise the trait will also have a definition of its own and a new scope willbe opened. Thus if a semicolon is not found, the method looks for an openingbrace “{”. If the trait does have its own scope then the method definitions on thefollowing lines will belong to this trait so the flag hasScope is set.

template is the substring between the end of the trait keyword and the termi-nating character. count is an integer storing the total length of lines seen so farand is used to provide the offset. name(String s) is a private method in ScalaMod-eller to trim the template and return the pure identifier (e.g. “example”). lastCom-ment stores the preceding line to the current one if it was a comment (see section4.8). These pieces of information are used to create a new model element.

The new model is added to its parent. Since a trait cannot belong to a method,

42

4.7 Launching and Debugging

only an object or a class, it is added to the root element. If the trait opened a newscope, the pointer to parent is updated. parent is used as the parent element forall method definitions. Updating the pointer like this allows the methods to beadded to the correct element. However, since the parser relies on assumptionsabout the code it can make mistakes as exemplified below:

object one { / / p a r e n t i s updated , r o o t i s upda t eddef methodOne = { } / / added t o p a r e n t =one

c l a s s two = { / / added t o r o o t =one , p a r e n t i s upda t eddef methodTwo = { } / / added t o p a r e n t =two

}

def methodThree = { } / / i n c o r r e c t l y added t o p a r e n t =two}

nameCommentMap is the trie for quick access to the model’s comment using itsidentifier (see section 4.8). count is updated with the new line’s length and therest of the loop is skipped so as not to waste time trying to find other elementson the same line. (Well set-out code would never do that anyway and it wouldreally confuse a line-based parser like this one.)

4.6.2 Appearance

To maintain homogeneity between tools and reduce any learning curve associ-ated with my new plug-in, the outline view as described matches almost exactlywith the style presented by the JDT’s outline view. The ScalaLabelProvider alsoreturns the same icons used in the JDT wherever similar structures exist in Java.The general colour codes for visibility (green = public, yellow = protected, red =private) are also maintained, providing a consistent user experience.

4.7 Launching and Debugging

In order to be able to run programs that a Scala developer has written fromwithin Eclipse, it is necessary to implement Eclipse’s launching framework[Szursewski, 2003]. This adds the necessary UI components to the Run and/orDebug menus and explains how to launch a Scala application. Since Scala com-piles to standard Java byte code, I had hoped to be able to use much of the JDT’sexisting code to run and debug Scala. Unfortunately, this is extremely compli-cated, dealing with all the possibilities and options concerned with differentJava Virtual Machines (JVMs). Furthermore, merely using the JVM is insuffi-cient. Although Scala code is compiled to Java byte code, it is still necessary torun the Scala executable to correctly set-up the JVM to deal with Scala’s extras. Atrivial solution would be to create a toolbar button that used the Process.exec()

43

4 Implementation

method to call the Scala VM on the selected file. However, this would not beproperly integrated into Eclipse and does not solve the issue of debugging.

The launching framework is split into two sections, UI and non-UI. The non-UI section must provide a LaunchConfigurationType (henceforth, config types)which can create instances of LaunchConfigurations. The config type defines thevariables and options that are appropriate to launching something of this type.This is also includes whether it can be run, debugged or both. The configura-tions are created by the user for each program of the correct type. In this project,the config type will be a Scala Application and the configurations it creates willbe for each Scala class with a main method.

The UI section must provide an icon for the configuration type and the neces-sary tab groups and dialogue boxes for a user to configure a launch. The screen-shot in figure 4.3 shows the list of available config types on the left. Scaliptor’spartially implemented contribution can be seen at the end of this list. An exam-ple debug configuration has been made for a Java application. This can be seenunder the Java Application config type in the tree. The options for configuringthis instance are seen in the tab groups on the right. There are very many op-tions provided by the JDT all of which must be supported in both the UI and thenon-UI plug-ins. To integrate with the JDT’s debugger, I would have to supplyinformation about the VM. This involves creating a VMRunner, VMInstall, gettingthe arguments for them and initialising things like the classpath.

4.8 Text-Hovers

In the JDT, when the mouse cursor is hovered over an identifier for a shortwhile, the JavaDoc documentation for that identifier is shown in a tooltip. Thisis known as a text-hover or an “infopop”. Even using the simple line parser,adding this functionality is possible.

If a line begins with the ScalaDoc1 comment symbol (“/∗∗”) then it can bepreserved. The following lines starting with (“∗”) are appended to the first com-ment line until a close comment symbol (“∗/”) is found. This entire commentcan then be associated with the following model element.

All that remains to be done is to add the hooks into the Eclipse API to providethe service with the correct information.

4.8.1 ITextHover

This interface defines the way a text hover must be implemented in order toparticipate in Eclipse’s framework. Firstly, in the SourceViewerConfiguration (seesection 3.1.2) a new method must be overridden, getTextHover. This should re-turn an implementation of ITextHover, in this case, a ScalaTextHover.

1JavaDoc in Scala code

44

4.8 Text-Hovers

Figure 4.3: Screenshot of the Eclipse Debug Dialogues

A text hover is supplied with an offset through the document where the mousecursor is and is required to find a suitable Region to provide hover info for. Todo this, I use the implementation of ScalaWordDetector from section 3.1.2 to de-termine the bounds of the surrounding word i.e. look backward and forwardfrom the offset until a space, ’.’ or other character that cannot legally be used ina Scala identifier, is found.

The hard part now, is searching through the model tree to find an element witha matching name. In order to optimise performance, I use a trie[Wikipedia.org,2005] containing all the model elements using their names as a key.

Tries

A trie is beautiful solution to the problem of searching through a lot of strings.The word “trie” is derived from retrieval but is often pronounced “try” to distin-guish it from a normal tree. Basically, it is a tree where each node represents acharacter and has children representing each of the characters which appear di-rectly after it in the entered strings. At the end of the string is a leaf node storingthe relevant data. See figure 4.4 for an example.

45

4 Implementation

Figure 4.4: An example trie for keys ’to’, ’tea’, ’ten’, ’inn’. Wikipedia.org [2005]

4.9 Content-Assistance

Using the model of the Scala source generated for the outline view, it becomespossible to suggest completions and alternatives when writing new lines of code.For example, each object/class knows about its own methods and member vari-ables. Thus, given a few letters at the start of the identifier, it could fill in therest, assuming you want to use a local member. It would be desirable to extendthe modelling code to allow suggestions from all visible alternatives, narrowingthe scope as each segment2 of the line is completed like the JDT does so well forJava code. The ScalaDoc documentation stored with each model element couldalso be provided to allow the user to make an informed decision as the JDT doeswith JavaDoc.

The model should already be mostly sufficient for the task, as it containsall the data for everything from a package to an individual private member.Adding a project model element to coalesce packages and external jars or otherthings that may need to be in the classpath is fairly trivial.

Storing the model in a trie as described in the previous section is also idealfor content-assistance as the search should be narrowed upon each successivecharacter entered. This is exactly how a trie works and avoids having to searchthe whole model tree again every time.

Unfortunately, at time of writing there was insufficient time to complete thecontent-assistant, however its design is shown in figure 4.5.

2I define segment here as being a section between ’.’s

46

4.9 Content-Assistance

Figure 4.5: Class diagram for TextHovers and Content-Assistance

47

4 Implementation

48

5 Evaluation and Testing

Firstly, I evaluate each aspect of project’s context with respect to how difficultit made my work. Then I shall go on to evaluate the project itself, and howsuccessfully it has met the requirements.

5.1 Eclipse development

During the course of the project, I have learnt a lot about the Eclipse API withrespect to creating source-editing plug-ins. There exists a framework to do al-most anything that you could want to do, however its use is mostly shroudedin mystery. All documentation on the subject (including books) is very basic, ex-plaining the obvious elements and completely neglecting the more complicatedelements. These have to be gleaned from XML specifications and the Eclipsesource code itself. The biggest improvement I feel that could be made to assistin the creation of Eclipse plug-ins therefore is better and more detailed documen-tation covering all the features that the JDT provides and how a new plug-in canhook in to provide similar features.

Secondly, integrating with the launching framework (see section 4.7) seemsoverly complicated. Although there are a lot of possibilities and options that youmight feasibly want to change, the vast majority of times, a user will just want torun the program on the default VM with the minimum classpath. Arguments tothe program will be the only thing likely to be changed often and this is buriedwithin the menus, making it tedious to change. A more streamlined launchinginterface is called for. There should be a quick way to change the argumentsfor a user, perhaps a pop-up dialogue box when the application is run. For thedeveloper, a new Java Launch class should be made available to extend fromthat provides all the usual defaults.

Furthermore, the Eclipse API tries very hard to make no assumptions and beas generic possible. Unfortunately, this makes it particularly cryptic and moredifficult to use. For example, for any source-editing plug-in, it is necessary tosupply a white-space detector. For all but a tiny minority of cases, white-spacewill be the same. The benefits of modules, allowing re-use and abstraction meanthat Eclipse can afford to create sub-classes to cover as much common groundas possible. This way plug-ins can just add the extra functionality they need. IfEclipse provides too much, then a developer is always free to use a class higherin the hierarchy. Thus, a better approach may have been to assume more de-faults and allow customisation if necessary as proposed in the following section.

49

5 Evaluation and Testing

5.1.1 Improving Eclipse

I suggest the creation of a new layer of classes which can handle the usual caseto shield a beginner from a lot of the API. When a developer feels they needto customise their plug-in more than the beginner set allows, they can changethe inheritance to the standard SourceViewerConfiguration and TextEditor. This ap-proach is adopted by Eclipse’s Graphical Editing Framework (GEF) [http://www.eclipse.org/gef][Hudson, 2003] which allows a developer to create a graphical ed-itor plug-in (e.g. UML diagram editor). Normal development should extendfrom Eclipse’s EditorPart class whilst beginners can extend from GraphicalEditor.

To this end, I have created a small package submitted for inclusion into themain Eclipse project which facilitates source editing plug-in development. Itassumes that a compiler exists that emits error messages containing the name ofthe file and a line number to create appropriate error markers. It automaticallyhighlights keywords most commonly used in languages such as “if”, “else” withthe option of adding both usual OO words, e.g. “class”, “extends”, and customkeyword lists. This reduces the work that has to be done for a basic plug-in toextending my SimpleSourceEditor and supplying a small list of extra keywords.

5.2 Scala

Scala is a very flexible, very powerful language that can express complex rela-tions quite concisely. Unfortunately, this seems to lead to a complicated syntax.Over the several months I spent with the language, I never learnt to read orwrite anything but the most basic patterns. It’s complexity is demonstrated bythe fact that it lies outside the class of LR(1) languages. This makes it very diffi-cult to write tools for, as most of the standard parser creators are not powerfulenough. This is exasperated since Scala source can contain XML so a parserwithin a parser is needed. ANTLR may be able to do it, given enough time togo through the extensive Scala syntax, removing left-recursion (see section 4.4).The creators of Scala [http://scala.epfl.ch] are aware of these issues and potentialsmall changes to the syntax are a frequent topic of conversation on the Scalamailing list.

However, it should have been easy to use the parser contained in Scala’s owncompiler. Unfortunately, due to its immaturity, it is not well separated and relieson many external packages and a special Java compiler to deal with algebraictypes (PiCo). When it is better implemented, in its own language, perhaps itwill be better suited for this kind of role.

5.3 Testing

As I made each significant change to the source code of the plug-ins that makeup Scaliptor, I opened a runtime version of Eclipse with the plug-ins activated

50

5.4 Comparing Scaliptor to other language plug-ins

and went through the process a user would do to check for correct operation.When a significant feature was mature enough, it was released for beta testingto the Scala community.

As an open source project, releases were regularly made public as can be seenin the table in section 3.3. The Scala community was informed via the Scalamailing list and there were over 300 downloads during the course of the project.These people helped to find errors in the program and reported them in the bugdatabase supplied by SourceForge.net. Then I could classify and prioritise themfor fixing. The community also provided welcome support and encouragementand supplied suggestions or more formally, Requests For Enhancement (RFEs).

5.4 Comparing Scaliptor to other languageplug-ins

5.4.1 Eclipse FP: Haskell 0.6

At first glance, this plug-in appears very professional. There are beautiful iconsfor everything and high-resolution icons where they are shown larger. How-ever, many of these icons have been obtained from HUGS [http://cvs.haskell.org/Hugs/index.html], the Haskell interpreter without proper credit. Its professionalappearance continues when a wizard is used to create a Haskell project. Thiscreates separate folders for source and binary output automatically and appliesextra icons over the folder icons to distinguish them as the JDT does. Unfortu-nately, there appears to be some bug in the new Haskell module wizard whichprevents the creation of a module. Manually importing a Haskell source filedemonstrates similar syntax highlighting capabilities as Scaliptor. There are notext-hovers or Content Assistants.

The Haskell plug-in requires the Glasgow Haskell Compiler (GHC) to com-pile/run source code, optionally HUGS to run it and Haddock for exportingdocumentation. This is a little more complicated than Scaliptor’s requirementsbut does add slightly more functionality. Furthermore, a friendly wizard is pro-vided to gather the necessary information about where each of these programsare located in the file system and what options the user would like to activate onthem. This is probably easier than going through the usual preferences windowsand hides many of the advanced options that are available there.

An incremental builder operates on source code when changes are saved inthe same way that Scaliptor’s builder operates. The Haskell plug-in providesa Module Browser which displays only compilation units from the navigator,similar to Scaliptor’s/JDT’s Package Explorer.

Although, everything works as one would expect from an Eclipse plug-in,anyone who feels they require extra help will find it. Eclipse FP integrates intoEclipse’s Help Contents and provides extensive information in a User Guide.

51

5 Evaluation and Testing

This details many of the features and requirements.Some features which I did not quite have time to complete are present: actions

in the editor to (un)comment a line. However, the uncomment line keyboardshortcut assumes use of a German keyboard, as the command is [Ctrl-ß]. Also,Eclipse FP includes a working launch configuration type for Haskell modules.

A big disadvantage compared to Scaliptor is the lack of an Outline view forquick code navigation. Overall though, it looks slicker and provides a few morenice touches that I could have easily implemented given a little bit more time.

5.4.2 Eiffel for Eclipse (EfE) 1.0

Installing EfE was painless but could have been easier. Most plug-ins, includ-ing Eclipse FP and Scaliptor provide an update site so that Eclipse can install itautomatically. Efe does not, so a zip must be extracted into Eclipse’s plugins di-rectory. Again, basic syntax highlighting only is available, no content assistanceor “Text-Hovers” are available. The wizards are more functional and are madeavailable on an extra toolbar and menu in the main Eclipse workbench. The neweiffel file wizard for instance includes the option to create a “Hello World” file.

Just like EclipseFP and Scaliptor, compilation and running depends on an ex-ternal compiler — SmartEiffel (the GNU Eiffel Compiler) [http://smarteiffel.loria.fr/] in this case. There is no debug support. Compiling is done manually from atoolbar button, not automatically via Eclipse builders. The output from the com-piler is displayed in the console, there is no automatic error marking. Strangely,in the first versions of Scaliptor, the compiler was called manually from a buttonin the same way, but I found it too difficult to route the output to the consoleand easier to turn it into markers which is far more useful and more integratedinto Eclipse.

There is no extra browser/explorer equivalent, it relies purely on the file sys-tem navigator to explore the project, however an outline view is provided.

Help files are also supplied that integrate seamlessly into the standard Eclipsedialogues. Unfortunately, while they are in English, they are imperfect transla-tions from the original French. However, currently Scaliptor makes no effort atinternationalisation (i18n1) or help files so it’s still an advantage.

Overall, it looks a lot less professional as most of the features are accessedthrough toolbar buttons and not the usual Eclipse methods. Apart from helpfiles there are no extra features compared to Scaliptor. It was created by a pair ofpeople from the Université de Tours and Scaliptor was just me, thus I feel thatScaliptor can be favourably compared in this case.

1’i’ followed by 18 letters, followed by ’n’ — Java’s standard abbreviation for internationalisa-tion

52

5.5 Evaluating against the requirements

5.5 Evaluating against the requirements

The requirements from section 2.3 are repeated here with annotations describ-ing an objective evaluation of how successfully they have been implemented.Extra requirements gathered from the community are also highlighted at theend of this section. Bugs are documented with their number as generated bySourceForge — more information can be found at the project homepage (http://www.scaliptor.org).

Syntax Highlighting — Keyword and literal Highlighting Fully complete andoperational. See section 3.1.2. There is a small bug when editing a multi-line comment, as the comment’s colour is not correctly repaired. Docu-mented bug number 972334.— Advanced, context sensitive syntax highlighting Not attempted dueto time constraints and limited parser. However, Marc Moser at the EPFLhas completed a plug-in to provide this. He had to work around Eclipse’sframework rather than with it, to get it to work. Eclipse only provides,and indeed assumes, that you will be using simple rule-based systems fordetecting the syntax. For context sensitive behaviour, this is not sufficient.Perhaps, since the JDT only recently (since version 3.0) provided this ca-pability, the framework is still immature. The Eclipse framework requiresimprovement to make it more flexible. A good way of doing this would beto provide an alternative class to inherit from similar to the methods dis-cussed in section 5.1.1. This would supply extra power without makingthe existing basic system any more complicated to implement.

Use of JDT Package Explorer to explore Scala packages Automatic, Packageexplorer integrated into Scala perspective.

Scala Perspective Includes wizards, editor, package explorer, outline view andproblem view. This is similar to the standard Java perspective providinga homogeneous development environment. All the functionality of Scalip-tor is made available for quick and easy access whilst features for other lan-guages are hidden to reduce confusion. This enhances usability for Scaladevelopment.

Compiling and error-marking Scala source — Adding a button to call the com-piler manually Simple batch call, compiled currently edited file. Since ver-sion 0.2.— Automatically building on detection of change Implemented in ver-sion 0.3. Just uses included compiler, ScalaC. Output from the compiler iscaptured and parsed to generate Eclipse problem markers. These highlighterrors both in the editor and in a summary table of the workspace. When-ever a file is changed, a build is triggered. In version 0.3, all files in the

53

5 Evaluation and Testing

project were recompiled. Since version 0.5, this has been optimised to com-pile only the necessary files. Greater integration is desirable for efficiency,preferably a parser which could supply errors directly. Requires changesto ScalaC or creation of new compiler/parser. Documented bug 1124155:intermittent error where build gets stuck, requires manually killing thecompiler process. This is an issue with the way ScalaC is called and wouldbe avoided with an alternative approach as discussed above. See section4.5.

Generate an Abstract Syntax Tree version 0.5. A model if the code is gener-ated. Assumes the “usual case” and thus works well the vast majority ofthe time. However it can be inaccurate due to line-based nature of theparser. See section 4.6.

Scala Launcher and Debugger UI components activated. Calling the Scala VMfrom Eclipse’s Launch framework is exceptionally complicated at first. Morework needed. See section 4.7

Wizards to assist in generation of new Scala elements — New Project Avail-able since version 0.2. Creates a project of desired name and assigns ScalaNature to it. A new icon differentiates a Scala project from a Java/otherproject.— New Class Available since version 0.2. Adds a scala file of desired nameto selected package. Instantiates contents of the file with the class headerincluding package and class declarations. Not as powerful as JDT’s NewJava Class wizard as it does not allow specification of super classes andthen provide skeletons for abstract methods.— New Object Not implemented due to time constraints. Should be verysimple to add based on source for the class wizard.— New Trait Similarly as above.

Code Assistance and auto-completion of Scala source Not implemented dueto time constraints and difficulty of parsing Scala. However a design wascreated in section 4.9.

Integrate with Eclipse’s CVS and Team extensions .scala extension registeredas CVS ASCII compatible in plug-in Manifest. This is sufficient to allow theexisting CVS plug-in to manage Scala source files.

Preferences as necessary Preferences are active for Scala install directory, out-put directory for compiled resources and whether to generate debug info.They are all available from the standard Eclipse preference pages.

Integrate into the Eclipse UI and follow Eclipse best-practices As mentionedabove, all preferences are accessed from the main, global pages. Some of

54

5.6 Usability

these options should be project specific and thus be in a project’s prefer-ence page, not the global one. This may confuse users and should beamended as soon as possible. There does not appear to be much docu-mentation on implementing project specific preferences and this hinderedprogress considerably.

RFE 1123329: Ability to add external jars to the Scala build path — incom-plete due to time constraints.

5.6 Usability

As Scaliptor conforms to most of the Eclipse standards, it should be as easy touse as Eclipse and the JDT. However, there are some exceptions as mentionedabove. Preferences which should be project specific (runtime path, debug out-put) are not and thus may be not be obvious to find. However, the issue whichcaused the most support requests was the building and error marking feature.It requires the Scala compiler to properly installed and its location supplied. De-spite a detailed how-to for these procedures being supplied in the READMEsupplied with the zipped version of the distribution and on the FAQ on thehomepage, many people missed it. Some were inexplicably unable to fix it evenwith detailed instructions. Since I have reports of it working correctly on manyother people’s machines with similar configurations, I can only assume this isdown to user error. Therefore, some improvement to facilitate setting up thecompiler is called for.

The Eclipse FP project (see section 5.4.1) provides a wizard to gather neces-sary information about the location of Haskell compilers etc. This would besuitable. However, it still requires a little further work as the wizard is run bypressing a small and cryptic icon on the toolbar. Ideally, the wizard should runautomatically when the plug-in is first installed.

The performance of the code is very important in user interfaces. A sluggishUI is very irritating as interrupts the flow of the user’s thoughts and causes con-fusion. Thus, according the the Eclipse best practices, all long running processesshould run in the background with a progress bar. Scaliptor meets this specifica-tion as the only long running process is building which runs in the background.Double-clicking on the status bar creates a detailed progress bar. The parsingof code for text-hovers and the outline view (see section 4.4) is very quick, usu-ally taking less than 10ms. This was measured using Java’s currentTimeMillis()method at the beginning and end of the code. Unfortunately, the OS used (Win-dows XP Pro) only returns figures with a precision of 10ms.

55

5 Evaluation and Testing

56

6 Conclusions

Eclipse is very flexible and provides a lot of support to plug-in developers. How-ever, it can do more and my Simple classes (see section 5.1.1) help toward ab-stracting more of the common work away from the beginner.

Scala is a very powerful language but in covering so much ground, both OOand functional paradigms, it has come at the cost of readability and ease of pars-ing. It is simply very big and complicated. Supporting it fully would require afreely available parser or more time to implement one in ANTLR. Without this,a lot of the work presented here loses a lot of accuracy. At time of writing, theEPFL who originally created Scala are developing their own series of Eclipseplug-ins to be known as the Scala Development Tools. They already have ad-vanced syntax highlighting working but this is not yet available to the public.

Even with this parsing difficulty, Scaliptor compares well to plug-ins writtenfor other languages by teams on a similar scale to myself. Further work wouldconsist of:

• Improved parser to help with syntax highlighting, outline view, text-hoversand content assistance

• Launcher and debugger

• Help files

• Internationalisation

• Setup Wizard (see section 5.6)

I have analysed some of Eclipse’s competition with respect to supporting newlanguages and the benefits of OO compared to functional languages. An inter-esting extension would be to question how well a hybrid language like Scalacan support itself and other languages by re-writing this project in Scala. Thisshould be quite feasible as Scala source already compiles to Java byte-code andcan call Java methods. This would help to answer some of the points raised insection 1.2.4.

57

Bibliography

John Arthorne. Project natures and builders. Eclipse Corner, November 2004.URL http://www.eclipse.org/articles/Article-Builders/builders.html.

François Audineau and Mathieu Hélias. Développer un éditeur sousEclipse, 2004. URL http://pamplemouss2002.free.fr/eclipse/docs/linker.php3?file=TutorielDevelopperunEditeurEclipse. French.

Gilad Bracha and William Cook. Mixin-based inheritance. In Norman Mey-rowitz, editor, Proceedings of the Conference on Object-Oriented Programming:Systems, Languages, and Applications / Proceedings of the European Conferenceon Object-Oriented Programming, pages 303–311, Ottawa, Canada, 1990. ACMPress. URL http://citeseer.ist.psu.edu/bracha90mixinbased.html.

Robert Buffone. Divided loyalty, parts 1 & 2: Creating views and deployingplugins in eclipse and netbeans. DevX.com, September 2004. URL http://www.devx.com/opensource/Article/26612/.

Damien Challet and Yann Le Du. Microscopic model of software bug dynam-ics: Closed Source versus Open Source. International Journal of Reliability,Quality and Safety Engineering, October 2004. URL http://arxiv.org/PS_cache/cond-mat/pdf/0306/0306511.pdf.

Andrei Cioroianu. Java desktop development. onJava.com, February 2004. URLhttp://www.onjava.com/pub/a/onjava/2004/02/18/desktop.html.

Eric Clayberg and Dan Rubel. Eclipse: Building Commercial Quality Plug-ins.Eclipse. Addison Wesley, first edition, 2004. ISBN 0321228472.

Don Coleman, Joel Confino, Peter Koletzke, Brian McCallister, Tom Purcell,and John Shephard. Java IDE shootout. JavaOne 2004, Sun’s WorldwideDeveloper Conference, 2004. URL http://javaoneonline.mentorware.net/servlet/mware.servlets.StudentServlet?mt=1093594567372&mwaction=showDescr&class_id=27985&from=business&fromtopic=By%20Topic&subsysid=2000&topic=business&avail_frames=true. Free registration required.

Eclipse.org. Eclipse Help. Eclipse, 2004. URL http://dev.eclipse.org/help30/index.jsp.

Eclipse.org. Eclipse web site. Web, 2005. URL http://www.eclipse.org.

58

Bibliography

Marty Hall and Larry Brown. Core Web Programming. Java. Sun MicrosystemsPress/Prentice Hall PTR, second edition, 2001. ISBN 0130897930. URL http://www.corewebprogramming.com.

Elwin Ho. Creating a text-based editor for Eclipse. Hewlett Packard, June 2003. URLhttp://devresource.hp.com/drc/technical_white_papers/eclipeditor/index.jsp.

Randy Hudson. Create an Eclipse-based application using the Graphical EditingFramework. IBM, July 2003. URL http://www-106.ibm.com/developerworks/opensource/library/os-gef/.

Kim Johnson. A descriptive process model for open-source software develop-ment. Master’s thesis, University of Calgary, June 2001. URL http://sern.ucalgary.ca/students/theses/KimJohnson/toc.htm.

Prof. Forbes D. Lewis. Recursive descent parsing. URL http://cs.engr.uky.edu/~lewis/essays/compilers/rec-des.html. Date Consulted: 2nd February 2005.

Chris Lüer. Evaluating the Eclipse platform as a composition environment. Web,March 2003. URL http://citeseer.ist.psu.edu/571052.html.

Mauro Marinilli. Swing and SWT: A tale of two Java GUI libraries. developer.com,2003. URL http://www.developer.com/java/other/article.php/2179061.

James Martin. Rapid Application Development. Macmillan Publishing Co., Inc.,1991. ISBN 0-02-376775-8.

David McAmis. Totally RAD: we road test five IDEs. Builder AU, September2004. URL http://www.builderau.com.au/program/0,39024614,39131183,00.htm.

Adam Neat. Java jams: Five IDEs tested. Builder AU, January 2005. URL http://www.builderau.com.au/program/0,39024614,39174040,00.htm.

Martin Odersky et al. An overview of the Scala programming language.Web, École Polytechnique Fédérale de Lausanne, INR Ecublens, 1015 Lau-sanne, Switzerland, 2004a. URL http://scala.epfl.ch/docu/files/ScalaOverview.pdf. DRAFT.

Martin Odersky et al. The Scala Language Specification version 1.0. EPFL, ÉcolePolytechnique Fédérale de Lausanne, INR Ecublens, 1015 Lausanne, Switzer-land, 2004b. URL http://scala.epfl.ch/docu/files/ScalaReference.pdf. DRAFT.

OTI. Eclipse platform technical overview. Eclipse Corner, 2003. URL http://www.eclipse.org/whitepapers/eclipse-overview.pdf. Object Technology Interna-tional inc.

Eric Steven Raymond. The Cathedral and the Bazaar. 2000. URL http://www.catb.org/~esr/writings/cathedral-bazaar. version 3.0.

59

Bibliography

Nathanael Schärli, Oscar Nierstrasz, Stéphane Ducasse, and Andrew Black.Traits: Composable Units of Behavior, November 2002a. URL http://www.iam.unibe.ch/~scg/Archive/Papers/Scha02bTraits.pdf.

Nathanael Schärli, Oscar Nierstrasz, Stéphane Ducasse, Roel Wuyts, and An-drew Black. Traits: The formal model, 2002b. URL http://citeseer.ist.psu.edu/574534.html.

Michael Sellers. Designing for demanding users. interactions, 1(3):54–64, 1994.ISSN 1072-5520. URL http://doi.acm.org/10.1145/182966.182972.

Brock Shaw. Agile evolution. BCS Computer Bulletin, November 2004.

Richard Stallman. EMACS: The extensible, customizable display editor. 1980.URL http://www.gnu.org/software/emacs/emacs-paper.html.

Sun Microsystems Inc. Model-View-Controller. Java BluePrints, 2002. URL http://java.sun.com/blueprints/patterns/MVC-detailed.html.

Joe Szursewski. We have lift-off: The launching framework in Eclipse.Eclipse Corner, January 2003. URL http://www.eclipse.org/articles/Article-Launch-Framework/launch.html. IBM OTI Labs.

Wikipedia.org. Wikipedia. Web, 2005. URL http://en.wikipedia.org.

60

A ScalaModeller.java

/∗∗ C o p y r i g h t C h r i s Heald , U n i v e r s i t y o f York UK, 19−Jan −2005∗ Thi s program i s f r e e s o f t w a r e ;∗ you can r e d i s t r i b u t e i t and / o r modi fy i t under t h e t e rms o f t h e∗ GNU G e n e r a l P u b l i c L i c e n s e as p u b l i s h e d by t h e F r e e S o f t w a r e Founda t i on ;∗ e i t h e r v e r s i o n 2 o f t h e L i c e n s e , o r ( a t your o p t i o n ) any l a t e r v e r s i o n .∗∗ Thi s program i s d i s t r i b u t e d in t h e hope t h a t i t w i l l be u s e f u l ,∗ but WITHOUT ANY WARRANTY; w i t h o u t even t h e i m p l i e d warranty∗ o f MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.∗ See t h e GNU G e n e r a l P u b l i c L i c e n s e f o r more d e t a i l s .∗∗ You s h o u l d have r e c e i v e d a copy o f t h e∗ GNU G e n e r a l P u b l i c L i c e n s e a l o n g with t h i s program ;∗ i f not , w r i t e t o t h e F r e e S o f t w a r e Foundat ion , I n c . ,∗ 59 Temple P la c e , S u i t e 330 , Boston , MA 02111−1307 USA∗/

package uk . ac . york . cs . S c a l i p t o r . s c a l a ;

import j ava . io . IOException ;import j ava . io . InputStream ;import j ava . io . InputStreamReader ;

import org . e c l i p s e . core . runtime . CoreException ;import org . e c l i p s e . ui . I F i l e E d i t o r I n p u t ;

import org . s c a l i p t o r . u t i l . Tr ie ;

/∗∗∗ A c l a s s t o make a t r e e model o f a s c a l a f i l e .∗∗ @author C h r i s Heald∗ @since 0 . 5∗/

public c l a s s ScalaModel ler {

public s t a t i c Tr ie nameCommentMap ;

/∗∗∗ P a r s e s S c a l a s o u r c e t o r e t u r n a t r e e model o f t h e c o d e .∗ @param s c a l a S e g m e n t t h e s o u r c e c o d e∗ @return r o o t node o f t r e e model∗/

public s t a t i c ScalaTree model ( S t r i n g scalaSegment ) {/ / l ong s t a r t =System . c u r r e n t T i m e M i l l i s ( ) ;

nameCommentMap=new Str ingToStr ingTable ( ) ;Sca laTree root2 = new ScalaTree (−1 , −1, −1, " root " , " " ) ; / / t o p o f t r e eScalaTree imports = null ; / / s u b t r e e f o r i m p o r t s so t h e y a r e f o l d e d awayScalaTree parent = root2 ; / / p a r e n t f o r d e f sScalaTree root = root2 ; / / o u t e r c l a s s / o b j e c tScalaTree las tFunc = parent ;S t r i n g [ ] l i n e s = scalaSegment . s p l i t ( "\n" ) ;S t r i n g lastComment=" " ;i n t lastCommentLine=−1;i n t count = 0 ; / / number o f c h a r a c t e r s r e a d/ / f o r ( S t r i n g l i n e : l i n e s ) { / / j 2 s e 5 . 0for ( i n t i = 0 ; i < l i n e s . length ; i ++) { / / go through e a c h l i n e

i n t l ineLength = l i n e s [ i ] . length ( ) ;S t r i n g l i n e = l i n e s [ i ] . tr im ( ) ;i f ( ( l i n e . s t a r t s W i t h ( "∗" ) && ! l i n e . s t a r t s W i t h ( "∗/" ) ) / / i s i n s i d e a comment , not end o f comment

|| l i n e . s t a r t s W i t h ( "//" ) || l i n e . s t a r t s W i t h ( "/∗" ) ) { / / o r s t a r t s a commenti f ( lastCommentLine==i −1) { / / i f l a s t l i n e was a l s o a comment , append

lastComment+= l i n e . subs t r ing ( 2 ) ;} e lse lastComment= l i n e . subs t r ing ( 2 ) ;lastCommentLine= i ;count += l ineLength +1;continue ; / / s a v e comments t o add t o a node l a t e r

}

i n t ind , spc = −1;i n t v i s = ScalaTree . PUBLIC ; / / f i n d v i s i b i l i t y on l i n ei f ( l i n e . conta ins ( " p r i v a t e " ) ) {

v i s = ScalaTree . PRIVATE ;} e lse i f ( l i n e . conta ins ( " protec ted " ) ) {

61

A ScalaModeller.java

v i s = ScalaTree .PROTECTED;}

/ / f i n d p a c k a g e d e c l a r a t i o nind = l i n e . indexOf ( " package " ) ;i f ( ind != −1) {

spc = l i n e . indexOf ( " ; " ) ;Sca laTree c = new ScalaTree ( count , Sca laTree .PACKAGE_DECL, −1,

l i n e . subs t r ing ( ind + 7 , spc ) , " " ) ;root2 . addChild ( c ) ; / / a lways add t o p r o p e r r o o tcount += l ineLength + 1 ;continue ; / / don ’ t s e a r c h f o r o t h e r t h i n g s on same l i n e

}

/ / f i n d imp or t d e c l a r a t i o n sind = l i n e . indexOf ( " import " ) ;i f ( ind !=−1) {

spc = l i n e . indexOf ( " ; " ) ;i f ( imports==null ) { / / i f f i r s t import , c r e a t e s u b t r e e

imports = new ScalaTree ( count , Sca laTree . IMPORTS,−1 , " import d e c l a r a t i o n s " , " " ) ;root . addChild ( imports ) ; / / add t o h i g h e s t l e v e l e l e m e n t

}Sca laTree c = new ScalaTree ( count , Sca laTree . IMPORT, −1,

l i n e . subs t r ing ( ind +6 , spc ) , " " ) ;imports . addChild ( c ) ;count += l ineLength +1;continue ; / / don ’ t s e a r c h f o r o t h e r t h i n g s on same l i n e

}boolean hasScope= f a l s e ;

/ / f i n d t r a i t d e f i n i t i o n sind = l i n e . indexOf ( " t r a i t " ) ;i f ( ind !=−1) {

spc = l i n e . indexOf ( " ; " , ind + 6 ) ;i f ( spc == −1) {

spc = l i n e . indexOf ( ’ { ’ , ind + 6 ) ;hasScope= t rue ;

}S t r i n g template = l i n e . subs t r ing ( ind +6 , spc ) ;Sca laTree c = new ScalaTree ( count , Sca laTree . TRAIT , vis ,

template , lastComment ) ;root . addChild ( c ) ;nameCommentMap . put (name( template ) , lastComment ) ;i f ( hasScope ) { / / i f t r a i t has own scope , add d e f s t o t h i s

parent=c ;}count += l ineLength +1;continue ; / / don ’ t s e a r c h f o r o t h e r t h i n g s on same l i n e

}

ind = l i n e . indexOf ( " c l a s s " ) ; / / f i n d c l a s s d e f i n i t i o n si f ( ind != −1 && ! l i n e . conta ins ( " case " ) ) { / / i f t h e r e i s a c l a s s d e f t h a t i s n ’ t a c a s e c l a s s

i f ( l i n e . conta ins ( " extends " ) ) {spc = l i n e . indexOf ( ’ ’ , ind + 7 ) ;

} e lse spc = l i n e . indexOf ( ’ ) ’ , ind + 6 ) + 1 ;i f ( spc == 0) { / /−1+1

spc = l i n e . indexOf ( ’ { ’ , ind + 6 ) ;hasScope = t rue ;

}i f ( spc==−1)

spc= l i n e . length () −1;t r y {

S t r i n g template = l i n e . subs t r ing ( ind + 6 , spc ) ;Sca laTree c = new ScalaTree ( count , Sca laTree . CLASS , vis ,

template , lastComment ) ;nameCommentMap . put (name( template ) , lastComment ) ;lastComment=" " ; / / r e s e t commenti f ( ! hasScope ) { / / i f c l a s s doesn ’ t have own

/ / s cope , add t o p a r e n tparent . addChild ( c ) ;

} e lse { / / o t h e r w i s e add t o r o o t and make f o l l o w i n g d e f s/ / g e t added t o t h i s one

root . addChild ( c ) ;parent = c ; / / change p a r e n t s f o r d e f s and v a l sl as tFunc=c ;

}} catch ( StringIndexOutOfBoundsException e ) {

System . e r r . p r i n t l n ( " Error a t l i n e " + i ++) ;}count += l ineLength +1;continue ; / / don ’ t s e a r c h f o r o t h e r t h i n g s on same l i n e

}

/ / f i n d o b j e c t d e f i n i t i o n sind = l i n e . indexOf ( " o b j e c t " ) ;i f ( ind != −1) {

spc = l i n e . indexOf ( ’ { ’ , ind + 6 ) ;i f ( spc==−1)

spc= l i n e . length () −1;t r y {

62

S t r i n g template = l i n e . subs t r ing ( ind , spc ) ;Sca laTree c = new ScalaTree ( count , Sca laTree . OBJECT , vis ,

template , lastComment ) ;nameCommentMap . put (name( template ) , lastComment ) ;lastComment=" " ; / / r e s e t commentroot2 . addChild ( c ) ;parent = c ;root = c ; / / o b j e c t i s a lways o u t s i d e c l a s s e s − make i t

/ / new r o o tl as tFunc=c ; / / change p a r e n t f o r v a l s

} catch ( StringIndexOutOfBoundsException e ) {System . e r r . p r i n t l n ( " Error a t l i n e " + i ) ;

}count += l ineLength +1;continue ;

}

/ / f i n d f u n c t i o n d e f i n i t i o n sind = l i n e . indexOf ( " def " ) ;i f ( ind != −1) {

spc = l i n e . indexOf ( ’= ’ , ind + 4 ) ;i f ( spc == −1)

spc = l i n e . indexOf ( ’ ; ’ , ind + 4 ) ;i f ( spc == −1)

spc = l i n e . length ( ) −1;S t r i n g template = l i n e . subs t r ing ( ind +4 , spc ) ;Sca laTree c = new ScalaTree ( count , Sca laTree .FUNCTION, vis ,

template , lastComment ) ;nameCommentMap . put (name( template ) , lastComment ) ;lastComment=" " ; / / r e s e t commentparent . addChild ( c ) ;las tFunc = c ; / / change p a r e n t f o r e n c l o s e d v a r i a b l e scount += l ineLength +1;continue ;

}

/ / f i n d v a r i a b l e s and c o n s t a n t sind = l i n e . indexOf ( " var " ) ;i f ( ind==−1) ind = l i n e . indexOf ( " val " ) ;i f ( ind != −1) {

spc = l i n e . indexOf ( ’ ’ , ind + 4 ) ;i f ( spc==−1) spc = l i n e . indexOf ( ’ ; ’ , ind + 4 ) ;S t r i n g template = l i n e . subs t r ing ( ind , spc ) ;Sca laTree c = new ScalaTree ( count , Sca laTree . VARIABLE, vis ,

template , lastComment ) ;nameCommentMap . put (name( template ) , lastComment ) ;lastComment=" " ; / / r e s e t commentl as tFunc . addChild ( c ) ;count += l ineLength +1;continue ;

}/ / i f n o t h i n g found , j u s t i n c r e a s e o f f s e tcount += l ineLength +1;

}/ / System . out . p r i n t l n (" p a r s e t o o k "+( i n t ) ( System . c u r r e n t T i m e M i l l i s ()− s t a r t )+"ms " ) ;return root2 ;

}

/∗∗∗ Given a t e m p l a t e f o r an e l e m e n t e . g . a method s i g n a t u r e ( name and i t s p a r a m e t e r s ) ,∗ r e t u r n s j u s t t h e name .∗ @param t e m p l a t e∗ @return name∗/

private s t a t i c S t r i n g name( S t r i n g template ) {/ / remove f i r s t word i f more than one as in " o b j e c t p a r s e r "i n t index = template . indexOf ( ’ ’ ) ;i f ( index != −1)

template=template . subs t r ing ( index ) . tr im ( ) ;/ / assume s t a r t o f t e m p l a t e i s ok , j u s t need t o remove e x t r a s t u f f a t endScalaWordDetector wd = new ScalaWordDetector ( ) ;for ( i n t i =0 ; i <template . length ( ) ; i ++) {

char c = template . charAt ( i ) ;i f ( !wd. isWordPart ( c ) )

return template . subs t r ing ( 0 , i ) ;}return template ; / / i f can ’ t f i n d any e x t r a j u s t r e t u r n t h e whole t h i n g

}

/∗∗∗ E x p e r i m e n t a l a l t e r n a t i v e t o model ( S t r i n g s ) .∗ T r i e s t o p a r s e more a c c u r a t e l y , by d e t e c t i n g c h a n g e s in s c o p e .∗ @param s t h e S c a l a s o u r c e∗ @return r o o t node o f t r e e model∗ @see # model ( S t r i n g s )∗/

public s t a t i c ScalaTree modelByScope ( S t r i n g s ) {S t r i n g [ ] scopes = s . s p l i t ( "\\x7B .\\x7D" ) ;return new ScalaTree ( ) ;

}

63

A ScalaModeller.java

/∗∗∗ P a r s e s an e d i t o r ’ s i n p u t assuming i t ’ s S c a l a s o u r c e .∗ Returns a t r e e model o f t h e c o d e s u i t a b l e f o r use with a T r e e C o n t e n t P r o v i d e r∗ @param i n p u t S c a l a s o u r c e∗ @return r o o t node o f model t r e e∗ @see S c a l a T r e e∗ @see S c a l a T r e e C o n t e n t P r o v i d e r∗/

public s t a t i c ScalaTree model ( I F i l e E d i t o r I n p u t input ) {t r y {

InputStream stream = input . g e t F i l e ( ) . getContents ( ) ;InputStreamReader reader = new InputStreamReader ( stream ) ;char [ ] contents = new char [ 1 0 2 4 0 ] ; / /TODO s o l v e 10K l i m i treader . read ( contents ) ;return model ( S t r i n g . copyValueOf ( contents ) ) ;

/ / r e t u r n modelByScope ( S t r i n g . copyValueOf ( c o n t e n t s ) ) ;

} catch ( CoreException e ) {/ / TODO Auto−g e n e r a t e d c a t c h b l o c ke . p r i n t S t a c k T r a c e ( ) ;return new ScalaTree ( ) ;

} catch ( IOException e ) {/ / TODO Auto−g e n e r a t e d c a t c h b l o c ke . p r i n t S t a c k T r a c e ( ) ;return new ScalaTree ( ) ;

}}

}

64