Forgot your password?
typodupeerror
Java Programming

Java 8 Developer Preview Released 189

Posted by Unknown Lamer
from the now-contains-three-quarters-of-a-common-lisp dept.
An anonymous reader writes "Oracle has released the first developer preview of Java 8 for the full range of platforms (Windows, Max OS X, Linux, Solaris). Java 8 is a major update to both language and platform with Lambda expressions, method references, default methods, a new Date and Time API, Compact Profiles, the Nashorn JavaScript Engine, and the removal of the Permanent Generation from the HotSpot virtual machine. 'This milestone is intended for broad testing by developers,' Java Platform Chief Architect Mark Reinhold wrote on his blog. 'We've run all tests on all Oracle-supported platforms and haven't found any glaring issues. We've also fixed many of the bugs discovered since we reached the Feature Complete milestone back in June.' Let the bug hunt commence!" This is the second part of the JDK "Plan B" where JDK 7 was pushed out without cool new features like lambda expressions to prevent stalling language development for too long.
This discussion has been archived. No new comments can be posted.

Java 8 Developer Preview Released

Comments Filter:
  • Whew! (Score:4, Interesting)

    by inking (2869053) on Wednesday September 11, 2013 @09:39AM (#44818439)
    The fact that Oracle didn't find any glaring issues is hardly a surprise. A better question is whether they would fix them even if they did find them, like that rather glaring security vulnerability that they've just decided to brush off until their next major release last year.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      A better question is whether they would fix them even if they did find them, like that rather glaring security vulnerability that they've just decided to brush off until their next major release last year.

      The NSA told them they needed a little more time to break the new stuff.

      And as much as this is in danger of becoming a meme ... I'm afraid this is how we're going to have to increasingly view such things.

      Because on the topic of security, any US based company has completely ceased to be a trustworthy entity

    • by guru42101 (851700)
      After using JDeveloper and Oracle Middleware for the past 4 months my opinion of Oracle has greatly lowered. Not to mention the forms for EBS don't work with any Java after Oracle changed the vendor name. https://blogs.oracle.com/ptian/entry/solution_for_error_frm_92095 [oracle.com]
      • After using JDeveloper and Oracle Middleware for the past 4 months my opinion of Oracle has greatly lowered. Not to mention the forms for EBS don't work with any Java after Oracle changed the vendor name. https://blogs.oracle.com/ptian/entry/solution_for_error_frm_92095 [oracle.com]

        As much as I'd love to give Oracle hell over such a stupid mistake... the Eclipse Foundation (which includes contributions from the likes of Google and IBM) made the same mistake [infoq.com]... relying on the java.vendor field to detect which JVM is running.

  • by LordKronos (470910) on Wednesday September 11, 2013 @09:47AM (#44818507) Homepage

    So java now supports default methods for interfaces? In other words "we now support multiple inheritance". Or at least that's pretty close to it. I thought the logic was that multiple inheritance is messy when you have diamond shaped inheritance, or two parent classes that have the same method names, so java only did single inheritance, but then allowed you to do interfaces to sort of simulate multiple inheritance (except you had to write all the code). But with this change, it seems the same as multiple inheritance, with the exception that interfaces cannot include (non-static) variables, only methods. Am I correct here, or am I overlooking something?

    • I am also curious how they handle this. Before you could have multiple interfaces and It wouldn't matter if they all required you to have a specific method, because you had to implement it in the class (or parent). Now I'm not sure. Are they going to have a compile time error and require an annotation to tell us which to use if there are multiple? Has anyone tried this?
    • by mark-t (151149)
      The messiness of diamond inheritance is at least made unambiguous with the approach taken in Java8 in that a function implementation from a a superclass would be preferred to a matching function definition in an interface. Pretty much the way things are right now.
    • It's all discussed in the FAQ [lambdafaq.org].

      Summary: Java always supported multiple inheritance via interfaces, but it never supported multiple inheritance of state, and this situation continues with the current default methods feature. This is simply a new aspect of multiple inheritence in Java. This new feature does, however, does present the "diamond problem" for the first time in Java, but this is solved by simply disallowing ambiguous situations at the compiler level. Seems perfectly fine to me.

    • by JAlexoi (1085785)
      there are very strict limitations to the implementation. The concrete class hierarchy has the final say. Thus you can't provide default implementations of hashCode, equals and toString.
  • by Chrisq (894406) on Wednesday September 11, 2013 @10:01AM (#44818619)
    Having played with Java 8 I can see that it can be used in two ways. One is using a few of the enhancements but basically sticking to the procedural/OOP paradigm. The other is to incorporate the functional programming paradigm. I can see a lot of conservative Java teams just sticking to what they know - which will be interesting because at some point they will have a new developer start using the functional capabilities. I can see the culture clash, with the old team members saying "we can't support this" and the new members saying "but its more efficient and inherently more supportable as the functional paradigm uses immutable objects and avoids side-effects.
    • by ADRA (37398)

      Well frankly, "inherently more supportable" is 100% based on who is supporting the code. If you throw in the most elegant functional code on earth on a collage grad who's only learned OOP, then your code is going to have a bad day. Now imagine code where performance, and time trade-offs mean that the code isn't perfectly structured...

    • by gutnor (872759)
      Good thing is that it will deprecate Guava. Because young developers like their guava (for loops are fashion faux-pas nowadays), but it looks clunky compared to real support in the language.
  • by mark-t (151149) <markt@@@lynx...bc...ca> on Wednesday September 11, 2013 @10:25AM (#44818903) Journal
    I mean, I get that it's a lot simpler to define now, but I don't really get the point of adding such a major syntax-changing feature to the language for the sole purpose of syntactic convenience.

    I mean.... wasn't that their whole main argument against operator overloading? (the other argument, that operator overloading makes for unreadable code can be shown to be a red herring).

    • by abies (607076) on Wednesday September 11, 2013 @10:40AM (#44819039)

      It makes a huge difference in readability when transforming collections. Difference between (Xtend example)

      people.filter[age >30].forEach[println(it)]

      and

      people.filter(new Predicate1() {
            public boolean match(Person p) {
                return p.getAge()>30;
            }
      }).forEach(new Procedure1() {
            public void run(Person p) {
                  System.out.println(p);
            }
      });

      in readability and ease to write goes outside of what I normally call 'syntax sugar'. Going this way, most languages can be defined as syntax sugar over assembly...

      • Your Java example is needlessly convoluted. Most people would just write this, which is only a little more verbose than your Xtend code:

        for (Person p: people) {
            if (p.getAge() > 30) System.out.println(p);
        }

        • by abies (607076)

          OP asked why lambdas are better than anon classes. Example I gave is indeed simplistic and can be solved by snippet you gave - but as soon as you start adding some transformations, sorting, group by etc, plain java starts to be quite verbose. Still considerably better than 'functional' approach using anon classes of course.

          So yes, lambdas are of smaller use to people who are not using anon classes in first place and don't want to switch to functional approach. In java 8, main rationale for adding them was f

          • by mark-t (151149)
            Clearly, you only read the subject line of my post and not the body. The crux of my question was that if the significant syntactic convenience of operator overloading was claimed to not be a sufficient reason to add that to the language then why should it have been sufficient to justify adding lambdas?

            it's the inconsistency that I don't understand

            • I doubt there ever was an "official" reason for not having operator overloading except: they wanted the first Java compiler ready pretty quickly.

              OTOH it is not an inconsistency, its the insight of being now something like 10 years in the future versus the time when Java 1.0 / 1.1 was made public.

              However it is still annoying that we still have no operator overloading.

              • by dkf (304284)

                However it is still annoying that we still have no operator overloading.

                It's very easy to go horribly off the rails if you start overloading operators (or declaring completely new ones!) so if you're going to propose it, for goodness' sake do it by requiring people to implement a proper mathematical structure (e.g., a group, a ring or a field).

                • There are hundreds of uses for operators outside of the field of math. (E.g. adding an element to a list with + and removing it with -)

                  And frankly I would be already glad if we had operators for BigDecimal. Nearly every business application I worked with the last years ONLY uses BigDecimal. It is so annoying to have to write 5 lines of method calls when a simple READABLE result = input * hoursADay * 4 * daysOfYear * pricePerGwh would be sufficient.

            • by abies (607076)

              You need lambdas to do parallel transformations on collections in sane way. Java is claiming to be THE language for mainstream parallel programming (doesn't matter if it is actually valid, but Oracle sells it this way), so they need lambdas.
              You need operator overloading to do non-trivial math programming in sane way. Java was never sold as number-crunching platform, so there was no push from within Sun/Oracle for that.

              • by mark-t (151149)

                Whether or not Java was billed as a number crunching platform doesn't change the fact that such number crunching can often be fundamental to the underlying model to some pretty common and often surprisingly useful stuff, especially in the realm of computer graphics, but it arises in a handful of other domains as well. This phenomenon occurs as often as it does because at it's core, all computer programs *ARE* just math.

                Or are you suggesting that Java wasn't ever supposed to be used for doing computer

    • I don't really get the point of adding such a major syntax-changing feature to the language for the sole purpose of syntactic convenience.

      While there are definitely a lot of judgement calls and tradeoffs to consider when designing a language, syntactic convenience is a big part of why we use programming languages to begin with.

      I mean.... wasn't that their whole main argument against operator overloading? (the other argument, that operator overloading makes for unreadable code can be shown to be a red herring).

      As you indicate, the operator overloading argument was/is bogus. I suspect that everyone tried to misuse the feature when it was introduced with C++, in much the same way that everybody used a dozen different fonts the first time they ran a WYSIWYG word processor. The people who got bit by this bad code went on to wr

    • I use them to reduce bugs, for example, it's not uncommon to have a two-line piece of code that you want to apply to two different variables. Something like this:

      height = x * scaleFactor / screenSize + translation;
      width = y * scaleFactor / screenSize + translation;

      With lambdas you can combine the calculation into a single function, and reduce the duplication (reduced duplication reduces the chance for accidental typing bugs). Of course you could move it into a normal function, but then you have a two
    • by ndykman (659315)

      It's not just syntactic convenience. Lambdas represent closures, which have different scoping rules and variable capture rules. For one, lambdas just use lexical scope and don't introduce a new scope (which anonymous classes do. Because they are classes).

      They can capture certain variables in the scope that anonymous classes can't. It's a bit complex, but lambdas can capture variables that are effectively final, before, it has to be declared final.

      Here's an example. Imagine you are in a method of class, y

      • by cecom (698048)

        Sadly you are wrong. Java8 lambdas offer nothing over anonymous classes because, unlike C#, they only capture read-only variables, exactly as do anonymous classes. It is a sad joke.

        • Java8 lambdas are significantly more concise. And yes, syntax does matter. If it didn't, we'd be writing things in some dialect of COBOL.

          • by mark-t (151149)

            And using custom overloaded operators for appropriately defined classes that mimic ring or group-like structures is significantly more concise than calling named methods, and reads much more intuitively.... yet the syntactic convenience of such notation is not considered sufficient merit to add it to the language.

            Yet somehow the syntactic convenience of lambdas is considered sufficient merit over anon classes to add that.

            Go figure.

            • I totally agree with you that all the reasons that Java designers ever gave for not including overloaded operators can be concisely summed up as "bullshit".

              Even more so in a language that doesn't even have a built-in operator to meaningfully compare two strings for equality - or any other concise way to compare two String objects (at the very least, without repeating either comparand), accounting for any combination of nulls.

              Then again, I'm a C++/C#/Python guy, so what do I know?

              • by mark-t (151149)

                On the subject of operator overloading, having to call isEquals instead of using an operator like == to compare Strings is one characteristic of the language that never really bothered me in the slightest... but that may be only because it reads like what the function is actually doing, (that is, it seems fairly obvious to me from the name itself that it would test for equality between the object and the parameter to the function, and not do anything else).

                But having to type somethiing like a.plus(b).ti

  • learning from JavaScript ;)
    • by Lennie (16154)

      And they also included a Javascript engine, I wonder if the JVM people come up with something new which will boost Javascript performance in ways the browser developers haven't yet. Javascript performance improvements haven't stalled yet (asm.js was an interesting approach), but others people looking at the problem could produce interesting results.

  • by snsh (968808)

    Will this release of Java come with an Ask.com toolbar, a Yahoo.com toolbar, or a Google toolbar?

    • Will this release of Java come with an Ask.com toolbar, a Yahoo.com toolbar, or a Google toolbar?

      Yes.

      Wait, I thought you said "and"

  • I am surprised at the backlash about adding lambdas and some associated features (default methods) that support a more functional programming style.

    Firstly, lambdas aren't just anonymous class syntactic sugar, they work differently. Hence, new syntax, that just happens to be more concise. Lambdas and closures are as old as the hills, this isn't some trendy new language feature that hasn't been well thought out.

    And, yes, for loops are enough, we know this. But conciseness can help. I have a list of orders,

    • Actually, in Java8, lambdas pretty much are syntactic sugar for anon classes. They still can't capture non-finals from the outer scope, so there's literally nothing that you can do with a lambda that can't be done with a mechanical transformation of that lambda to an anon class. It's not like C#, where lambdas are true closures that can capture and mutate locals.

      But then, syntactic sugar can be a deal-breaker. This is one of those cases. And they're also adding all the LINQesqe stream stuff to the standard

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...