#52WeeksOfCode Week 33 – Groovy

Week: 33

Language: Groovy

IDE(s): Eclipse with Groovy plugins/Groovy Shell


History (official):

(From the Groovy Home Page)


  • is an agile and dynamic language for the Java Virtual Machine
  • builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
  • makes modern programming features available to Java developers with almost-zero learning curve
  • provides the ability to statically type check and statically compile your code for robustness and performance
  • supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
  • makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
  • increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
  • simplifies testing by supporting unit testing and mocking out-of-the-box
  • seamlessly integrates with all existing Java classes and libraries
  • compiles straight to Java bytecode so you can use it anywhere you can use Java

History (real):

Since this is the third or fourth language I’ve encountered that produces code for the Java Virtual Machine (JVM), I decided to search for “java is dead”:

Searching for "java is dead"

Searching for “java is dead”

Apparently the Java Death Watch has been around since 1996. This raises the bigger question “When is a programming language actually dead?”.

According to the Linguistics Society of America, a human language is considered dead when there are no more native speakers.

Computer languages are trickier. Is a programming language dead if no computers are left to run it or is it when there are no programmers who still use it? If we decide to adapt the definition of ‘dead’ from human language (no more native speakers), we need to ask “What is the computer equivalent of a ‘native speaker’?” This puts us back to square one so that’s no help. We should probably just see how good of a case we can make for either choice.

  • Computers as ‘Native Speakers’ – Computers actually ‘speak’ machine language, 1’s and 0’s. This is very hardware and operating system specific, like different dialects of English (same characters different syntaxes). Every programming language command has to eventually end up translated (directly or indirectly) into machine language. For modern coding languages, the underlying hardware doesn’t make that much of a difference. This argument is a non-starter.
  • Programmers as ‘Native Speakers’ – This makes more sense to me. The code is still around and still runs but nobody is writing new programs with the language, then the  language is dead. Or, to use the phrase of art, in ‘maintenance mode’. (see COBOL)

Groovy is another scripting language that produces code that can run on the Java Virtual Machine (JVM). Others include JRuby, Scala, Vala, Fantom and Jython. In effect, they are all dialects of Java, since you can mix Java code with any or all of them and they run just fine.

So is Java dead? Let’s just say that the rumors have been highly exaggerated.


Groovy is cross-platform and there are a number of ways to install it.

  • Download the binary package and unzip it wherever you want
  • Install the Groovy plugin in either Eclipse or NetBeans
  • If you’re on a UNIX-based machine (like Mac OS X or Linux), you can install the GVM (Groovy enVironment Manager).

I already had Eclipse after installing the Scala IDE (i.e. Eclipse with the Scala plugin) so I went with the  Groovy plugins for Eclipse. It was pretty straightforward.

Once I plugged in the location of the Groovy software, I got a nice selection of add-ons. I just selected what I needed:

Minimum Groovy plugin install

Minimum Groovy plugin install

A quick download, install and restart of Eclipse and I was off to the races. When I came back, there were additional choices in my New menu:

Starting a new Groovy Project

Starting a new Groovy Project

I selected Groovy Project, took the defaults and (like the Scala project) opened up with no source code, just project scaffolding. I had to add a Groovy class to the project to get some source I could work with.

There are three ways to run your Groovy code:

  • Run as Java Application – This compiles Groovy into Java bytecode and runs it on the JVM
  • Run as Groovy Script – Don’t compile, just run the script with the Groovy interpreter.
  • Run as Groovy Console – This is the most interesting option to me. When you choose this, your code opens up into a separate window:
Running in the Groovy Console

Running in the Groovy Console

This gives you an interactive console where you can do some quick experimentation with your code. This is a good choice for rapid development, letting you test out chunks of code before rolling them back into your main project.

Since I’m also comfortable with the command line, I installed the GVM for good measure. It’s pretty easy and gives me access to a command-line Groovy interpreter. Like the Groovy Console, this lets me test out chunks of code for rapid development. Once it’s installed you just call it with the command groovysh:

Starting up Groovy Shell

Starting up Groovy Shell

A sample Hello World in groovysh:

Running Hello World in Groovy Shell

Running Hello World in Groovy Shell

This is not the preferred option for Groovy newbies. I would recommend that you stick with Eclipse or Netbeans.

One of the things that interested me about Groovy was the claim that you can drop Java code into a Groovy script and it will just work as Java and Groovy share virtually the same syntax.

I tested this out with Eclipse. I created a quick Java version of “Hello World!”, copied and pasted the code into my Groovy project (commenting out the original code) and it worked!

Java code with Groovy - it works!

Java code with Groovy – it works!

This gives Groovy an additional advantage, as Java programmers will have a much less steep learning curve when the transition to Groovy.



#52WeeksOfCode Week 29 – Clojure

Week: 29

Language: Clojure

IDE(s): NightCode

History (official):

(From the official Clojure home page)

Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language – it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure’s combination of facilities elegant, powerful, practical and fun to use.”


History (real):

That was the equivalent of a marketing release for Clojure. In other words, it’s targeted at the ‘suits’. If you want the sales page for the technical crowd, see the Rationale page.

I have no personal animus against Clojure. Today was the first time I had heard of it. But I have to say that my first thought was “What? You mean I can at last combine the terse, unreadable code of Lisp with the performance hit of running Java? Sign me up!”

Of course, the true story is more complex.

One of the strengths of the Java platform is the Java Virtual Machine (JVM). A Java program compiles to bytecode which runs on the JVM. The JVM gives Jave its portability between operating systems. Microsoft’s .NET language followed suit with the CLR (Common Language Runtime).

Another advantage of the JVM, however, is that Java bytecode is an open, documented standard. That means that you can use any programming language you want to write Java applications, as long as you can compile your language to produce bytecode. Examples include Jython and JRuby that let programmers write Java programs in Python and Ruby, respectively.

Clojure lets programmers write in Lisp and produce code that can easily integrate with Java and code that uses Microsoft’s .NET framework. It can also connect to JavaScript libraries like Node.js for Web applications.

This is a cool idea. Scripting languages do make for faster prototyping and development and bytecode compilation does improve performance a bit (but not as much as going all the way down to machine code).

But why Lisp for scripting? Let’s ask the creator of Clojure, Rich Hickey. From the Clojure Rationale page:

Why did I write yet another programming language? Basically because I wanted:


  • A Lisp
  • for Functional Programming
  • symbiotic with an established Platform
  • designed for Concurrency


I think the third feature is the important one. We already have multiple dialects of Lisp. Erlang is a functional programming language that supports concurrency. But neither of these can integrate so easily with existing code as Clojure.

I think that if I had a complaint, it would be that the scripting language was based on Lisp. But that’s my own personal discomfort and unfamiliarity with functional programming and not meant to diminish Hickey’s accomplishment in any way.


So how do I get started coding in Clojure? After a bit of research, I found that writing the code was easy enough but a real Clojure project involves keeping quite a few metaphorical plates spinning. Managing all of the files, code dependencies and project details can get hairy very quickly, particularly if you work from the command, which is the bare-bones Clojure install default.

There is an existing tool, make, which can handle code projects but it’s finicky to configure. Java has similar project management issues which are handled by a tool called ant. Fortunately some contributors to Clojure created an automation tool named leiningen. It works so well that it’s become the default tool for working with Clojure projects.

I didn’t feel like working from the command line (again) so I searched for a nice IDE for my first Clojure project. There are Clojure plug-ins for popular Java IDEs like Eclipse, NetBeans and Intellij but I wanted a program that was built specifically for Clojure.

Enter NightCode. Not only was it written for Clojure projects, but it was written in Clojure. I felt this showed admirable brand loyalty so I grabbed a copy. The interface is pretty bare-bones:

NightCode on first startup

NightCode on first startup

I only have three options: Create a new project, import an existing project or run code interactively in the little interpreter window on the lower left. This is a pretty neat feature because you can jump out of your current project, quickly test out some scrap of code to make sure it works the way you think it does and then paste it back into your main source file without leaving the IDE. Very nice:

NightCode interactive shell

NightCode interactive shell

I created a new project and after giving my project a name was presented with a list of project templates:

NightCode template selection

NightCode template selection

I like templates. They let me get on with my life.

I picked Console and selected Create Project.  In a few moments my first project was ready to code:

A simple console application project

A simple console application project

I have a few more options now. One thing I noticed were the options Run, Run with REPL, Build and Test. Since Clojure is a scripting language, it’s possible to run code without actually creating an application. Run with REPL runs your code interactively which is useful for debugging. Test checks your code for logic and syntax errors. Build, of course, creates the standalone software application. It’s still a very sparse interface, but it looks like you could do some non-trivial projects in this IDE. Not bad for free software.

On to my trivial project. The console project template is a standard “Hello World” so I use it to take both Clojure and NightCode for a spin.

Here’s the code, in case you’re curious:

Hello World in Clojure

“Hello World!” in Clojure

I’d like to test my code before running it so Test automatically inserts test code into my program, compiles and runs it:

Automatic code testing

Automatic code testing

Selecting Run gives me this:

Running my code

Running my code

Run with REPL loads the code and drops me into an interactive shell:

Running interactively with REPL

Running interactively with REPL

Now I’m ready to create my standalone application with Build:

Building a standalone application

Building a standalone application

Clojure is a unique, versatile language and NightCode gives me enough tools to handle non-trivial projects with confidence.

#52WeeksOfCode Week 12 – Java ME

Week: 12

Language: Java ME

IDE(s): Java ME SDK32


The question for this week is why would anyone develop in Java ME? Java ME (Micro Edition) is designed for devices with limited memory, display and power capacity such as cell phones, PDAs, MP3 players, set-top boxes and Blu-Ray disc players. The most popular such devices are cell phones but they don’t support it. Android supports ‘real’ Java with their own framework. Apps for Apple’s iPhone and iPod Touch are built with Objective C and Windows phones don’t support Java in any form. In fact, according to NetMarketShare Java ME is in 3rd place in mobile operating systems with a 4.44% market share as of February 2014.

Not so fast. One place where Java ME thrives is in feature phones, the precursors to today’s smartphones. While smartphone shipments worldwide finally outpaced those of feature phones in 2013, about 42 percent of cell phone sales (839 million) were feature phones. In fact, if you’re living outside of the US and living on $10 a day, chances are pretty good that you don’t have an iPhone, Android or Windows phone. Facebook’s recent acquisition of WhatsApp was in part because of the app’s worldwide reach. Basically, it runs on everything, including Java ME devices. The market of the developed world is relatively small compared to the 3 billion other people on the planet who don’t have smartphones.

Now, if I were a developer (and as the official World’s Slowest Programmer(™), clearly I’m not), I wouldn’t readily dismiss this potential market.


As always, the first step is to get the software. The first thing you notice is that the latest version (3.4) is only available for Windows, so if you want to develop on Mac OS X, you have to use an earlier version (3.0). If you use Linux, however, you’re out of luck. You’ll have to use version 2.5.2 but you won’t have access to the emulator so you can’t test your software.

I have access to both Windows and Linux but since (as I’ve pointed out) I Am Not A Developer, I set up the IDE on my MacBook. Oracle does not make it easy to find any non-Windows version of the IDE. Even then, you have to register for a (free) user account on Oracle’s website. However, eventually I managed it.JavaME_IDE.png

If you prefer, you can also use Eclipse Pulsar and the default download comes with plug-ins for NetBeans. If you want to set up a new project, you can either import an existing wireless project or create a new one. But the demos give you plenty of code to play with and tutorials are readily available.

I set up a new project, taking the defaults. When I built and ran it, the software emulator automatically started and ran the app:HelloJ2MEApp.png

It’s similar to the Android SDK, except our graphic comes up as a feature phone (appropriately enough).