Red Hat Uncloaks 'Java Killer': the Ceylon Project

talawahdotnet writes "Gavin King of Red Hat/Hibernate/Seam fame recently unveiled the top secret project that he has been working on over the past two years, a new language and SDK designed to replace Java in the enterprise. The project came out of hiding without much fanfare or publicity at QCon Beijing in a keynote titled 'The Ceylon Project — the next generation of Java language?'"

Comments

Because Scala, JRuby, Groovy, Clojure ...

[Anonymous Coward]

aren't enough (damn subject would have dropped the 'h' and that would have made me cry).

We need yet another JVM language to 'kill' Java. Epic. Brilliant.

The other languages were developed much more openly, not dropped like an MS product. Get real, Red Hat.

Re:Because Scala, JRuby, Groovy, Clojure ...

[M. Baranczak]

I have an issue with people throwing away the excellent JVM just to use a new language.

Right at the top of The Friendly Article, for which a link has been conveniently provided: "It is built to run on the JVM".

so much effort has gone into making it portable, secure and reliable, why re-invent that.

Because of the patents held by Oracle? It's still up in the air as to whether or not those patents mean anything, but if they do, then we may be forced to reinvent it.

Re:Because Scala, JRuby, Groovy, Clojure ...

[21mhz]

here the authors specifically say that they want to kinda get to where Java would have been, if it were designed from scratch today rather than in early 1990s.

Um, then they would have it natively support the entire Unicode repertoire rather than remaining in the 16 bit trap that Java fell to along with other platforms of that time.

Re:Because Scala, JRuby, Groovy, Clojure ...

[JesseMcDonald]

In this case, yes. Just like UTF-16, UTF-8 can encode any Unicode character up to 31 bits (U+7FFFFFFF). Since both are variable-length encodings, UTF-16 is no simpler to work with. UTF-8 has the additional advantages of being identical to ASCII for the first 128 codepoints, using a single byte order vs. big-endian/little-endian UTF-16, not embedding NUL characters, generally taking less space, not being confused for UCS-2, etc.

See also: advantages of UTF-8 compared to UTF-16

No need to duplicate work

[MrEricSir]

We already have a Java killer; his name is Larry Ellison.

Re:No need to duplicate work

[Anonymous Coward]

One Rich Asshole Called Larry Ellison.

Poetic.

Re:Ceylon?

[telekon]

Am I the only one who read, "Cylon"?

Do they have a plan?

The 'Cylon' project requires a meta-cognitive processor, not a VM.

Although, I had a similar experience reading about the 'Dalvik' VM... Wha... the DALEK VM?

Finally, it's Red Hat. They have no Plan. The One True God has no frakking patience for RHEL (and neither do I).

Java killer?

[PCM2]

A "Java killer" that relies on the JVM to run sounds like it's in for an uphill battle.

Writing an SDK from scratch in a homebrewed language that does everything the Java SDK does? Well, good luck anyway.

Re:Java killer?

[PCM2]

if enough people decide it is a good idea and participate, it may take much shorter than you can imagine.

Designing and implementing a new programming language that's intended as a direct challenge to Java... by committee... using a distributed development model... "much shorter than I can imagine"? Have you followed the history of Java at all? Or of any language?

linux prevailed, firefox prevailed.

And both were written in a language people already knew.

Re:Java killer?

[ceoyoyo]

A new language that relies on an x86 processor to run sounds like it's in for an uphill battle....

There's no reason not to use the JVM. It's a highly optimized, widely distributed virtual machine (just like x86 processors are highly optimized, widely distributed actual machines).

Now Java as a language... leaves something to be desired.

Re:Java killer?

[raddan]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language. The JVM actually isn't all that bad-- it's mature, bug-free, and reasonably fast. But that's beside the point-- the JVM is like x86. Nobody* cares about the instruction set; they care about language features, and whether those features work quickly. And both the Java VM and Microsoft's .NET runtime have numerous options: IronRuby for .NET and JRuby for JVM, IronPython for .NET and Jython for JVM, Clojure, F#, yadda, yadda.

Reinventing the VM is a waste of time. And there are tons of languages to choose from for those VMs. So I don't quite see the point of this. The slides appear to be slashdotted, and just from the post's talking points... yawn.

* "nobody" here should be read as "very few", i.e., mostly people who write JIT compilers and not people who write enterprise code.

Re:Java killer?

[cakoose]

Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.

When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.

Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.

Re:Java killer?

[jensend]

Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.

*citation needed*
Everything I've seen from Gosling says that pure interfaces are the way to go- even to the extent of getting rid of regular inheritance; see these quips. I don't think anybody who's seriously looking at language design thinks C++- style multiple inheritance is a good idea. Nor does anyone want to resurrect the braindead C preprocessor way of dealing with things.

And what's so bad about :=? The fact that some outmoded languages used it doesn't make it a bad idea. Most of us are familiar with its use as a definition or assignment, and avoiding confusions between = and == could be a plus, especially if (as he seems to propose) the latter is extended to replace use of .equals().

Re:Java killer?

[Mongoose Disciple]

why not ? if enough people decide it is a good idea and participate, it may take much shorter than you can imagine

I don't think you grasp how much Java stuff is out there already, even open source, and how many years it took to produce.

Open source isn't like a magical brownie cobbler that fixes your shoes in the night if you leave him a little saucer of milk. Sometimes it duplicates its effort, so to speak, for no good reason but I wouldn't bet on it on a massive scale any more than I'd bet on winning the lottery, except someone actually does typically win the lottery.

Re:Java killer?

[cakoose]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.

C# started out essentially the same as Java. But at this point it's way better.

• Function types and closures. This alone makes it way better.
• More efficient generics (no boxing/unboxing).
• Local variable type inference.
• Coming in C# 5.0: automatic CPS transformation (async/await).

Re:Java killer?

[Desler]

What the fuck is "enterprise code"? I've heard this phrase used in so much marketing, but what the hell is it supposed to mean?

Horribly bloated code written by mouth breathers who can't grasp any other language than one which doesn't hold their hand the entire way through. Oh and you usually have to throw in a couple of frameworks and then add additional frameworks on top of other frameworks to manage your other frameworks in the process of designing "enterprise" software.

Re:Java killer?

[clang_jangle]

now, not only we are mature, but also we have endless number of tools to facilitate distributed development.

There's some truth to that, but it also reminds me a bit of my eight-year-old neice talking about how different everything is now compared to way back when she was seven. :)

Starting to show indications of maturity yes. Achieved maturity -- not quite yet I think.

Re:Java killer?

[The End Of Days]

Maybe I'm stupid, but how does having everything behave like an object preclude operator overloading, multiple inheritance, or a preprocessor?

Re:Java killer?

[shutdown -p now]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.

They aren't. C# 1.0 was essentially Java with syntactic sugar, yes (properties, events, delegates, enums, varargs, ...), but syntactic sugar can make a lot of difference in practice for readable and understandable code. It also had some nice parts such as unsigned types, stack-allocated user-defined value types, and raw pointers - all that mostly useful for efficient interop with C libraries, but it's a surprisingly common scenario even today.

C# 2.0 added iterators (what Python calls "generators" - functions that produce a lazy sequence of values using some nice syntactic sugar), fully typesafe generics (no type erasure), and, most importantly, full-featured closures. A minor addition were nullable value types (unlike Java, you use strongly typed box types like Integer for the same, C# nullable value types are not boxed and therefore do not require heap allocation).

C# 3.0 added type inference for local variables, array literals, and closure return/parameter types; and sequence comprehensions (rebranded as "LINQ"). Minor additions were tuple-like anonymous types - "new { foo = 1, bar = 2 }"; and array-like literals for arbitrary collection types - "new List<int> { 1, 2, 3 }".

C# 4.0 added "dynamic" type, which is essentially opt-in duck typing. Another big addition is covariance and contravariance for generic type parameters - making e.g. "IEnumerable<Object> objects = new List<string>()" valid. Minor additions are optional method arguments, and named (what Python/Ruby calls "keyword") arguments when calling methods.

For comparison, in the same time period, Java has added a half-hearted generics implementation, enums, and vararg methods.

So, no, they're not the same language anymore.

Re:Java killer?

[RzUpAnmsCwrds]

Anyone who wants Java to allow overloading of == clearly has never had to deal with C# code (C# allows overloading).

The fundamental problem is that people don't understand Java semantics. In Java, equality testing is consistent and efficient: for reference types (everything except primitives), == always means reference equality. And .equals() always means value equality.

Comparing strings with == sometimes works because the runtime allocates string constants from a pool. So ("A" == "A") evaluates to true because they reference the same object. But ("A" == new String("A")) evaluates to false.

The key here is that object variables in Java are *always* references. That's why any object reference can be null, and it's why you can't compare them with ==.

The problem with overloading is that it's not consistent. Some C# objects overload ==, some don't. There's also ".Equals()", which always checks for value equality. There's also the static method Object.ReferenceEquals(), which always checks for reference equality.

So you end up with this trap where you either end up using Equals() all the time (as you do in Java), or you have some code that uses Equals() and some code that uses ==. Which doesn't make sense.

Java is about consistency and predictability. Having operators do different things in different contexts results in neither.

Re:Java killer?

[degeneratemonkey]

I absolutely hate Java, and I rather like C++, but I take serious issue with your ignorant, intolerant ranting...

1. GC implementation is not a language feature, it's a runtime feature. This has nothing to do with Java as a language. Furthermore, any sufficiently complex C++ program implements some form of (at least) semi-automated garbage collection; even if it's just reference-counting smart pointers. You apparently have no experience writing real software.

2. Really though, are you seriously arguing against non-deterministic GC because you think every program in the universe should be "well-behaved" and "provable" (on your own terms)? We might as well toss out, gee, I dunno, almost every modern language under the sun while we're at it. I think I can count on one hand the number of languages in regular, widespread use today whose standard runtimes leave memory management exclusively up to the programmer.

3. If you're really going to go down the "provable" road, you'd better throw away your C++ compiler too. Without referential transparency, C++ is practically useless as a language that facilitates "well-behaved" and "provable" code. Haskell for you.

4. "Class explosion?" This sounds like a term that would be used by a C programmer who writes C code inside of C++ classes, but who doesn't actually design object-oriented programs. "Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.

5. Meta-language (preprocessor/macros) is not language. Similar to point #1 in that it has nothing to do with the language itself. You could build a simple preprocessor for Java code if you felt so inclined (there are a small number out there already). It's a separate tool though. #define is not part of the C++ language in any way. It's part of the CPP language.

6. Kill off interfaces? No. What? I see problems with interfaces, but as a general idea they are not something to be killed off. Rather, I'd like to see the adoption of a more flexible "interface" system much like Go's. And multiple inheritance doesn't even make sense unless you like your objects to be schizophrenic, but please see point #4. The part about not understanding OOP.

7. Finally, you're cutting into a language like Java, while strongly defending an equally flawed language like C++. From your ranting it seems as though you don't understand either one (or many other languages, for that matter) well enough to comment on them. Yet here you are, vomiting invective upon the weary masses of Slashdot.

8. *Smack* Now go read something and stop face-rolling your keyboard. Thanks.

Oh and on-topic. Ceylon sounds interesting. I'll play with it. "Killing" Java will require billions of dollars though.

Re:Java killer?

[n dot l]

It's been ages since I worked with Java, but even if I hadn't been hearing for years how far Java's come since the bad old days, I'd feel compelled to call you on some of this bullshit...

A note before I start: I mostly work on video games, and I use a mix of C++ (engine), C# (custom build tools, editors, etc), various scripting languages (Lua, Python, etc: some embedded in the engine, others for automating aspects of the build). I've also written the odd business app in C# and, way back when, Delphi.

it just results in having to write a bunch more classes because the language is lacking in basic flexibility

On the contrary, one often wants simple values to behave like objects, such as when one wishes to declare groups of arbitrary values for serialization or the like. Having the compiler or runtime autogenerate an object version of your value types and provide a simple syntax for converting between the two forms is a huge time saver and spares one from writing a lot of tedious code.

it just results in having to write a bunch more classes because the language is lacking in basic flexibility

It also lacks the diamond problem. I mean, yeah, a competent programmer can work around that, sure. A competent programmer can also structure his code such that it doesn't require MI, without needlessly complicating anything.

no preprocessor

Nothing stops you from using C's (or any other) preprocessor with Java (or any other compiler that takes text files as input). That's where C++'s preprocessor (which most good C++ programmers recommend avoiding) came from, you know. Actually, in the bad old days, C++ itself was a preprocessor...

because the programmer "can't be trusted."

Because a programmer writing business apps has more interesting things to think about than making sure that his colleague remembers that foo() returns an object out of a memory pool which shouldn't be deleted or referenced beyond the end of the current transaction, whereas bar()'s return needs to be freed by returning it to a free list, and whether he can afford to pay the extra allocations and cache misses necessitated by returning shared_ptr wrappers that remember that for his colleague, or whether it's time to sit down and write two whole new pointer-wrapping classes (and if those wrappers use a reference count, should we put it in the object or allocate that from some special pool...), or whether he should return raw pointers and make a note to spend a few minutes during every future code review checking that they're not being misused...

Wait, where did shared_ptr come from? Why am I thinking of writing classes to wrap pointers? I just want to return a dynamically allocated object! What happened to not writing extra classes?

Throw in a non-deterministic garbage collector

The GC is, like all other software, entirely deterministic - in exactly the same way that malloc/free and new/delete's continue to behave deterministially when the heap becomes fragmented. The phrase you're looking for is "as strictly defined as my arbitrarily chosen reference point". Millisecond stalls at unspecified intervals to transparently collect garbage are entirely within the definition of well-behaved for a very large class of software.

At least in c++, you're guaranteed that when the stack frame is popped as your object goes out of scope, your destructor is called immediately.

And a language in which 95% of objects don't hold non-garbage-collected resources doesn't need destructors, let alone deterministic ones. The other 5% have a method called something synonymous with "close" on them, and competent programmers remember to call those functions, just as you remember to call (or write/use a class which will call) delete or free on the 95% of objects whic

Re:Java killer?

[kaffiene]

Operator overloading, like many C++ features, is great until you have to code with other people.

Re:Java killer?

[tomhudson]

Sheesh, obviously I hit a sore spot :-)

GC implementation is not a language feature, it's a runtime feature. This has nothing to do with Java as a language. Furthermore, any sufficiently complex C++ program implements some form of (at least) semi-automated garbage collection; even if it's just reference-counting smart pointers. You apparently have no experience writing real software.

Finalizers are a language feature. The fact that a finalizer is not guaranteed to ever run, not when your class does the java equivalent of c++ "out of scope" (no valid references left to it), or even on program termination, is a language flaw. The runtime just surfaces, or exposes, that flaw.

Would multi-threading real-time data servers that never kill off a thread from their thread pool between startup and shutdown months later while serving a thousand requests a second (because they never lose a byte of memory) qualify as "sufficiently complex"? No reference counting needed - just well-behaved code, and contracts between the loadable modules and the server as to who owns what memory.

It's called the "Dear Abby" school of memory management. If you pick it up, put it back when you're finished. If you give it to someone, either make sure that they know that they're expected to put it back when finished, or make explicit arrangements for them to return it to you so you can put it back.

It's not that hard to get right if such an obvious dummy as I can do it, right?

Really though, are you seriously arguing against non-deterministic GC because you think every program in the universe should be "well-behaved" and "provable" (on your own terms)? We might as well toss out, gee, I dunno, almost every modern language under the sun while we're at it. I think I can count on one hand the number of languages in regular, widespread use today whose standard runtimes leave memory management exclusively up to the programmer.

Finalizers in java can end up being just so much dead code, even on runs on the same machine. That's the sort of non-deterministic behaviour, where the code says one thing, but the behavior is "undefined" even between runs, that cries out for fixing. That's not "arbitrary" - that's a bug.

"Class explosion?" This sounds like a term that would be used by a C programmer who writes C code inside of C++ classes, but who doesn't actually design object-oriented programs. "Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.

Every non-trivial c++ program contains a fair chunk c code inside classes. All those flow control statements ... for(), if(), else, switch(), break;, continue; they're all c, not c++. Same with all the non-overloaded operators. You can't write a c++ program without using some c code. Here's a hint - look at the declaration for main().

"Classes if necessary, but not necessarily classes" is a rule of thumb a lot of us use; in my case, it's because, before java was ever even a gleam in JG's eye, I tried the "make everything a class" idiom, and ran into the same class explosion problem everyone does. Some people think that a proliferation of classes shows how great they are at coding. I don't. Classes, like everything else, are just semantic tools for managing complexity. Nothing more. Anyone who invests them with more meaning than that doesn't understand what's actually going on behind the scenes - your classes aren't real "objects" - just a series of bytes handily organized to do the job.

It's a separate tool though. #define is not part of the C++ language in any way. It's part of the CPP language.

The pre-processor is an integral part of every c implementation, always has been. And what is this CPP you speak of? The c pre-proces

Re:Something to watch

[zill]

I personally don't think it's ambitious at all. Their syntax and grammar only differ slightly from regular Java. Plus the fact that they're targeting the JVM means that they only need to patch javac (and javadoc) to make a new language. Despite how humongous the JDK is, the java compiler itself is relatively lean (only 140KLOC).

Re:Ceylon?

[steveha]

Am I the only one who read, "Cylon"?

You are not the only one. My first thought was, "I hope they hire Tricia Helfer to advertise this."

steveha

Re:C#/Mono similar?

[Anonymous Coward]

Two words: Oracle.

What's the second word?

Re:C#/Mono similar?

[Anonymous Coward]

"FuckingBullshitAss Oracle" is implied whenever somebody says "Oracle".

Pointless

[steveha]

They are proposing a new language, with new syntax, requiring new libraries... that runs on the JVM.

Since Oracle owns the JVM and is trying to find ways to extract money from it, a new language that requires the JVM seems pointless.

If you just want better syntax, why not use one of the existing JVM languages such as Scala?

If you are pioneering a completely new language, why not pioneer a new virtual machine, and lawyer up and make sure Oracle doesn't have any grounds to sue you?

steveha

hmm.

[jensend]

1. Put these guys, Walter Bright, and a few other folks (Alexandrescu? a couple of the best folks from the Java and C# camps?) in a building.

2. Lock the doors from the outside and guard the building until they've come up with the One True C++ Successor (both compilable to native code and a good target for a JIT) and the basic design for its standard library.

3. Profit^H^H^H^H^H^H End the ridiculous situation we have where systems-level programming is held back by 40-year-old braindead technologies like the C preprocessor while the dominant business programming languages are controlled by corporations with terrible track records.

Re:C#/Mono similar?

[Megaweapon]

Two words:

Oracle.

What's the second word?

Lawyers.

Missing feature in Java: Copy on write

[Michael Woodhams]

My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.

I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.

Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.

Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.

Are there any languages which do something like this?

Re:Ceylon?

[ronocdh]

It's a reference to the type of tea [wikipedia.org], as an alternative to Java—tea vs. coffee, get it?

Re:Another One! Just what we need

[garyebickford]

Don't forget all the other important languages!
* brainfuck
* whitespace
* piet
* INTERCAL
* false
* befunge
* malbolge
and, of course (last but not least!)
* LOLCODE

Re:Ceylon?

[Anonymous Coward]

I *am* from Ceylon (Sri Lanka) and yes, Ceylon is to tea what Java is to coffee. Both are islands. http://en.wikipedia.org/wiki/Tea_production_in_Sri_Lanka

Re:Ceylon?

[Culture20]

Am I the only one who read, "Cylon"? Do they have a plan?

No, it's a by-your-command line language. Totally open ended.

Re:Ceylon?

[lennier1]

Do they have a plan?

If he approached it the same way he did Seam (several different abstraction layers to the point where you're writing and digging through XML and annotations 50% of the time) the answer is simply "NO".

Re:lvalue on the right

[TeXMaster]

You have obviously never been on a *huge* software development project. The reason you use accessors and mutators (getters & setters) is so you can change the underlying representation without breaking all the uses in you million lines of code.I've had to make changes to underlying representation without breaking th client contract (signature). This is why such practices are used (plus, these methods are auto-generated by most tools anyway).

Well, in Ruby (which is a fully OOPL) getters and setters are used too, but the language syntax allows you to define methods such as 'property' and 'property=' so that setters and getters look exactly like direct access, and much less verbose than the dreadful getPropX() and setPropX() methods you usually have in Java or C++.

Re:Something to watch

[julesh]

Yes, but it also means you don't have to figure out how to persist your objects to your database, how to transfer them seamlessly from one box to another in a load balanced environment, how to manage the lifetime of per-user and per-session objects, how to set up your system to locate the URLs of your web services, how to send messages from one object to another on a remote machine, how to store your resources so that they can be altered without recompilation, and many other things...

Sure, J2EE takes a while to learn. But it provides a whole load of features that would take a lot longer to write if you had to do them from scratch.

Yes, but...probably no

[bradley13]

Java needs to be replaced. I have taught Java for years, because many colleges think it is a good first language to learn. Only recently have I actually attempted to develop commercial quality applications in it. Frankly, Java sucks big green ones. Generic types (with type-erasure) are a total hack, denying the running code valuable information. Abstract classes are only half-implemented, since you cannot have abstract static methods (e.g., factory methods). Meta-programming in Java is extremely limited - Reflection covers a few aspects, but even these are very awkward to use. Exception handling is awkward, there is no multiple inheritance, not all types are objects - hacked with boxing and unboxing. And so on, and so forth, and so on...

The chances of this language going anywhere are small. Anyone who has enjoyed studying compilers has written (or at least imagined) their own language. Creating new languages is fun, lots of people do it, and mostly - even if they are good - the languages disappear down a deep, dark hole. Success for a language requires a lot of support from many different parts of the IT community: lots of libraries, job prospects, more libraries, books, courses, real world applications, and did I mention code libraries? There are zillions of languages out there, many of them better than Java. Unfortunately, none of them to date have gotten the necessary support. What are the chances that this language will be different?