In case you missed it, we just released the fourth milestone of Ceylon and Ceylon IDE. The next release will be the feature-complete Ceylon 1.0 beta, now due in January. We've also pushed a major update to Ceylon Herd.

This is the first release of Ceylon IDE to include complete support for compilation to JavaScript and execution on Node.js.(Since M3, the Ceylon compiler has offered the option of compiling a Ceylon module to a CommonJS module) I personally love being able to write a snatch of Ceylon code and then watch it execute on both the JVM and Node, all from directly within Eclipse.

Another cool new features of the language is the assert statement. If assertions doesn't sound that cool or new to you, then I bet you have not yet seen Ceylon's unique spin on the concept. You can read more about it at the Ceylon blog.

(P.S. I'm now mostly blogging over at the Ceylon site, and on Google plus, but I'll still post items here from time to time.)

This is the second release of the Ceylon compiler and other command line tools.

You can read Stef's announcement here at the Ceylon blog. The major new features are:

• Java interoperability
• enumerated/algebraic types and switch/case
• first-class and higher-order functions
• support for remote module repositories and Maven repositories

Try it out!

A huge thanks to the Ceylon team for getting this release done on schedule while I've been taking a break from development! Thanks so much!

Great, I'm finally able to write, compile, and run Ceylon code that uses Java libraries from within Ceylon IDE:

import java.lang { System { sysprops=properties } }
import java.util { Date }

void greet() {
    value date = Date();
    print("Hello, " sysprops.getProperty("user.name", "world") 
          ", the date is " date.day "/" date.month "/" 1900+date.year ".");
}

This doesn't look like much, perhaps, but it's demonstrating some important features of the interoperability:

1. the ability to map a Java static declaration to a toplevel declaration in Ceylon,
2. the ability to resolve an invocation to the correct overloaded version,
3. the equivalence between Java primitive types and java.lang.String and Ceylon types in ceylon.language, and
4. the automatic mapping of JavaBeans properties to Ceylon attributes.

Here's a second working example:

import java.lang { System { sysprops=properties } }
import java.io { File }

void listHomeDir() {
    for (file in File(sysprops.getProperty("user.home")).listFiles()) {
        print(file.canonicalPath);
    }
}

Java interop has been a somewhat tricky problem for us because Ceylon's type system is somewhat different to Java's, and because the design of Ceylon's language module isn't really based on the Java SDK. When running on the Java VM, the language module does make use of the Java SDK as part of its internal implementation. But when running on a JavaScript VM, it can't, of course. So we have to limit our dependence upon JVM-specific stuff.

We've still got a few things to finish off here. For example, our treatment of arrays and Java Iterables is not completely finished, and some IDE features still aren't working quite right, but I think most of the hard work is already done, ready for release as part of Ceylon M2.

Good work guys!

The first official public release of the Ceylon IDE is out! You can read David's announcement here.

This is a full-featured development environment for Ceylon, with I guess everything you use regularly in your Java IDE, including interactive error reporting, incremental build, syntax highlighting, proposals, quick fixes, refactoring, searching, wizards, hover help, debugging, and much more. It even has a major feature that your Java IDE doesn't have: deep integration with Ceylon's module and module repository architecture. (No more futzing with the project build path!)

Check out the feature list, and some screenshots. Then try it out from our update site.

I'll have more to say about how we were able to engineer an entire professional IDE for a new language in less than 6 months with two part-time developers in a future post.

Once again: thanks to David Festal for all his hard work, and to SERLI for their support.

Haha! Try compiling this Java code:

interface Interface<T> {}

class Bang<T> implements Interface<Interface<? super Bang<Bang<T>>>> {

    static void bang() {
        Interface<? super Bang<Byte>> bang = new Bang<Byte>();
    }
	
}

(For me, the compiler stackoverflows, and Eclipse asks for my permission to crash.)

I'm not sure how widely known this problem is. It's not really a bug in the compiler, more like a bug in Java's type system. I found out about it from this excellent paper, which also proposes a solution to the problem, but the paper appears to build on work in this other paper, which I'm also linking because I'm a big fan of Stefan Wehr's work on JavaGI.

UPDATE: Here's another paper dealing with this issue, this time from Microsoft guys.

And, in case you're wondering, yeah, I can make the Ceylon typechecker stackoverflow with the equivalent code:

interface Interface<in T> {}

class Bang<T>() satisfies Interface<Interface<Bang<Bang<T>>>> {}

void bang() {
    Interface<Bang<String>> bang = Bang<String>();
}

I guess ima gunna get right on to implementing the solution proposed in Tate et al.