MASARYK UNIVERSITY FACULTY OF INFORMATICS
Scripting for the Java Platform (JSR-223)
Bachelor's Thesis
Student: Matej Sabo Studies: Applied Informatics Student ID: 325124 E-Mail: [email protected]
Brno 2011 Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elabor- ation of this work are properly cited and listed in complete reference to the due source.
i Abstract The aim of this work is to evaluate the potential of scripting languages on the Java Platform. The work includes a summary of strengths and weaknesses of Java and scripting languages, and an explanation of the specification JSR-223 Scripting in Java. An example application that uses the API described in the specification is presented. Selected script engine implementations are compared. In the conclusion I propose a possible direction of future development.
ii Keywords Java, scripting languages, JSR-223, multilanguage programming, script engine, Groovy, Quercus, Rhino, JRuby, Jython, Clojure
iii Table of Contents
1 INTRODUCTION ...... 1 2 SCRIPTING LANGUAGES AND JAVA...... 3 2.1 TECHNOLOGY...... 3 2.2 JAVA...... 4 2.3 SCRIPTING LANGUAGES...... 5 2.4 STRENGTHS AND WEAKNESSES OF SCRIPTING LANGUAGES...... 5 2.4.1 Runtime Performance...... 6 2.4.2 Development Speed...... 7 2.4.3 Bugs...... 7 2.4.4 Maintenance...... 8 2.4.5 Scaling...... 8
2.5 COMMON USE-CASES OF SCRIPTING LANGUAGES ON THE JAVA PLATFORM...... 8 2.5.1 Extreme programming...... 8 2.5.2 Wiring together existing components...... 9 2.5.3 End-user-customization...... 9 2.5.4 Prototyping...... 9 2.5.5 Testing...... 9 2.5.6 Administration and Management ...... 9 2.5.7 User Interface Programming...... 10 2.5.8 Web applications ...... 10
2.6 OVERVIEW OF SELECTED SCRIPTING LANGUAGES...... 10 2.6.1 Groovy...... 10 2.6.2 JavaScript – Rhino ...... 10 2.6.3 Jython ...... 11 2.6.4 JRuby...... 11 2.6.5 Clojure...... 12
3 SCRIPTING IN JAVA...... 13 3.1 JSR-223: SCRIPTING FOR THE JAVA PLATFORM...... 13 3.1.1 The general scripting API...... 13 3.1.2 Calling scripts ...... 14 3.1.3 Calling procedures and functions within scripts...... 15 3.1.4 Sharing objects...... 15 3.1.5 Web Scripting Framework...... 16
3.2 CUSTOM SCRIPTING IMPLEMENTATIONS...... 16 3.3 SUMMARY...... 17 4 SCRIPTING IN JAVA – EXAMPLE APPLICATION...... 17 4.1 ANALYSIS, DESIGN AND IMPLEMENTATION ...... 18 4.1.1 Requirements...... 19 4.1.2 Design...... 20
iv 4.1.3 Implementation...... 20
4.2 TECHNOLOGY USED IN THE APPLICATION...... 20 4.2.1 Object-relational mapping...... 20 4.2.2 Scripting engines...... 21 4.2.3 RSyntaxTextArea...... 22
4.3 EXAMPLE SCRIPTS...... 22 4.4 COMPARISON OF SCRIPTING ENGINES USED IN THE APPLICATION...... 24 4.4.1 Script Engine implementations – basic information...... 24 4.4.2 Execution speed...... 26 4.4.3 Popularity...... 27
4.5 SUMMARY...... 28 5 CONCLUSION...... 29 6 ATTACHMENT...... I 7 BIBLIOGRAPHY...... II
v List of Figures Fig. 1: The categorization of dynamic, dynamically typed, and scripting languages.....5 Fig. 2: The performance of runtimes of scripting languages...... 7 Fig. 3: Screenshot of the main window of the application...... 18 Fig. 4: The incremental development model...... 19 Fig. 5: The execution time for “Hello World” scripts run with Java Script Engines...27 Fig. 6: The popularity of Script Engines based on Google hits (in million)...... 28
List of Tables Tab. 1: The Mozilla Rhino JavaScript engine...... 24 Tab. 2: Groovy Scripting Engine...... 25 Tab. 3: Jython Scripting Engine...... 25 Tab. 4: JRuby Scripting Engine...... 25 Tab. 5: Clojure Scripting Engine...... 26 Tab. 6: Quercus PHP Scripting Engine...... 26
Attachment CD-ROM: Scripting Languages on the Java Platform (JSR-223)...... I
vi List of Abbreviations
JVM Java Virtual Machine JRE Java Runtime Environment JDK Java Development Kit JSR Java Specification Request API Application Programming Interface GUI Graphical User Interface IDE Integrated Developing Environment
7 1 Introduction
The common programming practice is to choose a programming language, best suited for the project. But this is now beginning to change. The multilanguage or hybrid ap- proach allows developers to use a different language for each individual development task within one project. You can, for example, use dynamic languages with their mod- ern features, and still retain access to Java libraries, or you can use the robust multith- read support of Java. This method is relatively new, and programmers may not fully understand how to take advantage of it. This thesis provides an overview of the ways and possibilities of running code written in scripting languages from within a host Java application. As primary sources for the theoretical part of this work I have used the book Script- ing in Java – Languages, Frameworks, and Patterns [Bosanac], the official specifica- tion JSR-223 (Scripting for the Java Platform) [JSR-223], and a number of Internet articles. The practical part describes the technologies I have used for the demonstrat- ive application, and consists mostly of my own texts. The aim of this thesis is to evaluate the potential of scripting languages on the Java platform. This is done in two parts. First, I present the concept of scripting languages in the context of Java, and the technologies and the rationale for combining both in one application. In the second part I demonstrate how the scripts and the Java applica- tions communicate on a application that I have designed. I also provide a comparison of the scripting engines that I have used. This work attempts to be a comprehensive guide to scripting on the Java platform. It is intended for programmers new to this technology, and serves as a quick introduc- tion to the subject with examples. Scripting languages and Java are a powerful combination. It is a promising new way of developing that brings together the robustness and portability of the Java Plat- form, and the dynamic elegance of scripting languages. However, the current Java Script Engine implementations have a poor runtime-performance, and unless this is improved, the technology will not be widely used. The thesis consists of three chapters. The first chapter introduces the concept of Java and scripting languages. It is a summary, comparison, and evaluation of possible use-cases for scripting languages on the Java platform. The second chapter describes the technology and the API used for communication between scripts, and the Java ap- plication. The JSR-223 specification covers also the Web Scripting Framework. How- ever this is out of scope of this paper, and I mention it only marginally. In the third chapter I present an application that demonstrates how Java and scripting languages interact. The application has a Swing GUI, and its purpose is educational. It is inten- ded as a tool for programmers to get familiar with the syntax of various scripting lan-
1 guages without the need of installing their programming environments. Its code can serve as an example how to write a multilanguage application. Later in the chapter show the results of the comparison of script engine implementations that I have used in the application.
2 2 Scripting languages and Java
To understand the concept of combining Java with scripting languages, it is important to know the characteristics of Java and of scripting languages, and the advantages and disadvantages of each approach. It is also helpful to understand the technology used for executing a code in scripting languages on the Java Platform. However, the chal- lenge is often not the technology, but the choice of the right language for each devel- opment task within the application. This chapter presents an overview of Java and scripting languages that are com- monly used on the Java platform. I summarize the properties and features of scripting languages, and list the most common use-cases. The text can be used as a guide as to where Java is the best choice and where it is better to use a scripting language.
2.1 Technology Java is a programming language with a runtime platform. The core of the platform is the Java Virtual Machine (JVM). It is the execution environment of Java programs, and provides services that normally depend on the operating system and the hardware platform; such as memory management, network services, file access and error hand- ling. The programs written in Java are not compiled into the machine code of the pro- cessor, but into an intermediate representation called Java bytecode. The bytecode is interpreted (indirectly executed) or just-in-time compiled by Java Runtime Environ- ment (JRE) installed on the machine. A Java program can thus run on any computer architecture where JRE is present. The overhead of interpretation means that inter- preted programs almost always run more slowly than programs compiled to native ex- ecutables would, but the portability is a fair trade-off. The overall machine time needed for the interpretation is still cheaper than the programmer's time needed to port an application on a different platform. The same is true, to a larger extend, also for the interpreted scripting languages. Their runtime performance could be much poorer than that of Java, but there are cases when this doesn't matter much, for example when the bottlenecks are databases or network. [Wikipedia, Java] Java is not the only programming language that compiles into Java bytecode. Groovy is another example. In general, if there exists a language interpreter (engine) written in Java, JRE can execute1 a code in that language. Furthermore, it is possible to embed the engine into a Java application so that the script may interact with the host application. The first script engines for JVM were those for web scripting lan- guages – the aim was to ease the building of web sites powered by Java. Today there
1 The code in translated by the Java script engine implementation into the Java bytecode that JRE executes.
3 are script engines for JVM for most of the popular programming languages, including PHP, JavaScript, Python, Groovy, Ruby, Perl, Tcl, Lisp, and others. The engine implementations vary greatly. Many scripting languages have a com- piler implementation that has its own API for executing scripts, configuration, and sharing objects between the script and the host application. There has been an effort to standardize the API to allow applications to execute a script regardless of its language. The specification was released in 2004 under the name JSR-223: Scripting for the Java Platform. Most of the engines in addition to their own API implement also the API described in the specification.
2.2 Java The Java Platform is the world’s most popular developing environment [Tiobe]. It's estimated that there are 14 million Java developers in the world with some nine mil- lion using Java regularly during the work day. The Java JRE is installed on a high per- centage of systems of most of the platforms, from cell phones and desktops to high speed computing clusters. [Oracle] The Java programming language is a general-purpose, portable2, object-oriented language. Its syntax is similar to C and C++, but has a simpler object model and fewer low-level facilities. Java was developed by Sun Microsystems, and later released as open source software under the terms of the GNU General Public License. Since 2010 Java is owned by Oracle that oversees and manages the Java developer community. [Wikipedia, Java] Java has a reputation of a robust and stable programming language. Its field of ap- plication is really wide, it is used in user-applications, games, web applications, pro- cesses financial transactions, etc. It's characteristics include: • strong, static typing • reliability, good scaling • multi-threading • support for distributed client and server applications • safety – secure access key system resources, protection from theft, loss and corruption • portability, platform-independency • great number of high quality libraries, wide community support • enterprise-level features like transaction management, remoting, or monitoring [Wikipedia, Java]
2 It was developed with the philosophy “write once, run anywhere”, and provides no-cost runtimes on popular platforms.
4 2.3 Scripting languages The categorization of programming languages is not fixed – there are two terms, scripting languages and dynamic languages – and they in most cases overlap. Both scripting and dynamic languages are higher-level programming languages. Scripting languages were originally intended for plugging together existing components pro- grammed in a system programming language (Java, C++, etc...), and are also called gluing languages. The term 'dynamic language' means that the source code is read at runtime, and that is the case with most of scripting languages. [Borggrén-Franck]
Fig. 1: The categorization of dynamic, dynamically typed, and scripting languages (Source: Performance of Scripting Languages [Nystrom])
The properties of scripting programming languages usually include: • dynamic or no typing • interpretation • runtime modification (new functions and variables can be added to classes and objects on the fly). • Rapid edit-compile-run-test cycle – great for agile development methods • Technical purity – designed to solve the technical problems faced by their inventors, not to address specific goals identified as part of a 'strategic plan' to influence buyers of IT solutions • Optimizing person-time, not computer-time • Open source – no bureaucratic limitations, transparent evolution • Platform neutrality [Ascher]
2.4 Strengths and weaknesses of scripting languages In general, the scripting languages provide significantly higher programmer productiv- ity than Java, but their execution speed is slower. [Vinoski] The following paragraphs
5 contain overview of the pros and cons of the scripting languages from several aspects: runtime performance, development speed, bugs, maintenance and scaling.
2.4.1 Runtime Performance Programs in Java have better runtime performance than equivalent scripts. There are two main reasons why the code written in scripting languages tends to be slower: the presence of an interpreter, and the performance-costly weak or dynamic typing. How- ever, you should not analyse the speed of the solution without considering your situ- ation and the benefits that each approach provides. If you are accessing database of doing I/O operations they are probably going to be the bottlenecks, and the slow runtime performance of scripts may not matter. Also, even if the execution speed mat- ters, the higher development speed and easier maintenance of scripts may be a fair trade-off. [Bosanac] “Scripting languages are less efficient than system programming languages, in part because they use interpreters instead of compilers but also because their basic components are chosen for power and ease of use rather than an efficient mapping onto the underlying hardware. (…) Fortunately, the performance of a scripting language isn't usually a major issue. Applications for scripting languages are generally smaller than applications for system programming languages, and the performance of a scripting application tends to be dominated by the performance of the components, which are typically implemented in a system programming language.” [Ousterhout]
6 Fig. 2: The performance of runtimes of scripting languages (Source: Performance of Scripting Languages [Nystrom])
Figure 2 shows a graph comparing the runtime performance of scripting language interpreters. In green are the script engine interpreters for JVM. Y-axis is time and memory, and performance of Java is the unit. The benchmarks used are Fannkuch, Fasta, and Mandelbrot. [Nystrom]
2.4.2 Development Speed There development speed of scripting languages is much higher than that of Java. The higher-level of abstraction, the dynamic typing, and the simplicity of the scripting lan- guages make it possible to write much shorter code that is easier to maintain. The lack of a compilation step in scripting languages means a shorter build cycle ideal for rapid prototyping and exploratory changes. [Bosanac]
2.4.3 Bugs The static typing of Java allows for automatic detection of typing errors during com- pile time. This is not possible for dynamically typed languages, so they tend to be vul- nerable to this kind of bugs. However, the typing bugs are not the only bugs. More common are errors that can be uncovered only by careful testing and code inspection. The shorter code of scripting languages allows for easier understanding of the pro- gram, and is more suitable for code review by a development team. The higher devel- opment productivity also means that more time remains for testing. [Bosanac]
7 2.4.4 Maintenance Programs written in scripting languages are shorter than their equivalents in Java, and therefore easier to maintain. This is important because the cost of maintenance is often the biggest part of the software lifecycle cost. The shorter code also means that the fu- ture modification or restructuring of the program is less painful. It is easier to debug and add additional features to a shorter program than to a longer one, regardless of what programming language it was written in. [Bosanac]
2.4.5 Scaling Scaling can be understood from two perspectives: • How the developing productivity scales depending in the size (lines-of-code) of project • How well the program handles with the user load ("it needs to scale to 100,000 requests per second") [Neward] In general Java performs better under heavy load. The scripting languages may not scale well because they are built on top of their own runtimes that are less optimized as that of Java. To judge the development productivity scaling is more difficult. The code written in a scripting language is shorter as the same program in Java, so it takes longer before it reaches such complexity that further development becomes difficult. On the other hand, the more verbose Java allows for better structuring of the code, and thanks to private/public classes and interfaces may be better suited for development of programs in large teams. [Neward]
2.5 Common use-cases of scripting languages on the Java platform Scripting languages can perform specific tasks more easily or more quickly than Java. In this section I present a list of areas where scripts and Java most often interact, and where the hybrid programming approach brings greatest advantages. These use-cases include extreme programming, wiring together existing components, end-user-cus- tomization, prototyping, testing, administration, GUI programming, and web applica- tions.
2.5.1 Extreme programming Extreme programming is a software development method with two basic principles: test-driven development and refactoring. Scripting languages may be better suited for extreme programming than Java for two reasons. Refactoring of a code in scripting languages is less time-consuming because you don't have to compile the code to run tests. The other aspect relates to typing – in Java, if a programmer wants to reuse a
8 method, but with a different input/output types, and these types don't share the same interfaces, the solution could be really complex: It is not required only to change that method definition, but also to change the types of all variables passed to that method as the particular argument. [Bosanac]
2.5.2 Wiring together existing components Scripting languages are often referred to as gluing languages. They are well suited for manipulation and wiring of pre-existing components (modules, libraries, functions), programmed in system-programming languages. Because scripting languages tend to be dynamically typed, it is easy to use various components and handle them according to the application’s need. [Bosanac]
2.5.3 End-user-customization Users of an application may need to write scripts that drive the application, extend it, or contain loops and other flow-control constructs. In such cases, it is sensible to sup- port a scripting language interpreter that can read user scripts, then run them against your Java application's classes. [Bosanac]
2.5.4 Prototyping One often-used development process is the prototyping model. It is best suited when the precise requirements for the product cannot be specified in advance, and provides valuable feedback from the customer during development. Scripting languages are of- ten considered one of the possible tools suitable for prototyping – the runtime per- formance is usually not crucial, and the rapid development and ease of refactoring of scripting languages are good arguments to use them. [Bosanac]
2.5.5 Testing There is a recent trend to use scripting languages to implement test cases. A lot of time can be saved writing unit tests in a scripting language: scripts are shorter and faster to write, so the amount of time needed to write a test case is going to improve a great deal. Scripts can also be generated and modified manually (without recompilation) – this introduces additional flexibility in the testing process. [Bosanac]
2.5.6 Administration and Management Routine administration tasks within an application are usually just a few lines of code that are executed only periodically, therefore their runtime performance is not crucial. Scripts embedded into Java and scheduled with a Java scheduler are ideal for this task. This approach saves time, and the scripts can be modified without redeploying the system. [Bosanac]
9 2.5.7 User Interface Programming Application GUI tends to change frequently. This makes it difficult to maintain in hard-coded system programming environments. Scripting languages are suitable for manipulation of the GUI widgets and the higher level nature of the scripting languages leads to faster development and shorter solutions easier to maintain. One drawback of this approach is the runtime performance. For common application interfaces it may not be a big deal, but a more graphics-intensive interface may need an alternative solu- tion in a system-programming language. [Bosanac]
2.5.8 Web applications The web applications development is one of the fields dominated by scripting lan- guages. For server-side scripting the language PHP3 is commonly used while cli- ent-side is almost solely occupied by JavaScript. Java is also used for development of web applications. Because its is a distributed programming language it is convenient for large Web solutions. [Bosanac]
2.6 Overview of selected scripting languages The specific properties of scripting languages vary greatly. Most of them were created with having a specific purpose in mind. In the following section I present a short sum- mary of features and characteristics of these scripting languages and their engine im- plementations: Groovy, JavaScript, Python, Ruby, and Clojure.
2.6.1 Groovy Groovy is an object-oriented dynamic programming language written specially for the Java Platform, unlike the other scripting languages that exist as ports to the Java plat- form. [Groovy, Differences] Its syntax is very similar to that of Java but more evolved. Each Groovy class is a full-fledged Java class and most Java code is also syntactically valid Groovy. It is easy to learn for Java developers, and allows seamless use the Java libraries without the need for adapters. [Roth] Groovy has its own custom scripting implementation that is explained later. Its fea- tures include powerful processing primitives, support of both static and dynamic typ- ing, and closures4. It can simplify testing by supporting unit testing and mocking out- of-the-box. [Groovy]
2.6.2 JavaScript – Rhino JavaScript5 is a lightweight, object-oriented language, most known as the scripting language for web pages. It's a dynamic and weakly typed, lightweight, object-oriented
3 PHP Hypertext Processor 4 Mechanism for passing blocks of code as method arguments. 5 JavaScript is a dialect of the EMCAScript language
10 language. It's capable of functional programming – it supports higher-order functions, and closures. JavaScript tends to fail quietly in the case of a programming error, this is desirable in web applications, but can make it difficult to build large systems. [Ascher] Mozilla Rhino is a JavaScript engine that is included as a feature in the Java 6 librar- ies. It is intended for server-side applications, hence there is no built-in support for the browser objects that are commonly associated with JavaScript. [Caldwell]
2.6.3 Jython Python is an interpreted, object-oriented, general-purpose language. It has a clear, in- tuitive syntax, with powerful high-level data structures, and a flexible dynamic typing. Some of the features of Python include: • easy to learn syntax emphasizing readability • dynamic semantics • dynamic typing and dynamic binding • incorporates modules, exceptions, and classes • attractive for Rapid Application Development [Python] Jython is an implementation of the Python programming language written in Java. Programs in Jython can seamlessly import and use any Java class. Jython programs use mostly Java classes instead of Python modules. It's often used in prototyping and GUI application design, as well as in high-performance systems. [Ascher]
2.6.4 JRuby JRuby is a Java implementation of the Ruby programming language. It provides a complete set of core classes, as well as most of the Ruby Standard Libraries. [Ruby] Ruby is a dynamic, reflective, general-purpose object-oriented programming lan- guage that supports real threading. Is syntax is inspired by Perl and contains Small- talk-like features. The philosophy of Ruby is the principle of least astonishment, meaning that the language should behave in such a way as to minimize confusion for experienced users. The features of JRuby include: • High performance • Great number of libraries • Closures, first-class continuations, unique block syntax • Automatic garbage collection • Exception handling
11 [Wiki, Ruby]
2.6.5 Clojure Clojure is a functional and multi-paradigm, dynamic, general-purpose language. It's a dialect of Lisp that runs on the JVM, and the Common Language Runtime. Its features include: • multi-threading, concurrency • strong-typing • code-as-data philosophy, closures • sophisticated macro system • almost no syntax • polymorphism [Clojure]
12 3 Scripting in Java
There are two approaches to bringing scripting languages on the Java Platform. The first one is to use the Java Native Interface to bridge inter-process communication between Java and the native scripting environment, usually C/C++-based. This presents undesirable restrictions and can result in performance bottlenecks. The second approach is known as 'scripting in Java'. The scripting language is run on top of the Java virtual machine using a scripting engine for JVM (Java-based scripting runtime implementation). These implementations are slower than the native runtimes and their real value is that they can call Java classes and vice-verse. This way they have access to everything that is implemented in Java. Jython, Rhino, Groovy or Clo- jure are examples of such scripting engines. [Roth]
3.1 JSR-223: Scripting for the Java Platform JSR 223: Scripting for the Java Platform is a standard interface to host scripting en- gines. It helps developers integrate Java technology and scripting languages by defin- ing a standard framework and API. The framework allows developers to embed scripting environments within a Java-based host application, access and control Java objects from the scripting environment, and provides a standard, portable6 way to gen- erate web content with scripting languages. The script engines that implement this specification are called Java Script Engines. [JSR-223] [O'Conner] One of the advantages of the specification is that an application can be unaware of particular scripting languages being used. This comes handy when using scripting for end-user-customization – the user can choose the language to write scripts in. The spe- cification is best fit for implementations of general-purpose languages. Many scripting engines include in addition to the implementation of the API described by the specific- ation also a custom API with specific functionality. [Caldwell] For following languages there exists a JSR-223-compliant implementation: JavaS- cript, AWK, FreeMarker, Groovy, Jaskell, Jelly, Jep, Jexl, Judoscript, Pnuts, Python, Ruby, Scheme, Sleep, Tcl, Velocity, and PHP. [David]
3.1.1 The general scripting API The scripting API for Java Script Engines is located in the javax.script package. The API is relatively small; for interconnecting scripts with the host Java application you will probably need to use only these classes and interfaces: [O'Conner]
• ScriptEngineManager – discovery mechanism of available scripting implementations
6 The extent to which programs behave identically in different implementations of the specification
13 • ScriptEngineFactory – provides the ScriptEngine object and various details about the scripting language • ScriptEngine – the fundamental interface required for every implementation • ScriptContext – provides information about attributes and scopes • Bindings – a map of key-value pairs of objects from host application that can be accessed from within scripts • Invocable – an optional interface, provides access to functions and procedures within a script • Compilable – an optional interface, allows scripts to be executed repeatedly without recompilation. • ScriptException – generic Exception class for the Scripting APIs, includes the error messages from the scripts
3.1.2 Calling scripts To call a script using the standard API you have to create a ScriptEngineMan- ager object, retrieve a ScriptEngine object from the manager, and evaluate a script using the ScriptEngine object. The script engine jar must be on the classpath. Here is an example with the Rhino7 JavaScript engine: [O'Conner]
ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName("JavaScript"); try { engine.eval("print('Hello, world!')"); } catch (ScriptException ex) { ex.printStackTrace(); }
A script (character sequence obtained from either a String or java.io.Reader is run by the engine's eval method. Additional engines can be used by placing them on the classpath. Engines for Groovy, JPython or Clojure are available for download from websites of the projects.
The discovery mechanism of ScriptEngineManager provides the names of the available script engines. The names can be used as arguments for the getEngineByName method. ScriptEngineManager manager = new ScriptEngineManager(); List
7 Rhino is included in the core JDK 6 libraries
14 3.1.3 Calling procedures and functions within scripts Sometimes you may want to invoke only a specific procedure or function from the script. This is done via the Invocable interface. You can call only methods or func- tions that the engine has already evaluated. The support of this interface is not re- quired, however the Rhino JavaScript engine implementation supports it:
ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName("JavaScript"); try { engine.eval("function sayHello() {" + " println('Hello, world!');" + "}"); Invocable invocableEngine = (Invocable) engine; invocableEngine.invokeFunction("sayHello"); } catch (ScriptException ex) { ex.printStackTrace(); } } }
3.1.4 Sharing objects The JSR-223 provides a way to share objects between the script and the host Java ap- plication. It's done through a mechanism called Bindings. There are three types of Bindings: • Dynamic Bindings • Programmatic Bindings • Static Bindings Dynamic Bindings are created during script execution. They are mostly used to im- port a Java package or class into the script namespace. It's usually done by a built-in function:
// PHP: $javadate = new Java(“java.util.Date”) $response_class = new JavaClass (“javax.servlet.http.HttpServletResponse”)
// JavaScript: importPackage(java.util); var hashtable = new Hashtable(); importPackage(java.net); var socket = new Socket(“java.sun.com”, 80);
Programmatic Bindings are a map of key-value pairs created manually before the script execution. Objects in the map are accessible by both the Java program and the script. Method calls on these objects are generally made using the syntax of the script-
15 ing language. You can place an object in the map using the put method and retrieve it using get method: [O'Conner] [JSR-223]
ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName("JavaScript"); try { engine.put("zero", new Double(0.0)); Bindings bindings = engine.getBindings(ScriptContext.ENGINE_SCOPE); engine.eval("zero++;"); System.out.println( "the increment is: " + engine.get("zero") ); } catch (ScriptException ex) { ex.printStackTrace(); } Static Bindings are built-in functions of Java implemented by the interpreter. They are not created by the user. For example, PHP uses native callback functions in its host application to implement some of its built-in functions such as echo, header or cook- ies. [JSR-223] There are cases where differences between Java and the scripting language may cause inconsistencies, such as Java class overloading or conversion of return values. To resolve such cases I recommend to read the specification.
3.1.5 Web Scripting Framework The Web Scripting Framework is an optional part of the specification. It uses the Scripting API to generate Web content in any Servlet Container. The framework al- lows scripting pages to be included in Java Web Applications, and defines a standard mechanism which presents the web constructs from the Servlet Container to the scripting engines. [JSR-223]
3.2 Custom scripting implementations Some scripting engine implementations for JVM have their own API. It's either be- cause they were created sooner than the JSR-223 was ready, or the scripting languages provide some advanced functionality, for example thread management, that the com- mon scripting API omits. Example of such implementations are Groovy, Mozilla Rhino, JRuby, Jython, Scala, or JavaFX. Most of them implement both the standard API and a custom one. [Caldwell] To use a custom implementation of a scripting engine, you need to add the jars of the Java-based scripting runtimes to your Java classpath. After that the engine can be instantiated and you can execute scripts within your Java environment. In most cases, the scripting implementation provides simple engine classes to do this:
16 // run a Groovy scripting (Groovy V1.1) GroovyShell gs = new GroovyShell(); gs.evaluate(script);
// run a Python scripting (jython V2.2) PythonInterpreter interp = new PythonInterpreter(); interp.exec(script)
In the next example I import java.security.* library into the Groovy script, and I share an object between the script and the host application. When the script evalu- ates, the String value of the “sharedObject” is replaced by it's MD5 sum, and sub- sequently displayed on standard output by the host application:
String script = new String( "import java.security.*;" + "MessageDigest d = MessageDigest.getInstance('MD5');" + "sharedObject = d.digest(sharedObject.getBytes()).toString();" ); Binding binding = new Binding(); binding.setProperty("sharedObject", new String("Waf!")) ; GroovyShell shell = new GroovyShell(binding); try { Object result = shell.evaluate(script); System.out.println(binding.getProperty("sharedObject")); } catch (Exception ex){ ex.printStackTrace(); }
3.3 Summary The mission of JSR-223 is to bridge the scripting languages with Java. The script- ing-in-Java technology makes it possible to write high-performance, scalable applica- tions in a very productive and elegant way. Though the semantic differences sometimes require ugly solutions, the supported features are in most cases sufficient to write enterprise-level applications using the Java platform, Java code, and the script- ing language of choice. [Roth] In the next chapter I present an example application that uses the JSR-223 API to run user-defined scripts. The chapter includes an overview of scripting engines that I used in the example application. It is in the form of tables and graphs that show the runtime performance, popularity and information specific for each engine.
4 Scripting in Java – Example application
In this chapter I present own work and my results of using the Scripting in Java tech- nology. I have designed on application that uses the API described in JSR-223 to run user-defined scripts. I had following goals in mind: • To demonstrate how the general scripting API is used in practice.
17 • To provide a framework where users can see examples of scripts in various scripting languages, and can design and execute their own scripts without the need to install the developing environment for each scripting language. It can serve as a tool for learning scripting languages. • To test the runtime performance of scripting engines. For development I have used the NetBeans IDE. The example application uses an em- bedded database and persistence to store scripts. For creation of the graphical user in- terface (GUI) I have used the Swing widget toolkit. The GUI consists of two panes: a library of scripts, and an editor with output pane. The user can browse the library and select a script, or create an own script. The selected script is displayed in the editor. The editor supports syntax highlighting, matching of parenthesis, and undo/redo func- tionality. The user executes the script by clicking the Run button. The script then runs in a separate thread and can be killed if it freezes. The standard output of the script, to- gether with the execution time is then displayed. If the script exists with an error, the error message displays in the output pane.
Fig. 3: Screenshot of the main window of the application.
4.1 Analysis, design and implementation The analysis and design are vital parts of software development – their underestima- tion can lead to severe problems or even to failure of the project. The trouble usually lies in the communication between the development team and the users.
18 Fig. 4: The incremental development model. (Source: Analýza a návrh systémů [Ráček], translation: author)
In my case, the application is a small project on which I have worked alone, and the targeted users of the application are programmers. This simplifies the design a great deal because there are no communication obstacles present. As the development life- cycle model I have used a simplified incremental life-cycle model (see Figure 4).
4.1.1 Requirements The first step in the analysing of an idea for a software application is to define the sys- tem and user requirements. In my case they were following: • usability, intuitive user interface • library for storing scripts (CRUD8 functionality) • easy to use editor supporting syntax highlighting • widest possible support for scripting languages • script execution shouldn't freeze the application I originally intended to create a web application, but the fact that a user can execute any script would be a serious vulnerability for the web server. Instead I decided to make a desktop application.
8 Create, Read, Update and Delete.
19 4.1.2 Design I considered several possible layouts, and thought about inclusion of additional func- tionality, such as script descriptions or an area for the input for the script. On the end I chose the simplest solutions. The GUI layout would consist of four areas: • script library in the form of simple table • editor • area for the standard output of the script • control area with four buttons (New, Delete, Save, Run) I have rejected the script descriptions and the input field for the script. The descriptions could be included in the script code as comments, and the data in the input field can be as well supplied in the form of a variable in the code.
4.1.3 Implementation I have developed the application in NetBeans IDE because of its tool for designing GUI with Swing9. The Netbeans development environment also provides a project template that simplifies the persistence configuration. As a database I have used the HSQLDB10 which is a fast open source MySQL database written in Java. It is embed- dable, so no local database installation is required. I wanted the script editor to support syntax highlighting, and I managed to find a Swing component that met my needs: RSyntaxTextArea. As for the execution of the scripts, the Java Script engines imple- menting JSR-223 are the best choice. The general API defined in JSR-223 enabled me to write one simple method for executing a script in any supported language. For the script library I have used a simple Swing JTable component with a model class. In the following section I explain in more detail the implementation of selected parts of the application.
4.2 Technology used in the application
4.2.1 Object-relational mapping The Object-relational mapping (ORM) can greatly simplify the access to the database. Netbeans provides a template for Desktop Database Application11. All you need is to provide a database connection to an existing database with tables set up. Netbeans automatically generates the classes that map to the tables, as well as the configuration file persistance.xml. What is actually used is the TopLink implementation of the framework Java Persistence API.
9 The primary Java GUI widget toolkit 10 It is available under a variation of BSD License from the homepage of the project: http://hsqldb.org 11 In Netbeans IDE 6.9, New Project → Java → Java Desktop Application → Next, and select Database application
20 The database objects are accessed through EntityManager object using named quer- ies. The code for getting a list of objects from the database looks like this:
EntityManagerFactory emf = javax.persistence.Persistence. createEntityManagerFactory("home_hsqldbPU"); entityManager = emf.createEntityManager(); Query query = entityManager.createNamedQuery("Examples. findAll"); List
Where home_hsqldbPU is the persistence unit name specified in the configuration file, and Examples.findAll is the named query. The persistence API supports transactions, and if something goes wrong, the rollback function can be used: try { entityManager.getTransaction().begin(); entityManager.persist(selectedExample); entityManager.getTransaction().commit(); } catch(Exception ex) { entityManager.getTransaction().rollback(); } The WikiBook Java Persistence12 is a good reference for using the API.
4.2.2 Scripting engines In the application I have used the discovery mechanism of the API to find the avail- able engines, and show them in a Combo Box for selection. When a language is selec- ted, the syntax highlighting of the editor is changed to that of the language. The API for executing the scripts was described in the previous chapter. One challenge that I faced was to redirect the standard output of the script into a Swing JTextPane component. I used the System.setOut() method: String stdoutText = new String(); String errorText = new String();
ByteArrayOutputStream baos = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(baos); System.setOut(ps);
ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName(language); engine.put("objectFromJava", object); Bindings bindings = engine.getBindings(ScriptContext. ENGINE_SCOPE); try { engine.eval(code); if(baos!=null) this.stdoutText = baos.toString(); } catch (ScriptException ex) { errorText += ex.getMessage(); }
12 Available at http://en.wikibooks.org/wiki/Java_Persistence
21 I have considered the possibility of streaming the standard output, so that it would be displayed on the fly as the script generates it, not only after it finishes. I did some re- search on the Internet to see how other people solved similar problems. I found some solutions, but they were rather complicated. I decided that the simpler method of dis- playing the output after the script finishes is sufficient for my purposes. However, it is an interesting problem, and the inclusion of an interactive console for communication with the script is a good idea for the future development of the application.
4.2.3 RSyntaxTextArea RSyntaxTextArea is a syntax highlighting text component for Java Swing suitable for an application that needs to edit or view source code. The component is open source and available under GNU Lesser General Public Licence. It supports a number of in- teresting features: • Find/Replace • Loading and saving of local or remote files (via FTP). • User-defined macros • Code templates • Unlimited undo/redo • Drag and drop • Edit with multiple fonts simultaneously • Bracket matching • Current line highlighting • Clickable hyperlinks [Fifesoft] In the application I implement only some of the features: the syntax highlighting, undo/redo, bracket matching, and current line highlighting.
4.3 Example scripts The application includes several example scripts. Here I present only the most inter- esting of them. The following Groovy script is taken from the book Scripting in Java [Bosanac]. It executes a Unix command, provided that the application is run on a UNIX-based sys- tem. In this case the output of the command line program free13 is displayed: process = "free".execute() output = process.getText() if (process.waitForOrKill(1000) != 0)
13 The program displays the amount of memory and swap used.
22 output.eachLine { println it } else println process.text The following script in Groovy imports the groovy SQL library and connects to the database embedded in the application. The names of the saved scripts are displayed on the output: import groovy.sql.Sql sql = Sql.newInstance("jdbc:hsqldb:file:home_hsqldb" , "org.hsqldb.jdbcDriver") output = "" sql.eachRow("SELECT * FROM PUBLIC.EXAMPLES") { output += it[0] + " " + it[1] + "\n" } println(output);
In the next script, the objectFromJava object is the main frame of the application available from inside of the script through Bindings. The object's class includes getters for some of the Swing components. These getters are used to access the components, and change some of their properties: import java.awt.Color; import java.awt.Font; application = objectFromJava;
Font font = new Font("Verdana", Font.BOLD, 12); application.getTable().setFont(font); application.getTable().setForeground(Color.GREEN); application.getTable().setBackground(Color.BLACK); application.getCodeTextArea().setForeground(Color.GREEN); application.getCodeTextArea().setBackground(Color.BLACK); application.getCodeTextArea().setCaretColor(Color.WHITE); The following Clojure script is a small GUI application for converting Celsius degrees to Fahrenheit. It is taken from the Clojure Programming Wikibook [Wikibooks, Clo- jure].
(import '(javax.swing JFrame JLabel JTextField JButton) '(java.awt.event ActionListener) '(java.awt GridLayout))
(let [frame (new JFrame "Celsius Converter") temp-text (new JTextField) celsius-label (new JLabel "Celsius") convert-button (new JButton "Convert") fahrenheit-label (new JLabel "Fahrenheit")] (. convert-button (addActionListener (proxy [ActionListener] [] (actionPerformed [evt]
23 (let [c (Double/parseDouble (. temp-text (getText)))] (. fahrenheit-label (setText (str (+ 32 (* 1.8 c)) " Fahrenheit")))))))) (doto frame ;(.setDefaultCloseOperation (JFrame/EXIT_ON_CLOSE)) ;uncomment this line to quit app on frame close (.setLayout (new GridLayout 2 2 3 3)) (.add temp-text) (.add celsius-label) (.add convert-button) (.add fahrenheit-label) (.setSize 300 80) (.setVisible true)))
4.4 Comparison of scripting engines used in the application I have included the following scripting engine implementations in the example applic- ation: Rhino, Groovy, JRuby, Jython, Quercus, and Clojure. In the tables 1 to 6 I provide the basic information about each engine: the version of the engine used, the description of installation, and the list of supported APIs. I have tested the execution-speed of each engine, and have done a small research about the popularity of each language and its engine implementation. The results are presented later in this chapter.
4.4.1 Script Engine implementations – basic information
Name and current version Mozilla Rhino 1.7R2 Language ECMAScript14 – JavaScript Project website http://www.mozilla.org/rhino/ Embedding Included in JRE 6 Scripting API Java Script API (JSR-223) Custom scripting API Popularity based on Google 7.1 million hits (“java script rhino”) Size of the binary N/A, included in JRE Notes Tab. 1: The Mozilla Rhino JavaScript engine
Name and current version Groovy Scripting Engine 1.8
14 ECMAScript is a language standard. JavaScript is one of the implementations of this standard.
24 Language Groovy Project website http://groovy.codehaus.org/ Embedding Copy groovy-all-1.8.0.jar on classpath Scripting API Java Script API (JSR-223) Custom scripting API Popularity based on Google 18.7 million hits (“java script groovy”) Size of the binary groovy-all-1.8.0.jar: 5.7 MB Notes “higher-level Java” Tab. 2: Groovy Scripting Engine
Name and current version Jython 2.5.2 Language Python Project website http://www.jython.org/ Embedding Copy jython.jar on classpath. Scripting API Java Script API (JSR-223) Custom scripting API – PythonInterpreter Popularity based on Google 0.2 million hits (“java script jython”) Size of the binary 7.9 MB Tab. 3: Jython Scripting Engine
Name and current version JRuby 1.6.1 Language Ruby Project website http://www.jruby.org/ Embedding Copy jruby.jar on classpath. More information: [https://github.com/jruby/jruby/wiki/RedBridge] Scripting API Java Script API (JSR-223) Bean Scripting Framework API Custom scripting API – Embed Core Popularity based on Google 0.6 million hits (“java script jruby”) Size of the binary 9.1 MB Tab. 4: JRuby Scripting Engine
25 Name and current version Clojure Scripting Engine, Clojure 1.2 Language Clojure (a dialect of Lisp) Project website http://clojure.org/ http://code.google.com/p/clojure-jsr223/ Embedding Download clojure-1.2.0.zip (project website) and clo- jure-jsr223-1.2.zip (clojure-jsr223 website), copy clo- jure.jar and clojure-jsr223.jar on classpath. Scripting API Java Script API (JSR-223) Popularity based on Google 0.3 million hits (“java script clojure”) Size of the binary 3.1 MB Notes Value that should be written on standard output is in- stead returned Tab. 5: Clojure Scripting Engine
Name and current version Quercus Script Engine 4.0.11 Language PHP Project website http://quercus.caucho.com/ Embedding Copy quercus.jar and resin-util.jar on classpath. Scripting API Java Script API (JSR-223) Popularity based on Google 0.01 million hits (“java script quercus”) Size of the binary 4.6 MB Tab. 6: Quercus PHP Scripting Engine
4.4.2 Execution speed By incorporating several script engines in one application I could compare how each of them performs. The benchmarking I have used is rather primitive, and my goal is to provide a only a rough idea of the speed of each language engine. When executing a script for the first time, the script engine is being initialized, and this execution takes longer than the subsequent ones. I have run the 'Hello World' script for each language, and for the scripts I have measured separately the first execu- tion and the next. I have repeated this process 10 times. Originally I intended to use a benchmark algorithm from The Computer Language Benchmark Game which is a project to compare the performance of various languages [Shootout]. I tried to run some of the benchmark algorithms, and found out that to test
26 repeatedly all the scripting engines would be too time- and resource-consuming. Such a test is beyond the scope of this thesis.
2500
2000
1500 First execution 1000 Second 500 execution
0 Groovy Jruby Quercus Rhino Jython Clojure
Fig. 5: The execution time for “Hello World” scripts run with Java Script Engines (Values in milliseconds)
The results of the “Hello World” test are shown in Figure 5. The first execution took about 30 to 70 times as long as the subsequent executions. The exceptions were the engines Rhino and Clojure: With Rhino the difference was only small, and in the case of Clojure the first and second executions took about the same amount of time. The subsequent script execution times for all the engines were about 40 ms, only Quercus took longer. I don't want to run into conclusion about which engine is fastest because a single test, especially one this simple, can be misleading. When faced real problems the en- gines could behave much differently. However, even a comparison such as this could point us to the right direction; for example that Rhino is a good choice (it's not by chance that it is included in JRE), or that Clojure may be really fast.
4.4.3 Popularity One of the criteria when choosing a scripting language may be its popularity among developers. More developers mean wider community support and more tutorials and solutions of specific problems available on the forums and blogs. The popularity may also indirectly tell how “good” the language or engine implementation is. I have measured it by Google hits on specific search terms. I have searched for the pattern “language name programming” to get an idea about the popularity of the pro- gramming language in general. This information may not be that valuable; for ex- ample JavaScript is usually used for client-side web scripting which differs a lot from its usage on top of a host Java application. More interesting is the number of hits for the pattern “java script Java script engine name”. This tells us how popular the specif- ic Java scripting engine implementation is. Indirectly it reflects how actively it is de-
27 veloped, and how many projects use it. The results are presented in a graph in Fig- ure 6.
PHP / Quercus
Lisp / Clojure
Python / Jython “java script” + script engine Ruby / JRuby name language name + Groovy “programming” JavaScript / Rhino
0 5 10 15 20 25
Fig. 6: The popularity of Script Engines based on Google hits (in million)
4.5 Summary On the application and the script examples I have demonstrated the way the script- ing API is used, and the possibilities and potential of the technology. The main prob- lem is the speed of the implementations. I have performed a simple execution-time test for each scripting engine. Rhino and Clojure seem to be the fastest of the engines that I tested. I also compared the amount of Google hits for each script engine imple- mentation. The results reflect the size of the developer community, and the amount of information resources available. Groovy came out as the most popular, probably thanks to its almost zero learning curve for Java developers. The embedding of the scripting engines into a Java application is straightforward and requires no special configuration. The JSR-223 scripting API is easy to use. Of the script engines that I have tried out, JavaScript and Groovy are probably the best choices. JavaScript is fast and the de-facto standard, as it is included in the JRE 6. Clojure also looks interesting: it seems to be fast, and its functional paradigm could make it ideal for certain development tasks.
28 5 Conclusion
The aim of this work was to evaluate the potential of scripting languages on the Java Platform. This was done from several perspectives: • The underlying technology • The strengths and weaknesses of both Java and scripting languages • The best use-cases for a script language in a Java application • The API for embedding script engine implementations • Presentation of an example application that uses the API • Comparison of selected script engine implementations However, I dealt only with one side of the problematic; the execution of code in scripting languages from within a host Java application. It is possible to combine Java with scripting languages also the other way around: Java components and libraries can be used from an application coded in a scripting language. I bypassed this area be- cause the assignment of the thesis is focused on JSR-223. The specification concerns only with Java Script Engines and their usage in a host Java application. The other ap- proach mentioned can make an interesting topic for future work. The Scripting in Java is a technology with great potential of saving programmer's time, but it is not mature yet. The performance is in most cases still very poor, and it can take some time before it gets significantly better. Although there are cases where the performance doesn't play a role, it is likely that some years will pass before the scripting in Java becomes a wide-spread approach. The trend of programming becoming more higher-level can be easily traced through the past decades, and there is no reason this should change. The speed of the hardware continues to increase, and programmers demand still simpler and more eleg- ant tools. If an effort is put into the improvement of the JVM support for scripting lan- guages, and into the optimization of the script engines, it is likely that the hybrid programming on top of Java will become wider spread. My educated guess is that when more developers become aware of the technology and the Java development community puts an effort into it, it may in the horizon of a ten years even become a standard.
29 6 Attachment
CD-ROM: Scripting Languages on the Java Platform (JSR-223) Includes: • The compiled example application Scripting in Java and database files (folder: ScriptingInJava_application/dist) • Source-code of the application • Text of this thesis in electronic form
Under a Unix-like system the application can be run by the execute_the_application.sh script located in the root directory of the CD- ROM: cd ScriptingInJava_application/dist java -jar ScriptingInJava_12_5.jar
I 7 Bibliography
[Bosanac] Bosanac, D.: Scripting in Java: Languages, Frameworks, and Patterns. Addison-Wesley, 2007.
[JSR-223] Oracle. JSR-223: Scripting for the JavaTM Platform – Public Review Draft Specification version 1.1 [online]. Available from:
[O'Conner] O'Conner, J. Scripting for the Java Platform [online]. Oracle. July 2006. Available from:
[Caldwell] Caldwell, D. P. Patterns for Integrating Java and JavaScript Technology: Tales from the Front Lines . 2008 JavaOne Conference. Available from:
[Roth] Roth, G. Scripting on the Java platform: Using Groovy, Jython, and JRuby for Java development. JavaWorld.com. November 20, 2007. Available from:
[Ascher] Ascher, D. Dynamic Languages – ready for the next challenges, by design [online]. July 2004. Available from:
[Vinoski] Vinoski, S. Multilanguage Programming . Toward Integration . May/June 2008. IEEE Computer Society.
[Tremblett] Tremblett, P. JSR 223: Scripting for the Java Platform [online]. March 2009. Available from:
[Nystrom] Nystrom, N. Performance of Scripting Languages [online]. May 8, 2010. Available from:
[Ascher] Ascher, D. Dynamic Languages – ready for the next challenges, by design [online]. July 27, 2004 . Available from:
II [Wikipedia, Java] Wikipedia contributors. Java (programming language) [online]. Wikipedia, The Free Encyclopedia [cited 2011 May 09]. Available from:
[Tiobe] TIOBE Software. TIOBE Programming Community Index for May 2011 [online]. Available from:
[Oracle] Oracle. Java – The Best Environment for Network-based Applications [online]. Available from:
[Borggrén-Franck] Borggrén-Franck, J. Running Dynamically Typed Languages on the Java Virtual Machine. Stockholm, Sweden 2010. Available from:
[Ousterhout] Ousterhout J. K. Scripting: Higher Level Programming for the 21st Century. IEEE Computer magazine. March 1998. Available from:
[Neward] Neward, T. Can Dynamic Languages Scale? [online]. January 23, 2008. Available from:
[Groovy, The Groovy Project. Differences from Java [online]. Available form: Differences]
[Groovy] The Groovy Project. Groovy [online]. Available form:
[Ascher] Ascher, D.: Dynamic Languages – ready for the next challenges, by design [online]. July 27, 2004 . Available from:
[Python] The Python Project. What is Python? Executive Summary [online]. Available from:
[Ruby] JRuby Wiki contributors. About JRuby [online]. GitHub Social Coding. May 17, 2011. Available from:
[Wikipedia, Ruby] Wikipedia contributors. Ruby (programming language). Wikipedia, The Free Encyclopedia [cited 2011 May 09]. Available from: < http://en.wikipedia.org/wiki/Ruby_(programming_language )>.
[Clojure] The Clojure Project. Clojure, Rationale [online]. Available from:
III [David] David, A. JSR 223 compliant scripting languages [online]. May 08, 2008. Available from:
[Ráček] Ráček, J.: Analýza a návrh systémů. 2009 .
[Fifesoft] Fifesoft: Open Source Staff. RSyntaxTextArea [online]. May 16, 2011. Available from:
[Wikibooks, Clojure] Wikibooks contributors. Clojure Programming. Wikibooks, Open Books for an Open World [cited 2011 May 17]. Available from: < http://en . wikibooks.org/wiki/Clojure_Programming>.
IV