Java 8 Developer Preview Released

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.

Whew!

[inking]

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.

Don't break the web.

[Bradley Meck]

Java devs tell this to JS devs a lot. You must fix your problem without changing anything. Warts must stay.

default methods for interfaces

[LordKronos]

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?

Conservative Java teams will find it "interesting"

[Chrisq]

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.

What do lambdas provide that anon classes do not?

[mark-t]

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

Re:default methods for interfaces

[LordKronos]

Currently (build 106), if you have two interfaces with with default methods with the same signature, the class implementing the two interfaces won't compile.

You'll get:

class {ClassName] inherits unrelated defaults from [methodName] from types [interface1] and [interface2]

To fix the class, you need to implement the method.

So, first of all, that means that default methods doesn't 100% fix the problem it was intended to fix. Namely that existing code would break if new methods were later added to interfaces, as that existing code would not have an implementation. It's still possible that adding new methods to an interface could break existing code, but probably a lot less likely. I assume they'll take care in future releases to make sure they don't modify existing interfaces in such a way as to break anything using the standard library, but that may not hold true if you use any code libraries from a 3rd party.

The other thing is, I don't see how this is a whole lot different from just allowing multiple inheritance but requiring the derived class to override to resolve the ambiguity up front (rather than the C++ method of letting the caller resolve the ambiguity). And I'm actually curious how Java will allow this to be resolved in the derived class. If you implement interfaces A and B, which are completely different from each other and both implement method Foo for completely different purposes, then using the C++ method, it's easy to call object.A::Foo when you are trying to treat the object as an A, and likewise for B. But with java, will the overridden function C.Foo be able to know when the caller was treating the object as an A vs a B? If not, then it's sort of difficult for the class to know how to properly resolve these sorts of conflicts.