Forgot your password?
typodupeerror
Java Programming

Everything About Java 8 233

Posted by Soulskill
from the building-a-new-generation-of-security-holes dept.
New submitter reygahnci writes "I found a comprehensive summary of the developer-facing changes coming in Java 8 including: improvements to interfaces, functional interfaces, lambdas, functions, streams, parallels, date/time improvements, and more. The article includes example code with realistic examples of use as well as explaining the reasoning behind some of the choices made by the developers who are working on Java 8."
This discussion has been archived. No new comments can be posted.

Everything About Java 8

Comments Filter:
  • by PhamNguyen (2695929) on Wednesday March 27, 2013 @05:32PM (#43296849)

    Highlights of Java 8 include

    Green solutions. Advanced power management features, and automatic tracking of each thread's carbon footprint. An console allows users to see the carbon footprint of each thread in real time.

    Social networking. Users can share jar files on social networks, and like their friends jar files.

    Cloud computing. Java 8 will be the first VM built for the cloud.

  • Changes (Score:4, Interesting)

    by phantomfive (622387) on Wednesday March 27, 2013 @06:21PM (#43297445) Journal
    There is a real, major benefit of using Java over other languages, such as C or Haskell or Smalltalk, which is this: it lets you work with other mediocre programmers, and has limitations that prevents them from doing anything too crazy. That is, even if they write horrible code, it won't be so bad that you can't work with it (I'm sorry fellow Java programmers if that offends you, but think of where Java is used most).

    That said, I'm somewhat concerned about some of these changes. Lambda functions are great, but one of the benefits of functional programming is the lack of side effects. Under the Java 8 design, lambda functions allow you to modify member variables, which means that benefit is completely gone. This means lousy programmers will be able to write incredibly complex code, with strange side effects, that is hard to use.

    The new streams functionality is fine, but did they really have to call it streams? When there are already Streams in Java?

    String.join() is great. Finally.

    The new Date library looks fine. It better be good enough, because do you really want yet another Date system added into Java?
    • Most decent Java programmers have been using Joda for years. This is just bringing in something that is standard practice.

      • by KZigurs (638781)

        Uhm. I think I'm a decent Java programmer and I haven't bothered to use Joda ever. Not every problem involves handling dates.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Lambda functions are great, but one of the benefits of functional programming is the lack of side effects

      What people want is to pass a callback to something and then play with members from within the callback, and do so --> WITHOUT <--- having to create a single use method with some pathetic name in some other place inside the class. Your supposed 'benefit' is exactly the opposite of the intent. ECMAScript 6 specifies 'fat arrow' functions for the same reason; lambda's that easily expose the outer context to the body of the lambda so we can all stop doing var that = this.

      Lambdas are perfectly legitimat

    • by devent (1627873)

      This is what I like in Java in comparison to other languages: the language moves slow, the JDK moves slow, but you have for everything open source libraries and tools. Unlike C or C++ I can mix those libraries without any hindrance, because the basic types are fixed in the Java language: String, primitives, etc.

      Call me old-fashion, but I like that the language is evolving slow. In Java I can use Groovy, Scala, Python, Ruby, JavaScript, etc. if I want "modern" features, like closures, lambdas, etc. Plus I ha

      • My wish list would be: more polish for Swing, new widgets in Swing, faster JVM, smaller JVM,

        Yeah, now those are some real changes that would be more practical.

        • by stenvar (2789879)

          Yeah, now those are some real changes that would be more practical.

          People have wanted that for more than a decade; don't hold your breath.

      • by stenvar (2789879)

        Call me old-fashion, but I like that the language is evolving slow

        Java has been evolving quite rapidly, with major new language features in every major release.

    • by Hentes (2461350)

      I agree. An often overlooked thing in language design is that less functionality leads to more standardized code that's easier to read. When I want to use complicated languages there's already a wide selection available.

  • as all it seems to be doing now is playing catchup to something like Scala which has at least thought out the functional stuff maybe a bit more

  • Project Lambda from what I have gleaned has as its goal not necessarily feature parity with other programming languages, but instead speeding up certain multicore computations. It is therefore an experiment, and as its coding is not done yet, no one can be sure whether the experiment will be a success. What if the speed-ups simply don't happen once the implementation is finished? Given that Project Lambda may already be delaying some of Java 8, even though it was supposed to be the focus of Java 8, why c
  • Ever since autoboxing was added, it's already implicitly overloading operators for all of the object wrappers around atomic types anyways, and it's always implicitly overloaded the + operator for the String object, so the objection that it adds complexity should not be an issue. The only real remaining objection about unreadability that always seems to arise when the subject of operator overloading on user-defined classes is raised is actually entirely isomorphic to complaints about function or variable naming practices where the identifer's name doesn't effectively convey any sense of what the identifier's real purpose is... Java doesn't stop a programmer from using global class name like qxj, for instance, so it makes no sense to prohibit operator overloading merely on the suggestion that the resulting program is harder to read or maintain (and even then, such an identifier may even have a legitimate purpose in certain contexts.... but then, so can operator overloading, which is my point)
  • by rubycodez (864176) on Wednesday March 27, 2013 @08:53PM (#43298647)

    does it break backwards compatibliity with 7, like 7 did with 6?

    that's been one of my major gripes about Java, write once, run anywhere until the jvm version changes, then you can be screwed.

No amount of genius can overcome a preoccupation with detail.

Working...