Today, we're proud to announce the release of Ceylon M1 "Newton". This is the first official release of the Ceylon command line compiler, documentation compiler, language module, and runtime, and a major step down the roadmap toward Ceylon 1.0.

You can get it here:

http://ceylon-lang.org/download

We plan a compatible M1 release of Ceylon IDE later this week.

Language features

In terms of the language itself, M1 has essentially all the features of Java except enumerated types, user-defined annotations, and reflection. It even incorporates a number of improvements over Java, including:

• JVM-level primitive types are ordinary classes in Ceylon
• type inference and type argument inference based on analysis of principal types
• streamlined class definitions via elimination of getters, setters, and constructors
• optional parameters with default values
• named arguments and the "object builder" syntax
• intersection types, union types, and the bottom type
• static typing of the null value and empty sequences
• declaration-site covariance and contravariance instead of wildcard types
• more elegant syntax for type constraints
• top-level function and value declarations instead of static members
• nested functions
• richer set of operators
• more elegant syntax for annotations
• immutability by default

Support for the following language features is not yet available:

• first-class and higher-order functions
• comprehensions
• algebraic types, enumerated types, and switch/case
• mixin inheritance
• member class refinement
• reified generics
• user-defined annotations and the type safe metamodel

Furthermore, numeric operators are not currently optimized by the compiler, so numeric code is expected to perform poorly.

This page provides a quick introduction to the language. The draft language specification is the complete definition.

Modularity and runtime

Ceylon modules may be executed on any standard JVM. The toolset and runtime for Ceylon is based around .car module archives and module repositories. The runtime supports a modular, peer-to-peer class loading architecture, with full support for module versioning and multiple repositories.

This release of Ceylon includes support for local module repositories. Support for remote repositories and the shared community repository modules.ceylon-lang.org will be available in the next release.

Chapter 7 of the language specification contains much more information about the Ceylon module system and command line tools.

SDK

At this time, the only module available is the language module ceylon.language, included in the distribution.

Java interoperability

There are a number of issues that currently affect interoperability with Java. These issues are a top priority for the next release.

Source code

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

https://github.com/ceylon

Issues

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

Community

The Ceylon community site includes documentation, the current draft of the language specification, the roadmap and information about getting involved.

http://ceylon-lang.org

Acknowledgement

We're deeply indebted 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 this release:

Stephane Epardaud, Tako Schotanus, Gary Benson, Emmanuel Bernard, Andrew Haley, Tom Bentley, Ales Justin, David Festal, Flavio Oliveri, Sergej Koshchejev, Max Rydahl Andersen, Mladen Turk, James Cobb, Ben Keating, Michael Brackx, Ross Tate, Ivo Kasiuk, Gertjan Assies, Nicolas Leroux, Julien Viet

A Feedback Request is our new way of asking for input from the community on design issues that we're uncertain about. I created the first two feeback requests over the weekend:

1. Syntax for inline functions and objects
2. Alternate visibility model

Please join in the discussions! The decisions we make on these issues will be incorporated into the Milestone 2 release.

Today, we're proud to announce a dedicated Ceylon community, ceylon-lang.org. Simultaneously, we're opening up access to our git repositories and even providing a special pre-release build of the Ceylon IDE, only for the truly adventurous.

We're not yet quite ready to release Milestone 1, due to a number of unsolved bugs and integration issues. But we're working really hard to get these sorted out!

I'm taking this opportunity to thank Red Hat's James Cobb for the web design, Emmanuel Bernard for setting up the infrastructure behind this site, and Tom Bentley for helping with much of the content. And, while I'm mentioning people's names, I would also like to thank new hires Stef Épardaud and Tako Schotanus for all the work they did getting the compiler up and running as volunteer contributors before coming on board, and David Festal from SERLI for making the IDE happen.

If you're interested in contributing to Ceylon, now is a really great time to get involved!

Built-in support for modularity is a major goal of the Ceylon project, but what am I really talking about when I use this word? Well, I suppose there's multiple layers to this:

1. Language-level support for a unit of visibility that is bigger than a package, but smaller than "all packages".
2. A module descriptor format that expresses dependencies between specific versions of modules.
3. A built-in module archive format and module repository layout that is understood by all tools written for the language, from the compiler, to the IDE, to the runtime.
4. A runtime that features a peer-to-peer classloading (one classloader per module) and the ability to manage multiple versions of the same module.
5. An ecosystem of remote module repositories where folks can share code with others.

I'm not going to get into a whole lot of fine detail of this, partly because what I have written down in the language spec today will probably change by the time you actually get to use any of this stuff, but let me give you a taste of the overall architecture proposed.

Module-level visibility

A package in Ceylon may be shared or unshared. An unshared package (the default) is visible only to the module which contains the package. We can make the package |shared| by providing a package descriptor:

Package package { 
    name = 'org.hibernate.query'; 
    shared = true; 
    doc = "The typesafe query API."; 
}

(Note: The package descriptor syntax has since changed

(Alert readers will notice that this is just a snippet of Ceylon code, using the "declarative" object builder syntax.)

A shared package defines part of the "public" API of the module. Other modules can directly access shared declarations in a shared package.

Module descriptors

A module must explicitly specify the other modules on which it depends. This is accomplished via a module descriptor:

Module module { 
    name = 'org.hibernate'; 
    version = '3.0.0.beta'; 
    doc = "The best-ever ORM solution!"; 
    license = 'http://www.gnu.org/licenses/lgpl.html'; 
    Import {
        name = 'ceylon.language'; 
        version = '1.0.1'; 
        export = true;
    }, 
    Import {
        name = 'java.sql'; 
        version = '4.0';
    }
}

(Note: The module descriptor syntax has since changed

A module may be runnable. A runnable module must specify a |run()| method in the module descriptor:

Module module { 
    name = 'org.hibernate.test'; 
    version = '3.0.0.beta'; 
    doc = "The test suite for Hibernate";
    license = 'http://www.gnu.org/licenses/lgpl.html'; 
    void run() {
        TestSuite().run();
    } 
    Import {
        name = 'org.hibernate'; version = '3.0.0.beta';
    }
}

(Note: The module descriptor syntax has since changed

Module archives and module repositories

A module archive packages together compiled |.class| files, package descriptors, and module descriptors into a Java-style jar archive with the extension car. The Ceylon compiler doesn't usually produce individual |.class| files in a directory. Instead, it directly produces module archives.

Module archives live in module repositories. A module repository is a well-defined directory structure with a well-defined location for each module. A module repository may be either local (on the filesystem) or remote (on the Internet). Given a list of module repositories, the Ceylon compiler can automatically locate dependencies mentioned in the module descriptor of the module it is compiling. And when it finishes compiling the module, it puts the resulting module archive in the right place in a local module repository.

(The architecture also includes support for source directories, source archives, and module documentation directories, but I'm not going to cover all that today.)

Module runtime

Ceylon's module runtime is based on JBoss Modules, a technology that also exists at the very core of JBoss 7. Given a list of module repositories, the runtime automatically locates a module archive and its versioned dependencies in the repositories, even downloading module archives from remote repositories if necessary.

Normally, the Ceylon runtime is invoked by specifying the name of a runnable module at the command line.

Module repository ecosystem

One of the nice advantages of this architecture is that it's possible to run a module "straight off the internet", just by typing, for example:

ceylon run org.jboss.ceylon.demo -rep http://jboss.org/ceylon/modules

(Note: The command line tools have since changed, and the above command would now be ceylon run org.jboss.ceylon.demo --rep=http://jboss.org/ceylon/modules)

And all required dependencies get automatically downloaded as needed.

Red Hat will maintain a central public module repository where the community can contribute reusable modules. Of course, the module repository format will be an open standard, so any organization can maintain its own public module repository.

Hrm, I notice it's been just over three months since I semi-accidentally announced the existence of the Ceylon project , and I guess I feel like you folks deserve some kind of progress report! At the time, I very much regretted the fact that the project became public knowledge before I was really prepared to socialize it, but in retrospect it was the best thing ever for us. That's where we got Stef and Tako and Sergej and Ben from, along with the other folks who are signing up to get involved in development. Unfortunately, we're still working in a private github repo, which is certainly not ideal, but it's helping keep us focused on getting actual code written.

So here's what we have so far:

• a 125 page language specification (with some open issues and vague sections),
• a parser and typesafe syntax tree for the whole language,
• a compiler frontend (type checker/analyzer) for about 85% of the language,
• a compiler backend that integrates the frontend with |javac|'s bytecode generation for perhaps 40% of the language, and
• the skeleton of a "model loader" that builds a metamodel of precompiled .class files (essential for incremental compilation and interoperation with Java).

The frontend of the compiler (the bit that analyzes the semantics of the code, assigns types to things, and reports programming errors) is basically done already. Certainly all the "hard" bits are finished, including stuff like generics, covariance, subtyping, refinement, member types, union types, definite assignment and definite return checking, type argument inference, etc. The few missing features could be finished off pretty quickly if there were any real urgency, but we may as well wait for the backend to catch up.

Development of the backend and model loader is now completely in the hands of volunteers from the community, and, frankly, it's going really well so far. We'll do an initial "alpha"-quality release of the compiler when we're happy that the backend is in a usable form.

I'm not going to promise any exact date for the first release, nor even the exact feature set - but I'm guessing it will happen within the next three months, and that it will include a really decent slab of the language defined by the specification. At that point, we'll hopefully be able to start putting some resources into the SDK and IDE.