Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Details of Oracle's JDK 7 and 8 'Plan B'

Posted by Soulskill on from the division-of-labor dept.

gkunene writes "Oracle has put Java 7 and 8 features up for Java Community approval, providing a clear indication of what the next two major versions of Java are likely to include. (Java 7 contents, Java 8 contents.) From the article: 'The JDK 7 and 8 JSRs represent Oracle's 'Plan B' approach for separating JDK 7 into two separate releases, splitting up features that were all originally intended for the Java 7 release. This approach is intended to help expedite new Java releases. Among the key components of the original Java 7 plan that are now set for inclusion in Java 8 are the Lambda and Jigsaw efforts. At JavaOne this year, Thomas Kurian, executive vice president, Oracle Product Development, explained that Lambda is all about bringing closures to the Java language. Kurian noted at the time that Lambda is intended to provide a more concise replacement for inner classes, as well as support automatically parallel operations on collections. Jigsaw is all about building modularity into the Java Virtual Machine.'"

19 of 204 comments (clear)

  1. Java Community approval by jrumney · · Score: 3, Insightful

    Is there still a Java Community left to approve this? I thought Oracle had managed to alienate them all over the past 6 months.

    1. Re:Java Community approval by matfud · · Score: 2, Insightful

      Yes I have pushed java to it's limits. It mostly works. There some nasty things that will get you but trivially avoidable. When you have to put it on various machines it does just work. HP/UX I have not yet encountered.

      Matt

    2. Re:Java Community approval by Chris+Walker · · Score: 2, Insightful

      No. Learn as many languages as you can. You're less likely to believe that one language fits all needs that way. Java isn't going to suddenly drop out of use, there is too much investment in it.

  2. Re:lifecycle? by h4rr4r · · Score: 2, Insightful

    Considering COBOL still has a presence in the Enterprise world I really doubt Java will go away that fast. If they went maintenance only today, maybe in 10 years it would start to be phased out in the Enterprise and maybe gone in another 25 years.

  3. Closures? by Anonymous Coward · · Score: 2, Insightful

    I think the focus on closures is a fad. The concept has existed for decades, but suddenly if Java doesn't have them it's incomplete? Strangely, I don't think the lack of them has ever stopped a program of mine from working. So this seems like more of a pissing contest with C# than a feature anyone is really clamoring for.

    1. Re:Closures? by Anonymous Coward · · Score: 1, Insightful

      yep, a fad that's existed for decades.

    2. Re:Closures? by jernejk · · Score: 2, Insightful

      Way back in the '90s, MS wanted to enable developers to use Java to write Windows apps.

      Really? I was around int the '90s and have no recollection of that.

      As a result, MS needed to write their own Java-like language for VB-style form designer apps, and came up with C#.

      Please, don't be naive. MS first tried to poison Java by proprietary API (the same tactics Google is using in Android). When they failed, they created a copy of Java, invented a "new" language which is for some reason unbelievable similar to Java + some nice features and started the "developers, developers, developers" mantra. They called .net "java killer" internally, BTW.

      Java was and still is a major risk for Microsoft.

    3. Re:Closures? by TheRaven64 · · Score: 2, Insightful

      Closures and objects are identical in terms of the things that they can express. See the COLA papers from VPRI for some good examples - you can trivially implement anything using closures that you can implement with objects, and vice versa. Objective-C has used higher-order functions for decades without closures. They do make some things a bit cleaner, syntactically (although Apple's syntax is horrible), but if you can't live without them then you have problems.

      --
      I am TheRaven on Soylent News
    4. Re:Closures? by Haeleth · · Score: 2, Insightful

      Closures and objects are identical in terms of the things that they can express.

      Any minute now someone is going to bring up Turing completeness and point out that in theory you could write any program in Brainfuck. And someone else is going to point out that closures in languages like C# are objects, just hidden behind some syntactic sugar. No, wait, I just did both myself.

      The point is that for certain common patterns, such as event callbacks, a closure-like syntax is significantly more readable than a conventional object type syntax. Computational equivalence is an academic question. In the real world, the question is how efficiently code can be written and how reliably it can be maintained, and in that regard there is often a real benefit to reducing boilerplate code.

  4. Elephant in the room? by oldhack · · Score: 5, Insightful

    Fix the generics. Get rid of erasure and all its associated idiosyncracies and gotchas, and bring generics properly into JVM level.

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. Re:Elephant in the room? by Haeleth · · Score: 2, Insightful

      He also observes that reified generics would probably make Java itself a better language, and would be useful for Scala too. Which between them account for practically everyone using the JVM in the real world. Is it really worth hurting the vast majority of people (and driving some of them to competing platforms), in order to benefit a handful of tiny niche products?

  5. Why the fuck bother by melted · · Score: 2, Insightful

    Just take this call it Java 9 or some such, and fire the remaining Java compiler people. Keep the VM people. There, solved it for you Oracle.

    1. Re:Why the fuck bother by Anonymous Coward · · Score: 1, Insightful

      Scala is not a maintainable language. Don't get me wrong, it's very cool and interesting but I have written code that I can't even decipher myself only a couple weeks later. It's too flexible and allows some really bizarre syntax and architecture. I would say it's worse than Perl and Lisp at being way too easy to create "clever" program designs that nobody can maintain.

      Google Go seems like it has a better chance even though I doubt it will gain a foothold either.

    2. Re:Why the fuck bother by Xrikcus · · Score: 3, Insightful

      And who didn't have to deal with backward compatibility. Designing a language from scratch is a completely different problem from evolving one that's heavily used.

    3. Re:Why the fuck bother by Alkonaut · · Score: 2, Insightful

      Sack the VM people too, at least those who decided that the implementation of generics should be through type erasure, in other words "type unsafety". Next, dismantle the whole community process (Whoever wants an open system please fork at this exit). If Oracle just puts its weight behind java, it could well be the needed injection it needs. Without the tools for parallelism, distributed computing and so on, java (both VM and language) will be a "mainframe" language.

      C# shows what can be done if you have
      a) lexical closures
      b) VM-level generics
      c) A process where the language evolves faster than through a vote by UN+dog.

      If oracle just makes Java the "other" .NET, it will be useable, but as a commercial second fiddle, it will probably be irrelevant.
      If oracle does not make java the other .NET, the slow community process will make the language irrelevant within 5 years anyway.

      So of the 3 topics here (Language, VM, Process) the language is the least important for the future of java.

    4. Re:Why the fuck bother by TheSunborn · · Score: 2, Insightful

      They reason they did implement generic with type erasure (Something they knew was not the best solution) was so you could compile your Java 1.5 code, and run it on a jdk1.4 stack which don't know anything about generics. (They did not want to update the bytecode format, and with that restriction, type erasure was the only solution). So it was more of a management choice.

      Why sun thought this was a better solution, then updating the bytecode is something I don't understand.

  6. Re:Go Java Go by chthon · · Score: 2, Insightful

    For a growing complexity in a certain problem domain, the border between configuration and the creation of a domain specific language becomes rather thin.

  7. Re:Go Java Go by logpoacher · · Score: 2, Insightful

    Definitely. We used to call it "PPL" - Property-file Programming Language - the tendency for simple name-value property files to acquire strange little bespoke syntaxes and nesting structures. The question isn't whether you will do it - it's how soon you face it and how elegantly you'll achieve it.

  8. Re:One area in which I appreciate the Java's power by Anonymous Coward · · Score: 2, Insightful

    Java can never start as fast as C or C++, it cant be done. I needs to start all kind of housekeeping threads, and allocate different memory pools etc.

    But it is true that in a theoretical reasoning that Java execution speed can be faster then C++, and thats cause the JIT may rearrange and optimize the bytecode during runtime, to take advantages of a specific hardware in a way that you may not do in C++.

    More often It goes slower tho, cause we all know when we stop coding features in, its when the good cases goes through. Why would you continue then? The JIT works and that's about it. It has some optimizations thats cool, but I'm not sure it such a huge feature for selecting Java over C++.

    The reason for selecting Java over C++ more tend to be that its like writing Object Oriented Basic, Java is simple. C++ is a bullet in the foot compared.