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 ...

[Anonymous Coward]

That's one of my pet peeves about Java.
Imagine how much memory and CPU time could be saved by all the Java web applications out there, if Java used UTF-8 instead of UTF-16. Same thing goes for .NET/Mono. The only kind of application that benefits from native UTF-16 is one calling into winapi.

Re:C#/Mono similar?

[Anonymous Coward]

If C# didn't kill Java, I don't see how anything else is going to.

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?

[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?

[tomhudson]

Making everything behave like an object can make things much cleaner

... but a lot of the time, it doesn't - it just results in having to write a bunch more classes because the language is lacking in basic flexibility - no programmer overloading operators, no multiple inheritance, no preprocessor - because the programmer "can't be trusted." Throw in a non-deterministic garbage collector and finalize methods that, if your program is running for months, may only be called when your program finally exits (really really REALLY dumb move there, people) ...

.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. Well-behaved, provable programs need to be deterministic. Until the gc is fixed, java by definition is not a well-behaved provable environment.

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]

The LAST people in the world I would ask for advice on programming language design would be people who think that C++ is a good language. That's like asking the blind for help with the colour scheme for your house.

Consistency is good which is why everything being an object is good. You can treat 'primitives' as being classes in terms of the language design while still implementing them as primitives in VM/byte code for optimisation purposes. Special cases / Corner cases are bad.

Multiple inheritance is the devil's spawn. The diamond pattern deserves it's own special level in hell. Interfaces are better - may I point out that Smalltalk used single inheritance with interfaces - so Java is much MORE traditionally OO in that regard than C++... but I digress. Mixins/traits are a much better solution still and are, I believe, the only solution a sane OO language designer should use these days.

Re:Java killer?

[kaffiene]

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

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:Something to watch

[Kagato]

The selling point to the enterprise is the JDK. If it was all about a better language that develops quicker they could have gone for Ruby years ago. In particular once sun brought JRuby in-house. The issue at hand is the Enterprise wants the bloatware in the J2EE SDK. Those classes and libraries represent a lot of work a developer doesn't have to figure out themselves.

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:C#/Mono similar?

[Anonymous Coward]

If C# didn't kill Java, I don't see how anything else is going to.

Yes, because a proprietary, patent encumbered, single-platform copy of Java with minimal enhancements was surely going to kill Java.

</sarcasm>

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:Something to watch

[fusiongyro]

Those classes and libraries represent a lot of work a developer doesn't have to figure out themselves

What? Those classes represent a lot of work the developer absolutely has to figure out themselves. Nobody just looks at J2EE and goes, "hey, that makes sense." J2EE costs time and money, it doesn't save time and money.

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.