Tag Archives: Ceylon

Constructors in Ceylon

via Constructors in Ceylon | Java Code Geeks.

Since the earliest versions of Ceylon, we’ve supported a streamlined syntax for class initialization where the parameters of a class are listed right after the class name, and initialization logic goes directly in the body of the class.

Programming with type functions in Ceylon

via Ceylon: Programming with type functions in Ceylon.

I’ve recently been working on some experimental new features of Ceylon’s already extremely powerful type system. What I’m going to explain in this post is known, technically, as:

  • higher order generic types (or type constructor polymorphism, or higher kinds), and
  • higher rank generic types (or rank-N polymorphism).

Please don’t worry about this jargon salad. (And please don’t try to google any of those terms, because the explanations you’ll find will only make these pretty straightforward notions seem confusing.) Stick with me, and I’ll do my best to explain the concepts in intuitive terms, without needing any of the above terminology.

But first, let’s start with pair of examples that illustrate a motivating problem.

Unique approach to observer/observable pattern in Ceylon

via Ceylon: Unique approach to observer/observable pattern in Ceylon.

The essence of the famous observer/observable pattern is that you have an observable object that produces events of various kinds, and one or moreobserver objects that register themselves as interested in notification when these events occur.

Typesafe APIs for the browser

Typesafe APIs for the browser

A new feature in Ceylon 1.1, that I’ve not blogged about before, is dynamic interfaces. This was something that Enrique and I worked on together with Corbin Uselton, one of our GSoC students.

Ordinarily, when we interact with JavaScript objects, we do it from within a dynamic block, where Ceylon’s usual scrupulous typechecking is suppressed. The problem with this approach is that if it’s an API I use regularly, my IDE can’t help me get remember the names and signatures of all the operations of the API.

Dynamic interfaces make it possible to ascribe static types to an untyped JavaScript API. For example, we could write a dynamic interface for the HTML 5CanvasRenderingContext2D like this:

Write in Ceylon, deploy as OSGI, use in Java EE

Write in Ceylon, deploy as OSGI, use in Java EE

The Ceylon language is inherently modular, and is shipped with a complete infrastructure that allows leveraging this modularity out-of-the box. However Ceylon is not captive of its own infrastructure. After the Java and JS interoperability efforts, the 1.1.0 version has brought out-of-the-box compatibility with OSGI, which enables running Ceylon code inside many other containers.

Every module archive produced by the Ceylon compiler contains OSGI headers in its MANIFEST file, that describe the module as it should seen by OSGI containers.

Containers tested so far are:

  • Apache Felix 4.4.1,
  • Oracle Glassfish v4.1,
  • Equinox platform,
  • JBoss WildFly 8.0.0.alpha3 (with JBossOSGi installed)

Of course, the Ceylon distribution and SDK modules should first be added inside the OSGI container as OSGI bundles.

But instead of writing long explanations here, let me direct you to some concrete examples provided, with the required instructions, in the following repository:


For the moment, it contains a single example that, though very simple, will give you the main steps to start.

It also shows the use of a Ceylon module totally outside Ceylon’s standard infrastructure, even outside the JBoss world, in a Web application servlet running on a Glassfish v4.1 application server. But of course you should be able to run it inside other OSGI-enabled application servers or containers.

In the next examples we’ll try to go further an do more interesting things such as providing services, using Ceylon annotations (which are compatible with Java annotations), or using OSGI services.

Please report any problem you might encounter while testing, and feel free to submit pull requests for any other successful use cases you might have built.

Looking forward for your remarks, and for the time to write the following examples.

Ceylon 1.1.0 is now available

Ceylon 1.1.0 is now available

Ten whole months in the making, this is the biggest release of Ceylon so far! Ceylon 1.1.0 incorporates oodles of enhancements and bugfixes, with well over 1400 issues closed.

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.

For the end user, the most significant improvements in Ceylon 1.1 are:

  • performance enhancements, especially to compilation times in the IDE,
  • even smoother interoperation with Java overloading and Java generics,
  • out of the box support for deployment of Ceylon modules on OSGi containers,
  • enhancements to the Ceylon SDK, including the new platform modules ceylon.promise, ceylon.locale, and ceylon.logging, along with many improvements to ceylon.language, ceylon.collection, and ceylon.test,
  • many new features and improvements in Ceylon IDE, including
  • ceylon.formatter, a high-quality code formatter written in Ceylon,
  • support for command line tool plugins, including the new ceylon format and ceylon build plugins, and
  • integration with vert.x.

A longer list of changes may be found here.