Java 8 Developer Preview Released 189
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! (Score:4, Interesting)
Re: (Score:2, Insightful)
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
Re: (Score:2)
As long as Larry keeps getting paid well by the TLAs, he'll keep giving them first access.
Re: (Score:2)
Re: (Score:2)
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.
default methods for interfaces (Score:4, Interesting)
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?
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Explained here:
http://stackoverflow.com/questions/16764791/how-does-java-8-new-default-interface-model-works-incl-diamond-multiple-inhe [stackoverflow.com]
Basically it's a compiler error.
Re: (Score:3)
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.
Re: (Score:2)
Re:default methods for interfaces (Score:4, Interesting)
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.
Re: (Score:2)
I think the thought is that "if it does break then it will be a compile-time error rather than a run-time error." The latter being more costly to determine the cause of.
But this still seems a bit of a hack to me...
Re: (Score:2)
There can't be a run time error.
A run time error would require that there is code that actually calls the method.
That on the other hand would mean: the method already existed in the old code. And that means the behaviour of the class is unchanged. (interface changed and added the same method the class is already implementing, regardless whether there is a default implementation or not, it would work fine).
Re: (Score:2)
There can't be a run time error.
A run time error would require that there is code that actually calls the method.
That on the other hand would mean: the method already existed in the old code. And that means the behaviour of the class is unchanged. (interface changed and added the same method the class is already implementing, regardless whether there is a default implementation or not, it would work fine).
But it's not problem free. So you have class X, which implements interfaces A and B. Interface A has function Foo, so class X implements function Foo. Everything is fine and dandy. Now it's the future. Interface B has been upgraded to also have function Foo, and given a default method so as not to break existing code. If you recompile it, as you said, it will work just fine since you've got an implemented method, thus no conflict. So now you pass an object of X to a function called DoSomethingWithB that exp
Re: (Score:2)
So now you pass an object of X to a function called DoSomethingWithB that expects a B object as a parameter.
Then you should have read the documentation about this function. After all you craft the code which calls this function AFTER you have upgraded your B.
And like I said, how does the code even know if the caller is trying to call Foo on an A or a B object? :D The caller is always calling on an B
The caller is always calling on an A object. As B just an interface and no class.
Or put it other way around
Re: (Score:2)
Java developers tend not to have issues with future proofing for new functions in interfaces.
Re: (Score:2)
java.lang.String. java.util.Date. java.util.Math. These are what did it for me. Re-learning every client's own "string" class in C++, it's nuances, what it got wrong, etc. Not to mention date handling.
The STL was too little too late for these things.
Re: (Score:2)
C++ lost the language war because it runs in an unmanaged environment without garbage collection.
C++ lost the language war because it takes two hours to compile something that takes two minutes in Java.
Managed environments and garbage collection are not benefits to programmers who know what they're doing, and are huge sources of bugs from programmers who don't. Like not bothering to close files when you're done because 'the garbage collector will handle it', and then running out of file handles. And let's not forget the joys of writing everything as XML files that use reflection to hook in classes at r
Re: (Score:2)
you have no idea what the code does when you look at it.
You've got that problem in C++ too, except that's with thanks to the fun world of custom operators and the world's most confusingly complex template system. The biggest single issue with Java is that it's officiously bureaucratic to the point of insanity. It does make it relatively easy to read someone else's code though, which isn't a charge often levied against C++ in my experience.
Re: (Score:2)
No, it's really not. C# extension methods are nothing but syntactic sugar for static method calls - they're always compile-time resolved and are not overridable, and they cannot be used to actually extend an interface - only to add convenience methods to it that are always implemented in terms of other methods.
OTOH, Java 8 default methods are true interface methods that just happen to provide an implementation for you if you don't have one. But they're overridable just like any other interface method.
Conservative Java teams will find it "interesting" (Score:4, Interesting)
Re: (Score:2)
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...
Re: (Score:2)
What do lambdas provide that anon classes do not? (Score:4, Interesting)
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:What do lambdas provide that anon classes do no (Score:5, Insightful)
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...
Re: (Score:3)
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);
}
Re: (Score:2)
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
Re: (Score:2)
it's the inconsistency that I don't understand
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re:What do lambdas provide that anon classes do no (Score:4, Insightful)
On the contrary, GP nailed it. When you start extending and composing and declaring too much, you lose the impressive and straightforward readability of GGP's example and end up with write-only code like Perl (to many people who are less capable than you).
If you're smart, functional programming is quite fun. If you have to work with someone who is, um, less smart but still forced to write functional code in your shared project, God help you man.
tldr; we don't all work in the upper echelons of the programming world
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
Java... is now.. (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
They had a JavaScript engine in the standard library for ages. This is just a better one.
Re: (Score:2)
Lambda expressions have been around since the 1950's. Most people haven't liked them. I don't find them inherently any better than any other approach, but they have different strengths. (OTOH, you can prove that anything Turing complete is, in a way, equivalent to anything else that is...)
To me short lamda expressions are OK. Longer ones are iffy, and ones over about 7 expressions long should be done some other way.
FWIW, to me the best concept of OOP was encapsulation. The best concept of it's predeces
toolbar (Score:2)
Will this release of Java come with an Ask.com toolbar, a Yahoo.com toolbar, or a Google toolbar?
Re: (Score:2)
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"
Functional Programming Isn't Scary. Is it? (Score:2)
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,
Re: (Score:2)
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
Re: How about... (Score:5, Insightful)
Those issues weren't with the language or the vm. They were with applets, which are a shitty deprecated part of the runtime that should be removed.
Don't break the web. (Score:3, Interesting)
Re: (Score:3)
http://www.w3schools.com/vbscript/ [w3schools.com]
Yes, don't break my VBScript support or else!!!
Re: (Score:2)
Why would Java devs need to tell that to JS devs? JS devs who aren't abstracting everything away with libraries like jQuery already know this.
I can think of a handful of languages WTFier than Java and JS is on that list.
Re:How about... (Score:5, Funny)
No one appears to be answering the really important question:
Which shitty toolbar(s) will this come bundled with?
Re: (Score:2)
...and how many updates can we expect to have to manually install over the next year if we administer a few dozen machines?
Re:Too late (Score:4, Insightful)
Really? Java is still the #1 language and will remain so for a long time to come. The toddlers will use the supposed hip languages all they want meanwhile most other devs are just using Java and solving real problems.
Oh and Java uptake is usually 1 to 2 years not 4.
Re: (Score:2)
Java uptake is usually 1 to 2 years not 4.
Wow, nice. 1 to 2 years wouldn't be so bad.
Working at a bank, we were still stuck with Websphere 6.0, and thus JSE 1.4, around the time JSE 1.7 was released.
Websphere 6.1, with JSE 1.5 support, was available from 2007, about 4 years after 1.5 was released, iirc, but such an upgrade has so much (potential) impact that some corporations take several years to do it.
Re: (Score:2)
I've done some hardware upgrade projects at banks. CPUs, printers, MICR readers, and so on. Some of the places still run Windows 2000 on the desktops. Considering it is only a launchpad for the teller application, I guess it doesn't need the newer bells and whistles beyond network printing.
Re: (Score:2)
Sorry to hear that. Were in healthcare and were on Java 7 and we'll be on Java 8 in the new year.
Re: (Score:2)
'Usually' really depends on company. I had to fight very hard battle to use something newer than 1.4 in 2007/2008 and then witnessed slow upgrade of 1.5 to 1.6 in 2012 in different company. In both cases, these were big, serious companies, eventually running billion-dollar businesses on java apps in question. So reality for me is that I might see java 8 in production use somewhere in 2017 if I'm lucky. But given current tech direction of the company and fact that over last 1-2 years, thousands of people wer
Re: (Score:2)
I can confirm that Java "uptakes" are often far over 4 years.
The energy company and bank I worked for the last 10 years where really slow in upgrading to recent Java versions.
Regarding "toddlers" and "real problems" .... one reason to use a more recent programming language is: to be faster in development because it is more expressive, write _less code_ so you need _less tests_ and bottom line _less time_
As far as I know this are "real world issues".
Re: (Score:2)
Yeah except development costs are peanuts compared to *maintenance* costs.
Re: (Score:2)
Which are less too, if developers use the new language features rather than abuse them.
Re: (Score:2)
Well developed software has low maintenance costs.
And using the right features of the language for the right things help in that.
But do not fear: the whining about new features in your favorite language is as old as the era of software development with high level languages. And whining about new languages is just the same ;D
Re: (Score:2)
I can confirm that Java "uptakes" are often far over 4 years.
We were stuck on 1.4 for development of one of our flagship applications for ages just in case one of our users hadn't upgraded this millennium. Yuck (especially as 1.4's support for things like XML handling was a Special World Of Pain). Mind you, we're on 1.6 now and are transitioning to 1.7 probably this year; the large ZIP support is the killer feature that makes the upgrade pain worthwhile (YMMV; we're working with rather large data archives).
Re: (Score:2)
There is nothing wrong to keep stuff around "just in case".
However that needs to be done "right".
That means: you need the complete software and hardware (at least as an VM configuration) to reconstruct the old system. And that means perhaps even running Windows NT from 2003 with the clock set back to 2003) and having an old office version from that time etc. etc. (in case you used some Java code to create Excel files, or read excel files that contain system configurations).
And god forbid you *only* have all
Re: (Score:2)
Really? Java is still the #1 language and will remain so for a long time to come. The toddlers will use the supposed hip languages all they want meanwhile most other devs are just using Java and solving real problems.
I used to say something like that about Perl, and now I'm a Java developer.
Re: (Score:2)
Really? Java is still the #1 language and will remain so for a long time to come. The toddlers will use the supposed hip languages all they want meanwhile most other devs are just using Java and solving real problems.
Oh and Java uptake is usually 1 to 2 years not 4.
I remember when Java was the language for "toddlers."
Careful with your over confidence.
Re: (Score:3)
The one key to Java that most people don't seem to understand is that its designed for longevity. It was one of the first massively used languages to come with a functional style guide, for example. If you're not going out of your way to obfuscate it, Java is very easy to read. Almost any Java developer can drop into a brand new codebase and read new Java code and know what's going on.
You need to have gone through that a few times in other languages to really appreciate how damned rare that is.
Are there
Re: (Score:2)
The lead developer on Java generics was Neal Gafter, not Martin Odersky.
Re: (Score:2)
My main concern here is not that it's too late—if it's useful, I'd like to be able to use it. But based on Oracle's history with Java, I'm really reluctant to place my eggs in this basket. I'd rather use something that isn't going to give me licensing whiplash two years down the road when the marketing strategy shifts again.
Re: (Score:2)
In what sense is this FUD? Please, reassure me. I would love to be able to trust that there is nothing to worry about here.
Re: (Score:2)
My favorite one atm is Xtend. It has none of the disadvantages you mentioned above, but removed most annoying 'celebration' from java code.
Re: (Score:2)
Googled Xtend for more info... what an unfortunate name they have for the language.
Re: (Score:2)
Too late, as in 'look at C#'
Java had a problem with the JCP not working, then the Sun to Oracle transition, and Apache getting elbowed out. It's a miracle a new version even came out in the first place.
C# never had a community process to worry about, and moved forward all the time. It has had closures, lambdas, function points etc. for quite a while now.
Re: (Score:2)
However, the versions of C# that implement those are (realistically) Windows-only. With the slow but steady increase of alternative OSes, and the fact that Windows is far from dominant in server-space, Java still has plenty of room to swing.
Re: (Score:3, Insightful)
Re: (Score:2)
You can still define one single function/method for what you want to d and create a lamda that simply just calls that single method ...
Re: (Score:2)
Re: (Score:2)
To reuse the code in the function :D as my parent wanted so badly.
I guess if you don't have a few bytes for more stack in this situation you have other worries
Re: (Score:2)
The point of lambdas is not to replace named functions. It's to open up a whole new facet of API design that does not require you to write named functions in the first place, which is much better generalized. This leads to better code reuse (because you can now write a more generic HOF method parametrized with a function, and provide that function as a lambda at every distinct call site).
Re:Oh Yeah! (Score:4, Insightful)
People that complain about code features are generally ignorant of how to use them, and thus spread FUD about them.
Lambdas are a great powerful feature when you really don't need to write a full fledged function. In combination with something like multithreading, being able to write an off-thread lambda in-place is quite powerful, it's actually easier to maintain a thread that is set up, starts and is monitored all within the same functional block, rather than writing a bunch of support functions to start, stop and monitor the thread throughout a class or spread across many classes or files. Another key win for Lambdas is being able to write a predicate for a sorting function without having to reference some function somewhere down in the file.
Yes, like EVERYTHING in code, lambdas can be abused, but generally speaking lambdas are not significantly more complicated to understand and manage, if you are not a complete software noob. This is why senior developers should guide juniors and intermediates using code review to the correct use of code features rather than to simply encourage not to use a feature out of fear and ignorance.
Re: Oh Yeah! (Score:3)
Take a look at Objective-C's blocks and how they are typically used. Pass a block to a method that runs async on another thread and calls your block when it's done. Sure, you could write a hundred one-off little functions to pass off to different requests, but it's simpler and easier to follow blocks. Why? Because you (can) define the block inline to the method call which will call it. Now you can look at the call site and the code that it will execute on completion, all in one place.
Re: (Score:3)
It's ironic how you inadvertently gave the perfect example of what GP was talking about.
Where's the vector sort function? Why, it's on the vector itself! Now that high-order functions and lambdas are there, vectors can provide a generic sort function which takes another function specifying the sort order. Since that would be extremely verbose if you only had named functions, you use a lambda to specify the order at call site.
Specifically, using Java 8:
Re: (Score:2)
Re: (Score:2)
Who's their?
Re: (Score:2)
Re:A Joke (Score:5, Insightful)
The 1990's called - they want their joke back. #tiredmeme
Modern JVMs are fast enough, most people can't tell the difference between them and pure native code.
Re: (Score:3, Funny)
Did you warn them?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
IBM has a lot invested in Java. I wonder what their contract or rights to Java are . . . ?
Re: (Score:2)