Time for tea?

Another day, another Java menace: Ceylon has landed

Lucy Carey

Red Hat’s new JVM language Ceylon is fully brewed and ready to pour. We speak to creator Gavin King about the path to 1.0.

This week’s Devoxx conference in Antwerp saw the
launch of two box fresh languages: Google’s
Dart SDK 1.0
, and Red Hat’s Ceylon 1.0. From the start, many
have tipped Ceylon as a clear threat to Java’s platform (the clue
is in the name). But is it really Red Hat’s intention? Creator
Gavin King has been adamant from the earliest development stages
that the intention has always been to create something that can run
alongside Java – but designed as a language and SDK for business
computing that learns and builds on Java’s successes and failures.
We caught up with King for the full scoop on this week’s launch,
the work behind it, and what’s brewing next at Red Hat

JAX: First of all, congratulations on the
launch of Ceylon at Devoxx this week!

King: Thank you! There was certainly
a lot of buzz at the conference – that’s really nice for us.

What was the impetus behind the development of

Obviously, at the time when the language was first
conceived, I was doing a lot of work with the JCP on the Java EE
side of the platform, and had been working for several years with
certifications like EJB, and CDI, and some of the other
technologies on the platform. And, you know, especially during a
period when I was working on CDI, at some stage, I got to the point
where the incremental improvements we were making to the
programming model and to the experience of our users was – how can
I say – a sequence of diminishing returns.

The problems that I was becoming more interested in, and
which were really frustrating me more, I suppose, were things that
were more at the language level. The limitations which I was
bumping up against were things which I couldn’t solve at the
library framework level.

So it started, I guess, as a set of ideas for how could we
enable a better programming model – and, especially a better
programming model for people who were building frameworks and
libraries and more generic code. Obviously, since that time, the
concept has evolved in different ways, but I guess that’s still
very much part of it.

What were the biggest problems that you were
looking to solve with this project?

Well, one of the biggest limiting things was the fact
that, as soon as you wanted to define a user interface or some kind
of structured data set configuration, or anything like that, or
build, or anything like that, in the Java world, you had to leave
the language of Java and go and use some other language, say XML.
 And it was even worse if you were writing a user end code for
the web browser, because the whole, ‘write once, run anywhere’
thing kind of failed immediately.

Java has been enormously successful, wonderful,
fantastic language – but, the initial vision kind of failed on
arrival. And so, as soon as you wanted to bridge the gap to a web
based client, you found yourself having to leave the Java language
and write something in JavaScript or something like that. Java
applications today are composed of several languages cooperating
together, and that’s not necessarily a bad thing, but the problem
is that you lose static typing, you lose the tooling support.

Java developers like me are amazingly attached to
having great tooling, and having tools that help us maintain and
refactor and alter our code. As soon as we leave Java and start
having to work with XML or JavaScript, we really keenly feel that
loss of support from the tooling level.

Going back to the feedback that you’ve had
this week – a lot of commentators are calling Ceylon a “Java
killer.” This is something that you’ve denied in the past, but can
you see why people think this?

Well, I mean, Ceylon certainly competes with Java as a
language, obviously, and we go even further than that. Nor merely a
language, but also a set of platform libraries. And so…it’s a
competitor in some sense, but I mean, it would almost be absurdly
arrogant of me to say, “we’re going to go up and compete against
Java”, which is an amazing ecosystem of multiple technologies that
work together.

You know, I prefer to think of it as being part of the
Java ecosystem, right? Sure, we go beyond that Java ecosystem in
terms of operating also in the JavaScript environment – but you
know, we think of ourselves as part of the JVM ecosystem, along
with other languages.

For us, interoperability with other languages,
beginning with Java and JavaScript – but I hope to extend that to
interoperability with JRuby, and with Groovy – we want to be part
of that world, and work together with other technologies. I expect
that, realistically speaking, any Ceylon application is going, in
the near future, to be composed of a mixture of Java and Ceylon and
JavaScript, quite frankly.

Although you’re saying that it’s a kind of
complimentary rival, why did you decide to name it

Well, Ceylon started off as the name of a secret
project inside RedHat. It’s a play on Java, and Java is an island
in Indonesia which was a source of coffee during colonial times,
and Ceylon was another island in the Indian ocean that was a source
of tea. So it comes from that – it was a play on that.

It was never meant to be the name of a programming
language, but it kind of stuck. When I proposed to change it, and
said, we’ll come up with a real name, my colleagues turned round
and said, “no, no, no! We like that one! Don’t change it,”

Naming issues aside, what was the most
challenging aspect of developing Ceylon?

I mean, obviously, it’s been four years of extremely
hard work and it’s an enormous undertaking and software engineering
challenge. There have been many hard parts of it.

Designing a type system for a statically typed
language, you know, if you want a state of the art statically typed
language these days, the conceptual work that goes into the design
of a type system – really a lot of quite technical and deep
thinking needs to go into that, and that occurred over several

In terms of actual development and writing code, by
far the hardest part of what we wrote was the part of our compiler
which takes a model of the Ceylon code and turns it into an
abstraction for Java, that Javac can take off and generate code for
the JVM with, that transformation, that mapping between the Ceylon
language, and the model of the JVM users. It was definitely the
most challenging part, and we’re immensely relieved to have finally
got it done. That was really the thing that took two years to

So now the hardcore tooling is done, what are
your plans for future releases?

The Ceylon 1.1 release will be all about performance
enhancement. We wanted to get a working release of the language out
as soon as possible, and we we didn’t have time to concentrate on
some performance related issues. So the next release, which we plan
for about three or four months in the future, so early next year,
will be about performance optimisation as opposed to the resulting
code that we generate, and also to our compiler, especially build
performance within our IDE.

That’s something that’s very important to developers
when they’re writing and building code within the IDE – that it be
snappy and fast, and we have work to do there.

Secondly, the shift of emphasis from development as a
language into development of the libraries and frameworks that
people are going to use to build applications with. Obviously we
have some things there, some basic things, but now there’s going to
be a whole load more of work going on there. Already much of our
SDK has been built by external RedHat community contributors,
who’ve popped up and been really interested in one particular
problem, say the build system. And there will be more of that, and
there’s going to more investment from Red Hat in that stuff, and
naturally that’s going to involve lots of people from outside the
Ceylon team.

Ceylon does look a lot like Java – when
compared to other languages on the JVM, what do you think makes it
stand out?

I guess at this level of conversation, there’s three
things I always point to. First of all, most of the languages for
the JVM are dynamically typed, or most of the popular ones are, so
there’s the fact that it’s a very statically typed language, very
type safe, more than even other statically typed languages.

Secondly, Ceylon has built in modularity, which is
something that Java has been promising for a long time, but the
latest news from Devoxx is that essentially, the plan to provide
modularity to users of Java, to a Java application, has been
abandoned and that, if we’re understanding correctly, the current
modularity of the Java platform will focus solely upon the Java SDK
itself. We had been expecting originally Java 8 to provide
modularity at a platform level, and that hasn’t happened, nor does
it look like it’s going to happen anymore. Ceylon offers at this
point, uniquely, modularity based in that language level, pooling
them into the IDE and the runtime.

Making use of modules and so on is so much easier than
any of the other options you have available to you. As a result of
that, if you were to set up a Java application that used Maven and
OSGI and Eclipse together, if you were to try to do that, it would
take you a week of lost productivity to make that work. Whereas
with Ceylon, you get it for free.

Aside from that, we have a really special type system.
It’s simple, but very expressive and powerful, and we think people
are really going to love it.

Finally, going forward, do you think that
going forward, Red Hat will start coding more in

The first step for us will be to bring some of our
pieces that we have in the JBoss ecosystem that we delivered as
pieces of the application server, and repackage them, and make them
modular, and make those modules for the Ceylon platform.

At the same time as that, we’re taking Ceylon, and
we’re enabling deployment to Openshift. Once we have then the
capabilities that we have in JBoss, also for Ceylon, then it’s
going to be a lot more interesting – what can we do in Ceylon that
we can currently do in JBoss?

People often ask me, does RedHat use Ceylon to build
internal projects, and I’m always kind of like, I don’t quite
understand, we don’t have internal projects, we’re a product

Image by Christian Cable

comments powered by Disqus