Four months after the last major release, and exactly one month after the 1.2.1 update, Ceylon 1.2.2 is a new maintenance release, with over 70 issues closed, including new features, improvements and bug fixes such as:

• you can now use java.lang.Iterable and Java arrays in for statements and comprehensions,
• the [] lookup operator works on Java lists, maps, and arrays,
• the in operator works on java.util.Collection and, last but not least,
• a new ceylon bootstrap command to make it really easy to distribute code to people that don't have Ceylon installed.

Note that for the JVM backend, this release is backwards-compatible with the previous releases (1.2.0 and 1.2.1), which means you can use modules compiled with 1.2.0 on a 1.2.2 distribution out of the box. This is not as easy the other way around, if you want to run modules compiled for 1.2.2 on a 1.2.0 distribution, which is why we recommend you upgrade to 1.2.2.

Sadly, on the JavaScript backend, we had to break binary compatibility to fix serious interoperation issues, and so modules compiled for 1.2.2 and 1.2.0 are not compatible. Versions 1.2.1 and 1.2.2 are binary compatible but can still give problems when used together. We recommend you upgrade your distribution to 1.2.2 and recompile your modules.

About Ceylon

Ceylon is a modern, modular, statically typed programming language for the Java and JavaScript virtual machines. The language features a flexible and very readable syntax, a unique and uncommonly elegant static type system, a powerful module architecture, and excellent tooling, including an awesome Eclipse-based IDE.

Ceylon enables the development of cross-platform modules that execute portably in both virtual machine environments. Alternatively, a Ceylon module may target one or the other platform, in which case it may interoperate with native code written for that platform.

In the box

This release includes:

• a complete language specification that defines the syntax and semantics of Ceylon in language accessible to the professional developer,
• a command line toolset including compilers for Java and JavaScript, a documentation compiler, a test runner, a WAR archive packager, and support for executing modular programs on the JVM and Node.js,
• a powerful module architecture for code organization, dependency management, and module isolation at runtime,
• the language module, our minimal, cross-platform foundation of the Ceylon SDK, and
• a full-featured Eclipse-based integrated development environment.

Language

Ceylon is a highly understandable object-oriented language with static typing. The language features:

• an emphasis upon readability and a strong bias toward omission or elimination of potentially-harmful or potentially-ambiguous constructs and toward highly disciplined use of static types,
• an extremely powerful and uncommonly elegant type system combining subtype and parametric polymorphism with:
  • first-class union and intersection types,
  • both declaration-site and use-site variance, and
  • the use of principal types for local type inference and flow-sensitive typing,
• a unique treatment of function and tuple types, enabling powerful abstractions, along with the most elegant approach to null of any modern language,
• first-class constructs for defining modules and dependencies between modules,
• a very flexible syntax including comprehensions and support for expressing tree-like structures,
• fully-reified generic types, on both the JVM and JavaScript virtual machines, and a unique typesafe metamodel.

More information about these language features may be found in the feature list and quick introduction.

IDE

Ceylon IDE now features the following improvement, along with bugfixes:

• support for the ceylon bootstrap command

SDK

The platform modules, recompiled for 1.2.2, are available in the shared community repository, Ceylon Herd.

This release introduces a single new platform module:

• ceylon.buffer is a cross-platform module for converting between text and binary forms of data.

Along with some enhancements to existing modules:

• ceylon.file now has functions for creating temporary files and directories,
• ceylon.net now has support for template handlers,
• ceylon.html was rewritten according to HTML5 specification and with support for lazy evaluation.

Web IDE

You can try Ceylon using the Web IDE, featuring syntax highlighting, interactive error reporting, autocompletion, online documentation, and persistence and code sharing via Gist.

The Web IDE serves a dual purpose as a standard example demonstrating the use of Ceylon for web application development and deployment to the OpenShift cloud platform.

Community

The Ceylon community site, http://ceylon-lang.org, includes documentation, and information about getting involved.

Source code

The source code for Ceylon, its specification, and its website, is freely available from GitHub.

Information about Ceylon's open source licenses is available here.

Issues

Bugs and suggestions may be reported in GitHub's issue tracker.

Migrating from Ceylon 1.2.0

Migration from Ceylon 1.2.0 is easy. To recompile a module for 1.2.2:

• First ensure that its dependencies have also been recompiled.
• If it imports a Ceylon SDK platform module, upgrade the version number specified by the module import statement from "1.2.0" to "1.2.2" .
• If it was compiled against Ceylon 1.2.0 you should still be able to use it in 1.2.2 for the JVM backend, as it is backwards-compatible. Sadly, this is not the case for the JavaScript backend, and so you will need to recompile your modules with 1.2.2.

Acknowledgement

As always, we're deeply grateful to the community volunteers who contributed a substantial part of the current Ceylon codebase, working in their own spare time. The following people have contributed to Ceylon:

Gavin King, Stéphane Épardaud, Tako Schotanus, Tom Bentley, David Festal, Enrique Zamudio, Bastien Jansen, Emmanuel Bernard, Aleš Justin, Tomáš Hradec, James Cobb, Ross Tate, Max Rydahl Andersen, Mladen Turk, Lucas Werkmeister, Roland Tepp, Diego Coronel, Matej Lazar, John Vasileff, Toby Crawley, Julien Viet, Loic Rouchon, Stephane Gallès, Ivo Kasiuk, Corbin Uselton, Paco Soberón, Michael Musgrove, Daniel Rochetti, Henning Burdack, Luke deGruchy, Rohit Mohan, Griffin DeJohn, Casey Dahlin, Gilles Duboscq, Tomasz Krakowiak, Alexander Altman, Alexander Zolotko, Alex Szczuczko, Andrés G. Aragoneses, Anh Nhan Nguyen, Brice Dutheil, Carlos Augusto Mar, Charles Gould, Chris Gregory, klinger, Martin Voelkle, Mr. Arkansas, Paŭlo Ebermann, Vorlent, Akber Choudhry, Renato Athaydes, Flavio Oliveri, Michael Brackx, Brent Douglas, Lukas Eder, Markus Rydh, Julien Ponge, Pete Muir, Nicolas Leroux, Brett Cannon, Geoffrey De Smet, Guillaume Lours, Gunnar Morling, Jeff Parsons, Jesse Sightler, Oleg Kulikov, Raimund Klein, Sergej Koščejev, Chris Marshall, Simon Thum, Maia Kozheva, Shelby, Aslak Knutsen, Fabien Meurisse, Sjur Bakka, Xavier Coulon, Ari Kast, Dan Allen, Deniz Türkoglu, F. Meurisse, Jean-Charles Roger, Johannes Lehmann, allentc, Nikolay Tsankov, Chris Horne, Gabriel Mirea, Georg Ragaller, Harald Wellmann, Oliver Gondža, Stephen Crawley, Byron Clark, Francisco Reverbel, Jonas Berlin, Luke Hutchison, Nikita Ostroumov, Santiago Rodriguez, Sean Flanigan.

Over the last year and a half it has happened quite frequently that users on our mailing lists or Gitter channels asked: "What is this OBR you people keep talking about?". It was something that would most often be mentioned when we were frustrated with the current project setup making things more difficult than necessary.

How it all started

To understand what the OBR really is you first need to know how our project was organized all these years. Ceylon started out with nothing but the parser and the code that checks and models our unique typesystem, we call it the "typechecker". When we started working on the compilers new modules got added, first for the Java Virtual Machine, later for JavaScript. Then we added a module that handles downloading and caching of external modules retrieved from the Herd. This went on to the point that we wound up with 9 separate but very interdependent projects.

The problem

Now of course modularization is a good software engineering practise so there was no problem there. The problem was with the way we had created multiple Git repositories for each of the projects. We started noticing that for certain types of cross-module issues we often had to make changes to multiple repositories at a time. And when you do that, let's say you change 6 repositories for a single bug report or for a single new feature, you lose cohesion. The changes are all separate and you lose sight of the fact that they belong together. So if you need to go back in time looking for a specific problem and when it was introduced and by which code commit it suddenly becomes very hard to synchronize all the repositories in such a way that you get a working system. The famous git bisect becomes impossible to use.

It also caused minor problems when managing issues on GitHub because users, not knowing, would often open issues on the wrong project which meant manually copying the issue from one project to another (and sometimes even we didn't know where to put an issue and it would get moved several times).

Looking for a solution

So at a certain moment it became obvious that our project setup was working against us, that its structure made certain operations way too hard. A single repository on the other hand wouldn't have those problems. A single big repository, the only one for the entire distribution. So we started calling it the "One Big Repository", quickly shortened to "OBR".

But there were doubts that a single repository would become too big and unwieldy. And how would we go from 9 repositories to just 1? Are there tools to do that? And what about our GitHub issues?

Instead we first looked at tools like git submodule and git subtree which would allow us to keep our current projects but still treat them as a one. But after researching it for a while we came to the conclusion that although it might work it does make things more complex for the developer. And given the fact that most of us aren't Git experts and sometimes have trouble enough with it as it is we decided that the added complexity would not work in our favor. Besides the problem with the GitHub issues being separate would still remain.

The execution

One Big Repository it would be then, merging all 9 Ceylon distribution repositories into a single one. But how? No ready-made tools seemed to exist, just fragments of scripts and examples of complex Git commands. And for the GitHub issues we could only rely on their remote API.

I will spare you all the nitty gritty details on the many dozens of practise merges we did to get to a point where we were happy enough with the result but finally, last monday on November 16th, we made public the new OBR, the One Big Repository!

How to use it

Setting up a Ceylon environment for development used to be a big hassle. So much in fact that we created some pretty complex build scripts to do that all for you. So fortunately as a contributor you'd never notice, you'd just type ant setup and everything would be done for you.

But now things have become still easier, for you as a potential contributor the only that is needed is:

$ git clone https://github.com/ceylon/ceylon
$ cd ceylon
$ ant clean dist

For a more thorough explanation on how to set up a development environment and how to go from there to submitting your first contribution please visit Contributing to the compiler backend