A project like this isn't even interesting
Took the words right out of my mouth
Red Hat is developing a new Java Virtual Machine-based programming language intended to overcome the limitations of Java itself. Unveiled earlier this week by lead developer Gavin King at a conference in China, the effort is known as Project Ceylon. Early reports of King's presentation in Bejing painted Project Ceylon as a "Java …
Took the words right out of my mouth
The post is required, and must contain letters.
JavaFX is just an extension of Java. This seems like a potential replacement. What's your point again?
""Much of our frustration is not even with the Java language itself."
"But when the language arrives, it will run in the Java Virtual Machine. "
Sounds rather like an extension of java to me.... of course it also sounds rather amorphous.
but the source code can be one of many languages (VB, C# and F# to name a few). The JVM is a theoretical CPU/environment, not a language. There's no reason that other source languages can't be compiled to Java Byte Code.
Another language to run on the JVM. Is this really the right way to do it? We can't all avoid oracle and whatever it wants to do with JVM and Java. If it can do it with Java what else can they do to JVM? Java owns the language and the JVM but this project is a start to a new future..
I can see Google getting into this. They have already side-stepped JVM, now they just need another language to say goodbye to Oracle
It died a death, as Java really is good enough.
User interface issues should not impinge on the language at all.
I think the main point to come out of this is the Java libraries are sh*t and I would agree wholeheartedly with that. I really wish they would take a leaf from the book of Python when looking at how to do proper library support. A nice clean general purpose language with some very usable interfaces to existing library infrastructures and that is where your UI support will come from.
And PLEASE can the Project Ceylon people avoid that mind-numbing use of jargon and marketing terminology that bedevils Java and it's SDKs? I mean come on guys. They have to come up with a name for a specific class type "BEAN", then come up with some even more banal name for ordinary classes "POJO". Just sayin'.
"Bean" is not a specific class type. It's just a class written to a convention so that another program can introspect it.
"Pojo" is an ordinary class in the context of persistence frameworks - as opposed to "J2EE Enterprise Java Beans" (bletch), which have nothing to do with the aforementioned Beans but are objects that, to be persisted, have to be of a class that is a subclass of some framework-provided class, which fracks up all the already pock-marked beauty of framework-managed persistence in the first place. Luckily we now have JPA and Hibernate, so that's all old history and you can persist your POJOs. Get it? More in the fat Hibernate Book.
0 on the test sheet.
I used to have a pretty nice CMP Session Bean framework in J2EE 1.4, which worked wonders for the stuff I do. Having methods start explicit transactions, commiting when the last method returns, or rolling back when certain Exceptions are thrown... that was pretty good for Business Logic. EJBs were also good if you wanted to have both a client UI and a Web frontend for your app; both would use the same server-side components.
Then Java EE 5 threw all that stuff away. CMP transactions seem to be no more, and Session Beans no longer support Local AND Remote methods. It seems that adding Hibernate was made at the expense of the already-established EJB framework. :(
Other than that ... EJBs are still good for stuff, even if they aren't as useful these days.
Yes, a bean is one kind of class written in a certain way.
The point was that they have to invent a terminology to describe a class that is not a bean, aka POJO.
Well, I'm sorry, but as far as I'm aware that is just "class" to everyone else.
The wider point I was trying to make is regards the terminology related to the different API infrastructures that are rife throughout the entire Java ecosystem. As a newcomer to Java, I found this an impenetrable barrier to understanding anything written about JAVA, that you need to know the current buzzwords to begin to get a grasp about that is being talked about.
Sorry to rant, it is just a bit of a bee that I have in my bonnet....
Let's take a look at this....
I can hear the attack lawyers at Oracle getting their lawsuit prepared already.
Just wait - tomorrow, Hurd will be announcing that Oracle is stopping development of all Oracle products for RHEL.....
I survived the great Hurd Migration....
So, will it support multiple inheritance? Proper mix-in programming? Proper destructors so RAII works?
The features you list seem to me to be the source of many programming errors,. Whilst other language communities have grown used to them, I've not seen a great desire for them in Java. There are far more useful and productive language features, and no real need to make Java more like (for example) C just to make people feel comfortable.
The difference between the major languages in use today may be of great concern to scientists, but is barely an issue for engineers. If you're delivering a practical, efficient solution to a client, you use what works, and Java has been shown to work from handheld, via desktop to server and into the cloud.
Multiple inheritance is one of the C++ evils that Java was deliberately designed to avoid.
Mix-in programming, Ruby-style, is simply the best way to create hopelessly obfuscated and incomprehensible code since Perl was invented.
And destructors are for wimps. If you can't manage your resources properly without this kind of nannying, you should really take up a less intellectually challenging career. Flower-arranging, maybe.
Aren't you relying on a gc to do the most basic of resource managing? Just saying...
Am I the only one who sees that as Red Hat being not-too-happy about Oracle's way to conduct business? It's becomming evident for everyone that the less you depend on Oracle products, the better.
Not that Java doesn't stink to begin with, I just doubt that it's the main reason behind the move.
....that (mis)read that as Project Cylon, and trembled just a little bit?
They seem to have a plan.... but where are the hotties?
Well, I guess it will take time.
Personally I will wait for Ceylon 6. Lucy Lawless (no.3) didn't quite do it for me.
The bloated piece of shit is the JVM, so yet another language will not change anything.
Apart from that, this Ceylon should not be thrown out of the airlock. A first look at the syntax says this can be explained in the original K&R "thin book of C" style, a good sign. An interfaces can contain mixin code.
Two Words... SCALA !!!
Two words... CLOJURE !!!
This is fun, can we all play?
This is about SE being the unfinished slap-dash that it is, and the Heath Robinson code it takes to build a desktop app or client. They're going after the very things that have frustrated me for a long time.
Is it by any chance linked to Sri Lanka's tea production.
If so perhaps we'll have lots of tea related elements in the new language,
for example bags instead of beans.
Even worse, they used the old colonial name for Sri Lanka! In the New Age of post-Bush Obumbling, aren't we all supposed to be uber-culturally-sensitive?
How frightening the comments to date have been so frivolous, when we are facing the ultimate conflict:
Oh, the humanity! It's coffee versus tea all over again. America versus England. Starbucks versus the ceremony of leaf and kettle.
Please, can't we get past the Revolutionary War? Hasn't there been enough suffering, both caffeinated and decaffeinated?
Can't we all just get along?
The issue isn't the language - new languages are two a penny, there are already a good half-dozen that run on the JVM, and arguing the toss about closures, pass-by-reference etc. is like arguing about indents or brace placement - it's not going to impact a decent coder to get the job done.
The reason Java has succeeded is the class library, which is (by and large) not too bad. Yes, there are cockups - Dates, URLs, Image I/O and anything to do with XML springs to mind - but Collections, java.io, threading, java.util.concurrent, these are all well designed subsystems. This imeans I don't have to reimplement them, but even better: no-one else has to either, which means I can interface to 3rd party code with these constructs. No painful translation required. Well, unless you're using org.w3c.dom (my god, how I hate thee...)
Any new language has to match or it's a non-starter.
Any serious developer knows this, and that's why even with all the issues Java has, there is nothing that comes close when it comes to standard set of cross platform APIs that a ton of developers know. Why do people think that Android uses a Java API and not native C, C++, or even AJAX.
Also, unless Redhat is going to spend billions marketing this, then I can't see it going anywhere.
Who the heck uses Java for desktop apps??