Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Open Source Programming Red Hat Software Linux

Red Hat Uncloaks 'Java Killer': the Ceylon Project 623

Posted by timothy from the as-sung-by-the-bad-brains dept.
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?'"
This discussion has been archived. No new comments can be posted.

Red Hat Uncloaks 'Java Killer': the Ceylon Project More

Red Hat Uncloaks 'Java Killer': the Ceylon Project

Comments Filter:

  • Ceylon? (Score:3, Funny)

    by ArcherB ( 796902 ) on Tuesday April 12, 2011 @10:26PM (#35802904) Journal

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

    Do they have a plan?

  • Sounds attractive but very ambitious.

    • Re:Something to watch (Score:5, Interesting)

      by zill ( 1690130 ) on Tuesday April 12, 2011 @10:46PM (#35803024)
      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: (Score:3, Insightful)

        by Kagato ( 116051 )

        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.

        • Re: (Score:3, Insightful)

          by fusiongyro ( 55524 )

          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 (Score:5, Insightful)

            by julesh ( 229690 ) on Wednesday April 13, 2011 @03:20AM (#35804794)

            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.

          • Re: (Score:3)

            by DrXym ( 126579 )

            J2EE costs time and money, it doesn't save time and money.

            Every language costs time and money to learn. In Java's case it's not the language so much as all the technologies that are built with it. That, in a nutshell is why any replacement for Java has to be as close to 100% compatible as possible. You literally want to be able to sit a Java developer of any competence in front of MiracleJ or whatever the language is called and for them to not notice much difference. It should feel comfortable, familiar. It should build the mass of code they likely have to mainta

          • So let me get this straight. It's better for someone to take, for example, C, or Ruby, or PHP and implement roll their own implementations of:

            1. Thread pool management
            2. Load balancing and fail-over
            3. Session replication
            4. Distributed transaction management
            5. Naming directory
            6. EIS connection management
            7. Pluggable authentication and authorization
            8. HTTP request parsing and invocation
            9. Tags and markup for data binding / AJAX support
            10. UI component model
            11. Logging
            12. Web service management and deployment

      • Re: (Score:3, Interesting)

        by jd ( 1658 )

        Oracle have threatened to sue anyone and their aunt Mildred if they step out of line on the Java standard or violate any Java-related patent. Apache needs a JVM-type system to run Tomcat and Debian will supply patentware over their collective dead bodies (once an open-source license for dead bodies is agreed upon). Red Hat knows this. Red Hat also knows that commercial vendors like Adobe (Cold Fusion runs on JRun, a servlet engine) like Java because nothing makes for bigger profits than free. Patent-based l

    • Re: (Score:3)

      by DrXym ( 126579 )

      Sounds attractive but very ambitious.

      Let's not forget that Microsoft has thrown its weight behind the .NET platform which is arguably superior to Java in many (but not all) ways and they still haven't even dented the popularity of Java.

      Part of the issue is that Java just works. It may be verbose, horribly broken in some respects but it still works. The only way you're going to wean people of vanilla Java is to produce a Java++, something which compiles syntactically correct Java with no modifications, supports all existing Java libs with no

      • Re: (Score:3)

        by kaffiene ( 38781 )

        In what way is Scala not a super set of Java?

        • Re: (Score:3)

          by DrXym ( 126579 )
          Scala is not a superset of the Java language. It may be byte code compatible which is not the same thing at all. By that definition Jython would also be a superset of Java since it too generates bytecodes and runs on a JVM.

      • Re: (Score:3)

        by Phleg ( 523632 )

        People promoting Scala, Google Go, Ruby or similar are pissing into the wind on this matter.

        What in god's name makes you think we want the legions of mindless Java programmers to join us?

  • Because Scala, JRuby, Groovy, Clojure ... (Score:3, Insightful)

    by Anonymous Coward on Tuesday April 12, 2011 @10:27PM (#35802916)

    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.

    • In all honesty, all the projects that you've listed make their stated goal to be less "enterprise" than Java in overall feel. Whereas 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.

      • Re:Because Scala, JRuby, Groovy, Clojure ... (Score:4, Insightful)

        by 21mhz ( 443080 ) on Wednesday April 13, 2011 @02:11AM (#35804410) Journal

        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.

        • Java has been using UTF-16 (which "supports the entire Unicode repertoire") for ages. If you access individual chars in a string, you've got to handle surrogate pairs on your own, sure, but why do you even do that? Stock string methods can handle it all just fine.

  • No need to duplicate work (Score:5, Funny)

    by MrEricSir ( 398214 ) on Tuesday April 12, 2011 @10:29PM (#35802932) Homepage

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

  • Java killer? (Score:5, Insightful)

    by PCM2 ( 4486 ) on Tuesday April 12, 2011 @10:37PM (#35802978) Homepage

    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.

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

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

      the open source community now knows open source effort works. linux prevailed, firefox prevailed. people have self esteem and faith now, and know the ways to make it work. now, they will make work, whatever they decide to make it work.

      • Re:Java killer? (Score:5, Insightful)

        by PCM2 ( 4486 ) on Tuesday April 12, 2011 @10:45PM (#35803016) Homepage

        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.

        • linux, firefox were developed during at an era when the open source movement was in development itself. tools, methods, issues, were not known.

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

          yes, indeed, with the variables given, one thing that is certain is that it would be much shorter than before, to develop an entire language, using the distributed development model now.

          • Re:Java killer? (Score:5, Insightful)

            by clang_jangle ( 975789 ) on Wednesday April 13, 2011 @12:40AM (#35803882) Journal

            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: (Score:2, Interesting)

        by tomhudson ( 43916 )

        The problem is this doesn't "throw out the things that are flawed in the original java" - quit the contary.

        No âoespecialâ types, everything is an object

        (and TFA loses additional points for using Microsoft's smart quotes as demonstrated above)

        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.

        The new assignment operator ":="

        Oh look, someone r

        • Re:Java killer? (Score:5, Insightful)

          by cakoose ( 460295 ) on Tuesday April 12, 2011 @11:20PM (#35803288) Homepage

          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.

          • Making everything behave like an object can make things much cleaner

            In a perfect world probably. But have you considered that there's a reason why primitive types are left as primitives even in C# (which had the opportunity to correct the mistakes Java made).

            Primitives are kept because they are fast, and objects are blinking slow. You don't notice this when you use a relatively few objects, even then because they contain primitives themselves. Turn those into nested object hierarcies (as you'd get if even a

            • Re: (Score:3)

              by cakoose ( 460295 )

              In a perfect world probably. But have you considered that there's a reason why primitive types are left as primitives even in C# (which had the opportunity to correct the mistakes Java made).

              I'm not suggesting that primitive types be implemented using the mechanics of regular objects. I'm just saying that they could be made to appear to the programmer like regular objects. Combined with certain restrictions (e.g. no extending from primitives) and some compiler tricks, this can be made to work efficientl

            • Re: (Score:3)

              by kaffiene ( 38781 )

              It's amazing that Scala manages to be blazingly fast, then, given that it's primitives are all classes. Maybe you should tell them that they;re obviously doing it wrong.

        • Re:Java killer? (Score:5, Insightful)

          by jensend ( 71114 ) on Tuesday April 12, 2011 @11:23PM (#35803332)

          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 [blogspot.com]. 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().

          • That brings up another thing that's missing from java - operator overloading. The String class is overloaded, but we can't overload operators (even the + or ==) when it would make sense.

            This is a case of "we don't trust the programmer to get it right", same as the lack of multiple inheritance and the stupidity of interfaces as a work-around.

            • Re:Java killer? (Score:5, Insightful)

              by RzUpAnmsCwrds ( 262647 ) on Wednesday April 13, 2011 @01:31AM (#35804194)

              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.

            • Java deliberately avoided operator overloading as it caused horrific problems with C++ programs. Apart from simple cases you could never trust that someone had overloaded the operator to make it work like you thought - you had to laboriously understand each and every place where an operator was used. Operator overloading was a good idea that turned out to be terrible in practice.

            • Re:Java killer? (Score:4, Insightful)

              by kaffiene ( 38781 ) on Wednesday April 13, 2011 @07:51AM (#35805966)

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

        • If you REALLY want to fix it, add the things that are missing:
          Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.

          They didn't do that, but they did allow to provide concrete methods with bodies in interfaces, which makes them much more like mixins. This actually takes away most of the problems, since you're only restricted to classes for when you need state, and multiple inheritance for state is almost always a bad idea (in C++ as well). The reason why Java interfaces feel so limited in comparison is because they don't contain any code, thus artificially limiting code reuse.

          A c/c++ style macro compiler and #include system

          Gods, no. If you suggest adding a macro syste

        • Re: (Score:3)

          by roalt ( 534265 )

          The new assignment operator ":="

          Oh look, someone revived the Clipper dBASE compiler / Pascal syntax.

          This is called the becomes operator. I think it was introduced by Dykstra, a well-known computer science professor. The idea is that it is mathematical more correct than the equals (=) operator, as you can do: x := 3; x := 4; Personally, it's not my favourite (I prefer =), but I do think that it leads to less if(a = b) { ... } mistakes than using the = and == operators from the C language

        • Re: (Score:3, Insightful)

          by kaffiene ( 38781 )

          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 th

      • Re:Java killer? (Score:5, Insightful)

        by Mongoose Disciple ( 722373 ) on Tuesday April 12, 2011 @11:32PM (#35803414)

        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.

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

          Yeah, that would be bizarre, rather than cathedral, I guess. The church frowns on the wee folk.

    • Re:Java killer? (Score:5, Insightful)

      by ceoyoyo ( 59147 ) on Tuesday April 12, 2011 @10:53PM (#35803074)

      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? (Score:5, Interesting)

      by raddan ( 519638 ) * on Tuesday April 12, 2011 @10:53PM (#35803080)
      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 [wikipedia.org], yadda [wikipedia.org].

      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? (Score:5, Insightful)

        by cakoose ( 460295 ) on Tuesday April 12, 2011 @11:35PM (#35803446) Homepage

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

      • Having a VM that's not at the mercy of Oracle would, to my mind, be a huge plus. But Oracle's war against Google shows just how fraught with risk that could be.

      • Re:Java killer? (Score:5, Insightful)

        by shutdown -p now ( 807394 ) on Wednesday April 13, 2011 @01:07AM (#35804064) Journal

        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.

      • C# may be a good language but its libraries are truly awful in the sense they're simply not available everywhere (Mono's libraries are missing major chunks of functionality compared to the Microsoft set).

        Despite the supposed language shortcomings of Java (often criticised by those writing smaller programs or who don't realise that features like 'operator overloading' were deliberately omitted as practical experience showed them to be problematic) the language isn't that bad (especially if you have a large t

    • Re: (Score:3)

      by dmomo ( 256005 )

      JVM bytecode and Java's language syntax are two very different things.

  • Pointless (Score:4, Insightful)

    by steveha ( 103154 ) on Tuesday April 12, 2011 @10:57PM (#35803108) Homepage

    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. (Score:5, Insightful)

    by jensend ( 71114 ) on Tuesday April 12, 2011 @11:10PM (#35803216)

    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.

  • Missing feature in Java: Copy on write (Score:5, Insightful)

    by Michael Woodhams ( 112247 ) on Tuesday April 12, 2011 @11:46PM (#35803516) Journal

    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?

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

      You don't need the compiler to know about copy-on-write. To write a generic copy-on-write pointer class it is enough to have a compiler that knows about const-ness, as well as operator overloading that also allows overloading pointer operations (dereference..). Both features are available in C++, and in fact some implementations of STL string have used copy-on-write. Like reference-counting, performance becomes horrible with multiple threads because of the extra locks that are then needed.

  • Gratuitous differences (Score:3)

    by Compaqt ( 1758360 ) on Wednesday April 13, 2011 @01:45AM (#35804284) Homepage

    Why is that language designers feel they must come up with gratuitous differences to differentiate their babies?

    I'm talking about where keywords are used in the same (or much the same) way, but they've come up with something different after spending some time with a thesaurus:

    E.g., instead of Java "implements" for interfaces, you get "satisfies".

    abstract is replaced by "formal"

    "actual" means "override"?

    "public" -> "shared" : what's the value-add?

    "var" -> "local" : var types much easier.

  • Unleash the recruiters (Score:3)

    by codepunk ( 167897 ) on Wednesday April 13, 2011 @01:51AM (#35804314)

    Great, I expect a email from a recruiter tomorrow wanting someone with 10 years of production Ceylon experience.

  • Yes, but...probably no (Score:4, Interesting)

    by bradley13 ( 1118935 ) on Wednesday April 13, 2011 @04:26AM (#35805060) Homepage

    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?

    • You keep slapping on new features every time someone has a slight issue with the language and you end up with C++. Don't know what you think is awkward about Java exceptions and multiple inheritance was yanked from the spec for very sound reasons (ask a gray-haired C++ coder why). Java makes compromises (like primitives not being first class objects), but at least they were done with forethought.

    • Re: (Score:3)

      by SJS ( 1851 )

      Many of the "improvements" to Java were done without the thought necessary to make them work right, such as the Generics capability.

      However, I disagree about the problem of abstract static methods. I have come to dislike static methods and would prefer to see their use limited *further*, since much of the absolutely terrible code I've had to deal with over the years has been a result of the (ab)use of static methods.

      Many colleges teach Java as a good first language, as the perceived alternative is C++, whi

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close