Creation Review

Type
Creation
State
Successful
End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.

Proposal

Eclipse Ceylon

Tuesday, January 31, 2017 - 05:12 by Stephane Epardaud
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Eclipse Ceylon is a modern statically-typed programming language for the Java, Android, and JavaScript virtual machines. The language features a unique and uncommonly elegant static type system, a flexible and very readable syntax, a powerful module architecture, a modular SDK, smooth interoperation with native Java and JavaScript, and with Maven and npm, excellent command-line tooling, and a full-featured IDE.

The Ceylon language is defined by a complete, but very readable specification.

Development of Ceylon ramped up in 2011, with the first major release 1.0 in 2013. Ceylon 1.1 was released in 2014, 1.2 in 2015, and 1.3 in 2016. Ceylon has a very active user community, with most interaction occurring in the various Gitter channels associated with the project.

The Ceylon project has already significantly advanced the state of the art in the Java/C# language family, and in the field of statically-typed languages in general. Innovations seen first in the Ceylon project are already being adopted in the type systems other new programming languages. Ceylon was the first language to demonstrate practical applications of free-form union and intersection types, and alerted the programming language community to the importance of these constructs. Ceylon was also either the first language, or at least one of the first two languages, to feature flow-sensitive typing, a concept which has now been adopted by a number of other languages. Furthermore, Ceylon has the most sophisticated and cleanly-integrated module system of any programming language.

Scope

The Eclipse Ceylon project encompasses development of the language itself (the language specification), the compiler frontend (typechecker), the compiler backends for Java and JavaScript, the module system, the command-line tooling, the SDK, and the Eclipse-based IDE. A future direction is tooling for Eclipse Che. The project also maintains the website and documentation for the language.

Description

Eclipse Ceylon consists in a number of components:

  • The Ceylon distribution, which is composed of the following modules:

    • ceylon-typechecker (compiler front-end), which includes the parser, AST and type-checker

    • ceylon-model: describes a type-checked Ceylon program (this is what the type-checker outputs), and provides a facility for turning a JVM class into a Ceylon model

    • ceylon-compiler-java: produces JVM bytecode modules for Ceylon programs (the JVM back-end), also contains the API documentation generator

    • ceylon-compiler-js: produces JavaScript modules for Ceylon programs (the JS back-end)

    • ceylon.language: the base Ceylon language module implicitly imported by every Ceylon module, which contains the Ceylon basic types

    • ceylon-module-resolver: deals with module repositories reading and writing and contains optional plugins:

      • ceylon-module-resolver-aether for Maven interop

      • ceylon-module-resolver-javascript for JS interop

    • ceylon-common: a utilities module used by most other modules

    • ceylon-cli: the framework used by the Ceylon Command-Line Interface tools

    • ceylon-tools: most of the CLI tool implementations

    • ceylon-runtime: a JBoss Modules runtime for Ceylon

    • ceylon-main: a barebones ClassPath-based runtime for Ceylon

    • ceylon-tool-provider: APIs to invoke the compilers and runners

    • ceylon-module-loader: resolver that resolves the right versions for transitive dependencies of Ceylon modules

    • ceylon-bootstrap: support for auto-downloading the right Ceylon distribution in Ceylon projects

  • The Ceylon SDK: the Ceylon APIs that allow access to the file system, network, databases, http client and server, mathematics, testing framework and many other things.

  • The ceylon-lang.org website: static generated website based on Awestruct

  • The Ceylon Web IDE: allows you to try your Ceylon program in the browser, requires an OpenShift server that compiles the code and sends it back to the browser for execution.

  • The Ceylon Eclipse IDE: fully-featured Ceylon editor in Eclipse

  • The Ceylon IntelliJ IDE: fully-featured Ceylon editor in IntelliJ, newer than the Eclipse plug-in and still a little bit behind in terms of features

  • The Java2Ceylon converter: Ceylon module that converts Java code in to Ceylon. Used by the Eclipse/IntelliJ IDEs

  • The Ceylon formatter: Ceylon module that formats Ceylon code. Used by the Eclipse/IntelliJ IDEs

  • The ceylon-ide-common project: common Ceylon module used by the Eclipse/IntelliJ IDEs to share functionality

  • The Ceylon Herd project, which is a web server allowing publishing and consumption of Ceylon modules. Its functionality and scope is similar to Maven Nexus.

  • The modules.ceylon-lang.org and herd.ceylon-lang.org services which are running a Herd instance for Ceylon modules. It’s functionally equivalent to Maven Central for Ceylon.

Why Here?

Ceylon has a small but very active and enthusiastic community of developers and users, and indeed is the fruit of the hard work of a large number of contributors over the years. We aim to further grow our community and believe that a key strategy to achieve that would be to move Ceylon from Red Hat to a vendor-neutral foundation. The Eclipse Foundation already hosts several projects Red Hat contributes to, including the Eclipse Project and Vert.x.

We believe that joining the Eclipse Community will help Ceylon become even more popular with contributors and users alike.

Future Work
  • investigate rebasing the JVM backend on ECJ
  • finish implementation of higher-order generics
  • investigate adding support for async/await
  • finish TypeScript interop
  • improve Eclipse plugin responsiveness by delaying binary generation
  • investigate support for Eclipse Che
Project Scheduling

The initial contribution will arrive in Q2, 2017, with a first release soon after. It is unclear whether the first release will be named 1.3.3, or 1.4.0. (The Eclipse requirements with respect to package naming might require a break to binary compatibility, thus resulting in a bump to the minor version number.)

Initial Contribution

The code we contribute to the Eclipse Ceylon project has the following dependencies:

  • Ceylon distribution

    • build dependencies:

      • ant 1.8.2 (ASL2)

      • ant-contrib 1.0b3 (ASL2)

      • antlr 3.4 (BSD)

      • biz.aQute.bnd 2.3.0 (ASL2)

      • hamcrest-core 1.3.0 (BSD 2-clause)

      • junit 4.11 (CPAL 1.0, CPL 1.0)

      • org.osgi.core 4.3.1 (ASL2)

      • org.osgi.impl.bundle.bindex 2.2.0 (ASL2)

      • org.osgi.impl.bundle.repoindex.ant 2.1.2 (ASL2)

      • shrinkwrap-api 1.0.0 (ASL2)

      • shrinkwrap-impl-base 1.0.0 (ASL2)

      • shrinkwrap-spi 1.0.0 (ASL2)

      • xmltask 1.16 (Apache 1.1)

    • Build+runtime

      • Rainbow 1.1.9 (ASL2)

      • jQuery 1.8.2 (MIT)

      • Bootstrap (ASL2)

      • net.minidev.json-smart-1.1.1 (ASL2)

      • org.apache.commons.lang3-3.4 (ASL2)

      • org.apache.commons.codec-1.8 (ASL2)

      • org.apache.commons.logging-1.1.1 (ASL2)

      • org.apache.maven.maven-settings-3.3.9 (ASL2)

      • org.tautua.markdownpapers.core-1.2.7 (ASL2)

      • org.apache.maven.maven-aether-provider-3.3.9 (ASL2)

      • org.apache.maven.maven-builder-support-3.3.9 (ASL2)

      • org.apache.maven.maven-artifact-3.3.9 (ASL2)

      • org.apache.maven.maven-settings-builder-3.3.9 (ASL2)

      • org.apache.maven.maven-model-3.3.9 (ASL2)

      • org.apache.maven.maven-repository-metadata-3.3.9 (ASL2)

      • org.apache.maven.maven-model-builder-3.3.9 (ASL2)

      • org.apache.httpcomponents.httpcore-4.3.2 (ASL2)

      • org.apache.httpcomponents.httpclient-4.3.2 (ASL2)

      • org.slf4j.api-1.6.1 (MIT)

      • org.slf4j.simple-1.6.1 (MIT)

      • org.eclipse.aether.spi-1.1.0 (EPL1)

      • org.eclipse.aether.connector.basic-1.1.0 (EPL1)

      • org.eclipse.aether.util-1.1.0 (EPL1)

      • org.eclipse.aether.api-1.1.0 (EPL1)

      • org.eclipse.aether.transport.file-1.1.0 (EPL1)

      • org.eclipse.aether.transport.http-1.1.0 (EPL1)

      • org.eclipse.aether.impl-1.1.0 (EPL1)

      • org.antlr.antlr-2.7.7 (BSD) (optional dependency of antlr-runtime 3, which we can remove by upgrading to antlr-runtime 3.5.2 without the optional dependency to antlr 2, I have a branch where I validated this)

      • org.antlr.runtime-3.4 (BSD)

      • org.antlr.stringtemplate-3.2.1 (BSD)

      • org.jboss.modules-1.4.4.Final (Apache 2.0, CC0 1.0, Public)

      • org.jboss.logmanager-2.0.3.Final (Apache 2.0, CC0 1.0, Public)

      • org.codehaus.plexus.plexus-utils-3.0.22 (ASL2)

      • org.codehaus.plexus.plexus-interpolation-1.22 (ASL2)

      • com.github.lookfirst.sardine-5.1 (ASL2)

      • com.github.rjeschke.txtmark-0.13 (ASL2)

      • com.google.guava-18.0 (ASL2)

  • ceylon-lang.org build dependencies:

  • Ceylon SDK

    • Build deps

      • ant-contrib 1.0b3 (ASL2)

      • biz.aQute.bnd 2.3.0 (ASL2)

      • org.osgi.impl.bundle.bindex 2.2.0 (ASL2)

      • org.osgi.impl.bundle.repoindex.ant 2.1.2 (ASL2)

      • org.h2 1.3.168 (MPL2, EPL1)

    • Runtime deps

      • org.springframework.data:spring-data-commons 1.12.4.RELEASE (ASL2)

      • org.springframework.data:spring-data-jpa 1.10.4.RELEASE (ASL2)

      • org.springframework:spring-tx 4.2.8.RELEASE (ASL2)

      • org.hibernate.javax.persistence:hibernate-jpa-2.1-api 1.0.0.Final (EDL 1.0, EPL 1.0)

      • org.jboss.narayana.jta 5.2.7.Final-1 (LGPL 2.1)

      • org.jboss.xnio.nio 3.3.6.Final (CC0 1.0, Public)

      • io.undertow.core 1.4.4.Final (Apache 2.0, CC0 1.0, Public)

      • org.jboss.modules 1.4.4.Final (Apache 2.0, CC0 1.0, Public)

  • Ceylon Web IDE

    • Runs on OpenShift

    • Deps:

      • txtmark 0.13 (ASL2)

      • Lots of things in JS:

        • Jquery 1.11.1 (MIT)

        • Code-mirror (MIT)

        • Github.js (not sure: https://github.com/github-tools/github/blob/master/LICENSE)

        • Jquery-cookie 1.4.1 (MIT)

        • jQuery UI 1.11.2 (not sure: https://github.com/jquery/jqueryui.com/blob/master/LICENSE.txt)

        • Marked (MIT)

        • Require.js (MIT/BSD)

        • Spin.js (MIT)

        • URI.js (MIT)

        • W2ui 1.4.3 (MIT)

  • Ceylon Eclipse IDE

    • Build Deps

      • Maven-ant-tasks 2.1.3 (ASL2)

    • Runtime Deps

      • Zip4j 1.3.2 (ASL2)

      • Net.minidev.json-smart 1.1.1 (ASL2)

      • org.tautua.markdownpapers.core 1.2.7 (ASL2)

      • com.github.rjeschke.txtmark 0.13 (ASL2)

      • Org.antlr.antlr4-runtime-osgi 4.5.1 (BSD, custom version with OSGi descriptor fixes)

      • org.antlr.runtime 3.4 (BSD)

  • Ceylon IntelliJ IDE

    • Most of those come from the IJ IDE download that is a build pre-requisite

      • Com.intellij.openapi (IJ IDE download)

      • com.intellij.idea (IJ IDE download)

      • org.jetbrains.plugins.gradle (IJ IDE download)

      • org.intellij.groovy (IJ IDE download)

      • org.intellij.maven (IJ IDE download)

      • org.jdom (IJ IDE download)

    • com.github.rjeschke.txtmark 0.13 (ASL2)

  • Ceylon Herd

    • Play Framework 1.2.6 (patched) (ASL2)

    • Postgres JDBC connector (BSD)

    • txtmark 0.13 (ASL2)

    • markdownpapers-core 1.2.7(ASL2)

    • gravatar 1.0.2 (no license: https://github.com/mbarbieri/play-gravatar) (tiny run-time dep, we can replace it)

    • db 1.1.1 (Actually ASL2: https://github.com/pepite/play--database/blob/master/src/play/modules/db/Exporter.java) (build-time dep)

  • Ceylon.formatter

    • No external deps

  • Java2ceylon

    • Org.antlr.antlr4-runtime-osgi 4.5.1 (BSD, custom build with OSGi metadata fixes)

  • Ceylon IDE common

    • net.lingala.zip4j 1.3.2 (ASL2)

    • org.jgrapht.core 0.9.1 (EPL, LGPL 2.1)

    • Ceylon dist

    • Ceylon SDK

    • ceylon.formatter

Project Hosting

We hope to be able to keep our projects hosted at GitHub and using GitHub issues, because we have a long history of contributions there and all of our users prefer using GitHub issues.

As for hosting ceylon-lang.org we currently have a server responding to GitHub push notifications which pulls the project from github and runs awestruct to rebuild the static pages, which are then served using a web server. We're fine with moving it as long as we can keep the workflow of it being published automatically on new commits.

We are also hosting http://modules.ceylon-lang.org and http://herd.ceylon-lang.org which are instances of Ceylon Herd where people can upload Ceylon modules. This is the equivalent of Nexus + Maven Central. This is a Play Framework application. The easiest for everyone is if we keep those hosted ourselves and the Eclipse DNS points to our servers. Just to clarify that these domains serves user-submitted code/modules, just like Maven Central, with a variety of OSS licenses that we do not control.

We are also hosting http://try.ceylon-lang.org/ which is the Ceylon Web IDE instance. Currently running on OpenShift. Here again, the easiest for everyone is if we keep those hosted ourselves and the Eclipse DNS points to our servers.

 

Source Repository Type

(To echo what I said on the Ceylon blog, for some reason my comments didn't show up there. FWIW, after a little testing, I do not think it's foul play, just bad implementation by Disqus.)

> Furthermore, Ceylon has the most sophisticated and cleanly-integrated module system of any programming language.

This is patently absurd. The ML family of languages is far, far more advanced than anything that could reasonably be implemented on top of the JVM -- unless you completely ignore compat with existing JVM languages; which you cannot afford to do and under which constraint it makes little sense to even choose the JVM.

(If you make such a bold claim you had better be *very* sure what you're saying, otherwise you're going to need a lot of qualifiers. FWIW, I think this is just a matter of tunnel vision, but the statement should still really be amended with an asterisk, or something.)

 

(Here's to hoping *this* comment shows up.)