Groovy for Domain-Specific Languages, Second Edition: Extend and enhance your Java applications with domain-specific scripting in Groovy
()
About this ebook
Fergal Dearle
Fergal is a seasoned software development professional with 23 years of experience in software product development across a wide variety of technologies. He is currently principal consultant with his own software development consulting company, Dearle Technologies Ltd., engaged in design, development, and architecture for new software products for client companies. In the past Fergal has worked in lead architect and developer roles for Candle Corporation on the OMEGAMON product which is now part of IBMs Tivoli product suite as development manager for the Unix implementations of Lotus 1-2-3. In the early 1990s Fergal lead the team at Glockenspiel that developed CommonView, the first object-oriented UI framework for Microsoft Windows. The team was awarded one of the first ever Jolt Productivity Awards by Dr Dobbs Journal.
Related to Groovy for Domain-Specific Languages, Second Edition
Related ebooks
Advanced Functional Programming: Mastering Concepts and Techniques Rating: 0 out of 5 stars0 ratingsMastering Visual Studio Code: Navigating the Future of Development Rating: 0 out of 5 stars0 ratingsSpring Security: Effectively secure your web apps, RESTful services, cloud apps, and microservice architectures Rating: 0 out of 5 stars0 ratingsBuilding an API Product: Design, implement, release, and maintain API products that meet user needs Rating: 0 out of 5 stars0 ratingsUltimate SwiftUI Handbook for iOS Developers: A complete guide to native app development for iOS, macOS, watchOS, tvOS, and visionOS Rating: 0 out of 5 stars0 ratingsRobot Grippers Rating: 3 out of 5 stars3/5Mastering C# Concurrency Rating: 2 out of 5 stars2/5Breaking Into IT: Your Roadmap to Success in the Tech Industry Rating: 0 out of 5 stars0 ratingsLess Web Development Essentials - Second Edition Rating: 0 out of 5 stars0 ratingsJetpack Compose 1.5 Essentials: Developing Android Apps with Jetpack Compose 1.5, Android Studio, and Kotlin Rating: 0 out of 5 stars0 ratingsLearn Java 12 Programming: A step-by-step guide to learning essential concepts in Java SE 10, 11, and 12 Rating: 0 out of 5 stars0 ratingsAdvanced Groovy Programming: Comprehensive Techniques and Best Practices Rating: 0 out of 5 stars0 ratingsMastering Groovy Programming: From Basics to Expert Proficiency Rating: 5 out of 5 stars5/5Introduction to JVM Languages Rating: 0 out of 5 stars0 ratingsJava: Programming: Your Step by Step Guide to Easily Learn Java in 7 Days Rating: 4 out of 5 stars4/5Seriously Good Software: Code that works, survives, and wins Rating: 5 out of 5 stars5/5Java EE 7 First Look Rating: 0 out of 5 stars0 ratingsC# Programming Fundamentals Rating: 0 out of 5 stars0 ratingsJava: Advanced Guide to Programming Code with Java: Java Computer Programming, #4 Rating: 0 out of 5 stars0 ratingsObject-Oriented JavaScript - Third Edition Rating: 4 out of 5 stars4/5Java Quick Syntax Reference Rating: 0 out of 5 stars0 ratingsGroovy 2 Cookbook Rating: 0 out of 5 stars0 ratingsJAVA PROGRAMMING FOR BEGINNERS: Master Java Fundamentals and Build Your Own Applications (2023 Crash Course) Rating: 0 out of 5 stars0 ratingsBeginning C++ Game Programming Rating: 4 out of 5 stars4/5Rust Mini Reference: A Hitchhiker's Guide to the Modern Programming Languages, #5 Rating: 0 out of 5 stars0 ratingsJava Coding Problems: Improve your Java Programming skills by solving real-world coding challenges Rating: 0 out of 5 stars0 ratingsKotlin at a Glance: Use of Lambdas and higher-order functions to write more concise, clean, reusable, and simple code Rating: 0 out of 5 stars0 ratingsInstant GSON Rating: 0 out of 5 stars0 ratings
Reviews for Groovy for Domain-Specific Languages, Second Edition
0 ratings0 reviews
Book preview
Groovy for Domain-Specific Languages, Second Edition - Fergal Dearle
Table of Contents
Groovy for Domain-specific Languages Second Edition
Credits
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Support files, eBooks, discount offers, and more
Why subscribe?
Free access for Packt account holders
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Errata
Piracy
Questions
1. Introduction to DSLs and Groovy
DSL – a new name for an old idea
The evolution of programming languages
General-purpose languages
Spreadsheets and 4GLs
Language-oriented programming
Who are DSLs for?
A DSL for process engineers
Stakeholder participation
DSL design and implementation
External versus internal DSLs
Operator overloading
Groovy
A natural fit with the JVM
Groovy language features
Static and optional typing
Native support for lists and maps
Closures
Groovy operator overloading
Regular expression support
Optional syntax
Groovy markup
Summary
2. Groovy Quick Start
Installing Groovy with GVM
Installing GVM
Installing GVM on Windows
How to find and install Groovy from binaries
Running Groovy
The Groovy script engine – groovy
Shebang scripts
The Groovy shell – groovysh
The Groovy console – groovyConsole
The Groovy compiler – groovyc
The Groovy IDE and editor integration
NetBeans
Eclipse
Spring STS
IntelliJ IDEA
Other IDEs and editors
Summary
3. Essential Groovy DSLs
Installing Gradle
Gradle basics
Gradle build scripts
Gradle tasks
Adding actions to tasks
Default tasks
Creating task dependencies
Built-in tasks and plugins
Plugins
The Gradle Groovy plugin
The IDEA plugin
The Eclipse plugin
Repositories
Dependencies
Spock tests
Given, when, then
Spock specification structure
Feature methods
Blocks
Fields
Fixture methods
Helper methods
Where blocks
Fixture blocks
Testing Gradle using Spock
Further reading
Summary
4. The Groovy Language
Introducing the Groovy language
The module structure
Groovy shorthand
Implicit imports
Default visibility, optional semicolon
Optional parentheses
The optional dot in method chains
Dynamic types
The optional return keyword
Properties and GroovyBeans
Assertions
Autoboxing
Strings
Regular expressions
Methods and closures
Control structures
Groovy Truth
Ternary and Elvis operators
Spaceship and Elvis operators
The switch statement
Loops
Collections
Ranges
Lists
Maps
Operators
Spread and spread-dot
Null safe dereference
Operator overloading
Summary
5. Groovy Closures
What is a closure?
Closures and collection methods
Closures as method parameters
Method parameters as DSL
Forwarding parameters
Calling closures
The implicit doCall method
Finding a named closure field
Closure parameters
Enforcing zero parameters
Parameters and the doCall method
Passing multiple parameters
Default parameter values
Implementing closures in Java
Curried parameters
Closure return values
The closure scope
The this, owner, and delegate variables
Closure composition
Closure trampoline
Closure memoization
Summary
6. Example DSL – GeeTwitter
Working with the Twitter APIs
Using Twitter4J Java APIs
Tweeting
Direct messages
Searching
Following
Groovy improvements
A Groovier way to find friends
Groovy searching
Removing the boilerplate
Refactoring
Fleshing out GeeTwitter
Improving search
Adding a command-line interface
Adding built-in methods
Summary
7. Power Groovy DSL Features
Named parameters
Named parameters in DSLs
Command chains
Builders
The builder design pattern
Using Groovy builders
MarkupBuilder
Namespaced XML
The GroovyMarkup syntax
GroovyMarkup and HTML
Using program logic with builders
Builders for every occasion
NodeBuilder
Using GPath to navigate a node tree
SwingBuilder
Method pointers
Metaprogramming and the Groovy MOP
Reflection
Groovy reflection shortcuts
Expandos
Categories
Traits
MetaClass
Pretended methods – MetaClass.invokeMethod
Understanding this, delegate, and owner
How builders work
ExpandoMetaClasses
Replacing methods
Adding or overriding static methods
Dynamic method naming
Adding overloaded methods
Adding constructors
Summary
8. AST Transformations
What is an AST
Compiler phases
Local AST transformations
Using ASTBuilder
Build from code
Build from Spec
Traits to the rescue
Global AST transformations
A finite state machine DSL
The state machine pattern
A state machine AST transformation
Handling errors – compile errors
Building the new AST nodes
Testing the state machine DSL
Compiling and packaging an AST transformation
Summary
9. Existing Groovy DSLs
Grails object relational mapping – GORM
Grails quick start
The grails-app directory
Building a GORM model
Using domain classes
Modeling relationships
Associations
One-to-one
Constraints
One-to-many
Many-to-many
Composition
Inheritance
Mapping
Querying
Dynamic finders
GORM as a DSL
Spock as a DSL
Spock
JUnit
Summary
10. Building a Builder
The builder code structure
Closure method calls
The resolve strategy – OWNER_FIRST
Pretended methods
invokeMethod
methodMissing
The closure delegate
BuilderSupport
BuilderSupport hook methods
A database builder
FactoryBuilderSupport
Summary
11. Implementing a Rules DSL
Groovy bindings
Exploiting bindings in DSLs
Closures as built-in methods
Closures as repeatable blocks
Using a specification parameter
Closures as singleton blocks
Using binding properties to form context
Storing and communicating results
Building a rewards DSL
Designing the DSL
BroadbandPlus
Reward types
The reward DSL
Handling events – deferred execution
Convenience methods and shorthand
The offers
The RewardService class
The BroadbandPlus application classes
Testing with Spock
Summary
12. Integrating It All
Groovy as a teaching language
Hiding complexity
A game DSL for kids
A game DSL – goals
Architecture and technology choices
TicTacToe in a DSL
Implementing the AST transform
Building the game engine pattern
Testing the DSL
Class loading issues
Gradle subprojects
Debugging
The game server
Integrating with Spring Boot server
Controller annotations
JSONP
Loading the DSL
Spring Data mapping for MongoDB
The Game UI
Summary
Index
Groovy for Domain-specific Languages Second Edition
Groovy for Domain-specific Languages Second Edition
Copyright © 2015 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2010
Second edition: September 2015
Production reference: 1230915
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-84969-540-4
www.packtpub.com
Credits
Author
Fergal Dearle
Reviewers
David W Millar
Pietro Martinelli
Jason Winnebeck
Commissioning Editor
Erol Staveley
Acquisition Editors
Tushar Gupta
Antony Lowe
Content Development Editor
Adrian Raposo
Technical Editor
Siddhi Rane
Copy Editors
Janbal Dharmaraj
Kevin McGowan
Project Coordinator
Kinjal Bari
Proofreader
Safis Editing
Indexer
Hemangini Bari
Production Coordinator
Shantanu N. Zagade
Cover Work
Shantanu N. Zagade
About the Author
Fergal Dearle is a seasoned software development professional with almost 30 years' experience in software product development across a wide variety of technologies. He is currently the principal consultant with his own software development consulting company, Dearle Technologies Ltd., engaged in design, development, and architecture of new software products for client companies. Recent projects have included the integration of the Telegraph (http://www.telegraph.co.uk) into Apple's new Apple News application for iOS 9 and the reengineering of the G-Cloud Digital Marketplace for the United Kingdom Cabinet Office (https://www.digitalmarketplace.service.gov.uk).
He is a committed mentor in his local CoderDojo in Wexford Town where he teaches Groovy to the young coding ninjas. He has been recently nominated as a CoderDojo Hero for his work.
In the past, Fergal has worked in lead architect and developer roles for Candle Corporation on the OMEGAMON product, which is now part of IBM's Tivoli product suite, and as the development manager for Unix implementations of Lotus 1-2-3. In the early 1990s, Fergal led the team at Glockenspiel that developed CommonView, the first object-oriented UI framework for Microsoft Windows. The team was awarded one of the first ever Jolt Productivity Awards by Dr. Dobbs Journal.
Acknowledgments
Being part of the extended Groovy community has been one of the most fulfilling periods of my professional life. I have had the privilege to work with some of the best and most talented software developers and Groovy programmers around the world, and I have learned a lot from them all. There are so many to mention; first names will have to do: George, Elliot, Adam, Steve, Rob, Glenn, Zsolt, Chris, Tao, Adi, Grezg, Brendan, Alex, Sean, Atilla, Eugen, Alvaro, Jet, Dom, and Tim … to name but a few.
Special thanks must go to Peter Ledbrook for his tireless work running the London Groovy Grails User Group, and to the organizers of GGX and GR8 conferences. Some of the great blogs and conference talks that inspired me to write this book were presented by Guilliame Laforge, Cédric Champeau, Marco Vermeulen, Mr Haki, and Jeff Scott Brown.
Closer to home, I could not have finished this book were it not for the tireless support of my coworker and comentor at CoderDojo, Tony Davidson.
Last, but not least, I want to thank my girls, Caroline, Eabha, Nessa and Sadhbh, who put up with my long absences during the writing, and without whose love and tolerance I would never have completed this book.
About the Reviewers
David W Millar is a veteran software craftsman who holds a degree in computer science from Drexel University. He has had the pleasure of working in a wide variety of environments from small start-ups and research groups to industry giants such as IBM and Comcast. He is an active member of the Philadelphia tech scene and a contributor to the Groovy ecosystem. In his free time, he can be found hacking on open source projects; eagerly following tech trends such as the container revolution, IoT, DevOps, and infrastructure automation; or playing with his cats.
Pietro Martinelli is a software engineer, who has been working in enterprise application development since 2003. In 2002, he received his degree in computer engineering at the University of Brescia with highest honors. His main technical interests are languages development (primarily parsers and code generation tools development), enterprise application design, build and deployment automation, and quality-oriented development methodologies. He's an object orientation and testing bigot who loves teaching and mentoring students and colleagues on software design and testing methodologies. He writes about his technological experiences and his technical vision of the world in his blog, Java Peanuts, http://javapeanuts.blogspot.com.
My wife Cristina and my daughters Irene and Laura beautifully fill every moment of my spare time.
Jason Winnebeck is a full-stack software developer with both frontend and backend development experience, including 15 years of experience with Java technologies and 4 years' experience with Groovy, specifically. He holds a master's degree in computer science from the Rochester Institute of Technology. He is married with two children, and enjoys volleyball and traveling.
www.PacktPub.com
Support files, eBooks, discount offers, and more
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
Support files, eBooks, discount offers, and morehttps://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Free access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access.
Preface
The Java virtual machine runs on everything from the largest mainframe to the smallest microchip and supports every conceivable application. But Java is a complex, and sometimes arcane, language to develop with. Groovy allows us to build targeted single-purpose mini languages, which can run directly on the JVM along with the regular Java code.
This book provides a comprehensive tutorial on designing and developing mini Groovy-based domain-specific languages (DSLs). It is a complete guide to the development of several mini DSLs with a lot of easy-to-understand examples. This book will help you gain all of the skills needed to develop your own Groovy-based DSLs.
Groovy for Domain-specific Languages, Second Edition, guides you from the basics through to the more complex metaprogramming features of Groovy. The focus is on how the Groovy language can be used to construct domain-specific mini languages.
Practical examples are used throughout to demystify these seemingly complex language features and to show how they can be used to create simple and elegant DSLs. The examples include a quick and simple Groovy DSL to interface with Twitter.
The book concludes with a chapter focusing on integrating a Groovy-based DSL in such a way as the scripts can be readily incorporated into your own Java applications. The overall goal of this book is to take developers through the skills and knowledge they need to start building effective Groovy-based DSLs to integrate into their own applications.
What this book covers
Chapter 1, Introduction to DSLs and Groovy, discusses how DSLs can be used in place of general-purpose languages to represent different parts of a system. You will see how adding DSLs to your applications can open up the development process to other stakeholders in the development process. You'll also see how, in extreme cases, the stakeholders themselves can even become co-developers of the system by using DSLs that let them represent their domain expertise in the code.
Chapter 2, Groovy Quick Start, covers the basics of installing Groovy and running simple Groovy scripts.
Chapter 3, Essential Groovy DSLs, covers two essential Groovy-based tools, Gradle and Spock. Gradle is a build, test, and deployment automation tool, which is powered by a Groovy DSL. Spock is a unit testing and specification framework built over JUnit. Both tools are used extensively throughout the book.
Chapter 4, The Groovy Language, covers a whistle-stop tour of the Groovy language. It also touches on most of the significant features of the language as a part of this tour.
Chapter 5, Groovy Closures, covers closures in some depth. It covers all of the important aspects of working with closures. You can explore the various ways to call a closure and the means of passing parameters. You will see how to pass closures as parameters to methods, and how this construct can allow the adding of mini DSL syntax to our code.
Chapter 6, Example DSL – GeeTwitter, focuses on how we can start with an existing Java-based API and evolve it into a simple user-friendly DSL that can be used by almost anybody. You'll learn the importance of removing boilerplate code and how you can structure our DSL in such a way that the boilerplate is invisible to our DSL users.
Chapter 7, Power Groovy DSL Features, covers all of the important features of the Groovy language, and looks in depth at how some of these features can be applied to developing DSLs.
Chapter 8, AST Transformations, covers how to use the Groovy abstract syntax tree (AST) transformations. AST transformations are a mechanism for us to hook into the Groovy compilation process. Here we look at compile time metaprogramming and see how we can use AST transformations to build code on the fly during the compilation process.
Chapter 9, Existing Groovy DSLs, discusses some existing Groovy DSLs that are in current use and are free to download.
Chapter 10, Building a Builder, explains how Groovy provides two useful support classes that make it much simpler to implement our own builders than if we used the MOP. You'll see how to use BuilderSupport and FactoryBuilderSupport to create our own builder classes.
Chapter 11, Implementing a Rules DSL, takes a look at Groovy bindings to see how they can be used in our DSL scripts. By placing closures strategically in the binding, you can emulate named blocks of code. You can also provide built-in methods and other shorthand by including closures and named Boolean values in the binding. These techniques can be used to great effect to write DSL scripts that can be read and understood by stakeholders outside of the programming audience.
Chapter 12, Integrating It All, takes all the knowledge from the previous chapters and builds a fully functioning web application based on a simple Game Engine DSL for Tic Tac Toe.
What you need for this book
It is highly recommended that you download the example code to use while you read the book. You will also need to download and install three key pieces of software, Groovy, Spock, and Gradle. Download and installation instructions for these are included in Chapter 2, Groovy Quick Start, and Chapter 3, Essential Groovy DSLs.
Who this book is for
This book is for any software developers who have an interest in building domain scripting into their applications. No knowledge of Groovy is required, although it will be helpful. This book will not teach Groovy, but will quickly introduce the basic ideas of Groovy. An experienced developer should have no problems with this and will move quickly onto the more involved aspects of creating DSLs with Groovy. No experience of creating a DSL is required.
The book should also be useful for experienced Groovy developers who have so far only used Groovy DSLs, such as Groovy builders, and would like to start building their own Groovy-based DSLs.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: Before you go to the Groovy documentation for MarkupBuilder to look for the book, author, and surname methods in MarkupBuilder, let me save you the effort.
A block of code is set as follows:
1.0?>
Any command-line input or output is written as follows:
Hello, World! Goodbye, World!
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: Click on the button to Create New App, then complete the form to create you app.
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Introduction to DSLs and Groovy
It has been over 10 years since my first contact with the Groovy language. The occasion was an introductory talk about Groovy at JavaOne in the Moscone Centre, San Francisco, by James Strachan, the creator of the Groovy language. Java itself was just 10 years old at that time and Groovy was one of the very first languages other than Java to run on the Java Virtual Machine (JVM).
Just this year, Java celebrated its twentieth birthday. In 2005, there were an estimated 3 million Java developers worldwide. Now, in 2015, Wikipedia estimates it as 11 million. The Groovy language has also taken off. There were an estimated 5 million downloads of Groovy in the last year alone. So what are the benefits of Groovy and why should you consider using it?
The Groovy project site at http://www.groovy-lang.org explains this better than I ever could with six major benefits:
A flat learning curve
Powerful features
Smooth Java integration
Domain-specific languages
A vibrant and rich ecosystem
The scripting and testing glue
In this book, we will cover all the key benefits of the Groovy language. The main focus, however, is on how Groovy supports the development of domain-specific languages through its metaprogramming features.
One of the big benefits of Groovy is how its dynamic features support the development of domain-specific languages (DSLs) or mini languages
, which we can run directly on the JVM alongside your existing Java code. Groovy DSLs integrate seamlessly into the Groovy language itself in such a way that it's not always apparent where the regular Groovy code stops and the DSL starts.
In fact, large parts of almost any Groovy application are written using Groovy-based DSLs. For instance, a new developer starting out with Groovy might assume that the builder code he uses to output some XML is a part of the core Groovy language. But it is, in fact, a mini internal DSL implemented using the Groovy metaprogramming features.
If you are an Android developer, the chances are you may have programmed in Groovy already. Since 2013, the build system in the Android SDK has been a tool called Gradle (http://www.gradle.org). Gradle is a Groovy-based DSL for dependency management and build automation.
Whether you are one of the 11 million existing Java developers, looking to add DSL features to you application, or you are an existing Groovy developer looking to improve your knowledge of DSL writing, metaobject programming or AST transformations, this book is intended for you.
By the end of this book, I hope that you will have the knowledge and the confidence to start building your own DSLs with Groovy, and be able to integrate them into your Java applications. To begin with, in this chapter, we will take some baby steps. This chapter will give you a brief background on DSLs and their usage. We will also dip a toe into the Groovy language, and briefly touch on the features of the language that distinguish it from Java and make it a great tool for developing DSLs on top of the Java platform.
DSL – a new name for an old idea
I've mentioned domain-specific language (DSL) several times now, so what does this really mean? The term DSL
describes a programming language that is dedicated to a specific problem domain. The idea is not new. DSLs have been around for a long time. One of the most exciting features of Unix has always been its mini languages. These include a rich set of typesetting languages (troff, eqn, pic, and so on), shell tools (awk, sed, and so on), and software development tools (make, yacc, and lex).
The Java platform has a multitude of mini DSLs in the form of XML config files for configuration of everything from EJBs to web applications. In many JEE applications, Enterprise Java Beans (EJB) can be configured using an XML configuration file, ejb-jar.xml. While the ejb-jar.xml file is written in the general-purpose language XML, the contents of the file need to conform to a document type definition (DTD) or XML schema, which describes the valid structure of the file.
XML configuration files can be found across a wide range of libraries and frameworks. Spring is configured by using a spring-config.xml file, and Struts with struts-config.xml. In each case, the DTD or schema defines the elements and tags, which are valid for the specific domain, be it EJB, Spring, or Struts. So, ejb-jar.xml can be considered a mini DSL for configuring EJB, spring-config.xml is a mini DSL for configuring Spring beans, and so on.
In essence, DSL is a fancy name for something that we use every day of our professional programming lives. There are not many applications that can be fully written in a single general-purpose language. As such, we are the everyday consumers of many different DSLs, each of which is specific to a particular purpose.
A typical day's work could involve working with Java code for program logic, CSS for styling a web page, JavaScript for providing some dynamic web content, and Ant, Maven, or Gradle to build the scripts that tie it all together. We are well used to consuming DSLs, but seldom consider producing new DSLs to implement our applications—which we should.
The evolution of programming languages
My own background is probably typical of many of my generation of old-school programmers. Back in 1986, I was a young software engineer fresh out of college. During my school and college years, I studied many different programming languages. I was fortunate in high school to have had a visionary Math teacher who taught us to program in BASIC, so I cut my teeth programming as early as 1974. Through various college courses, I came to know about Pascal, C, Fortran, Lisp, Assembler, and COBOL.
My school, college, and early professional career all reinforced a belief that programming languages were for the exclusive use of us programmers. We liked nothing better than spending hours locked away in dark rooms writing reams of arcane and impenetrable code. The more arcane and impenetrable the better! The hacker spirit prevailed, and annual competitions such as the International Obfuscated C Code Contest (IOCCC) were born.
Note
The IOCCC runs to this day. The point of the contest is to write valid but impenetrable C code that works. Check out http://www.ioccc.org to see how not to write code.
General-purpose languages
All of the teaching in college in those days revolved around the general-purpose languages. I recall sitting in class and being taught about the two
types of programming language: machine language, and high-level languages. Both were types of general-purpose languages, in which you could build any type of application, but each language had its own strengths and weaknesses. The notion of a DSL was not yet considered as part of the teaching program. Nor was the idea that anyone other than a cadre of trained professional programmers (hackers) would ever write programs for computers. These days, the word hacker
has bad connotations of being synonymous with virus writers and the likes. In those days, a good hack
was an elegant programming solution to a hard problem and being called a hacker by one's peers was a badge of pride for most programmers.
The high-level programming language you used defined what type of an application programmer you were. COBOL was for business application programming, Fortran was for scientific programmers, and C was for hackers building Unix and PC software. Although COBOL and Fortran were designed to be used in a particular business domain, they were still considered general-purpose languages. You could still write a scientific application in COBOL or a business application in Fortran if you wanted to. However, you were unlikely to try any low-level device driver development in COBOL.
Although it was possible to build entire applications in assembly language (and many people did), high-level languages, such as C, BASIC, and COBOL, were much better suited to this task. The first version of the world-beating spreadsheet Lotus 1-2-3 was written entirely in 8086 assembly language, and ironically, it was the rewrite of this into the supposed high-level language C that nearly broke the company in the late 1980's.
Languages such as C and C++ provide the low-level functionality in a high-level language, which enabled them to be used across a much greater range of domains, including those where assembly was utilized before. These days, Java, C# and C++ compete with each other like the Swiss Army knives of general-purpose languages. There are almost no application domains to which these languages have not been applied, from space exploration, through to enterprise business systems, and mobile phones.
Spreadsheets and 4GLs
Programs such as Lotus 1-2-3 and its precursor VisiCalc revolutionized people's view of who would program computers. A whole generation of accountants, financial analysts, scientists, and engineers came to realize that they can develop sophisticated turnkey solutions for themselves, armed only with a spreadsheet and a little knowledge of macros. Spreadsheet macros are probably one of the first DSLs to find their way out of the cloisters of the IT community and into the hands of the general business user.
Around this time, there was also much media attention paid to the new 4GL (fourth-generation language) systems. 4GLs were touted as being hugely more efficient for developing applications than traditional high-level languages, which then became known as third-generation language (3GL). From the hype in the media at the time, you would be forgiven for thinking that the age of the professional programmer was coming to an end and that an ordinary business user could use a 4GL to develop their own business applications. I viewed this claim with a degree of healthy skepticism—how could a non-programmer build software?
Like DSLs, 4GLs were, generally speaking, targeted at particular problem spaces, and tended to excel at providing solutions in those narrow target markets. The sophistication