Slashdot Mirror
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.
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.
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.
Mod me down, my New Earth Global Warmingist friends!
Java devs tell this to JS devs a lot. You must fix your problem without changing anything. Warts must stay.
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?
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.
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.
Yeah, the fascination with lambdas makes my cranium throb. The garbage was bad enough in javascript, but now they are chucking them into every language. Screw defined functions! Let's just have partial functions jammed into the middle of other functions! Then we can copy and paste them all over the place and just change the one line/variable that needs changing to make it relevant to that block! Shit on proper code reuse and declaration! All we need is for every variable type to be a variant type on the back end and we are set!!!
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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).
File under 'M' for 'Manic ranting'
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.
I haven't thought of anything clever to put here, but then again most of you haven't either.
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...
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.
No colour or religion ever stopped the bullet from a gun
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 write best practices and coding standards that breathlessly prohibited operator overloading and Java followed suit. So you have dumb things like == testing for reference equality of strings, Vec3D classes that you must .add() and .subtract() instead of + and -, and naturally-ordered things that you can't compare with < and >. Hopefully one day Java will reverse this bad decision too.
-1, Too Many Layers Of Abstraction
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);
}
Did you warn them?
Scale your application enough... The difference might bite you. But yeah, it's not as it's used to be.
uhm...
No one appears to be answering the really important question:
Which shitty toolbar(s) will this come bundled with?
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
Do you mean to ask if you can manipulate the UI from any thread? Then no. There's really little point anyway, it's so easy to just enqueue an anonymous Runnable into the EDT. If it's changed to be "thread safe" then all swing projects will become unmaintainable.
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.
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.
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 things that they could and should fix? Absolutely. They could actually be done very easily. Allowing some type inference the way that Scala does (only when there's only one option) would be a good start. Better support for small anonymous classes would really add a lot of functional capabilities at very little cost. Property access to javabean standard getters and setters would eliminate tons of IDE generated crap while still allowing overrides. That would cover quite a lot.
As languages go though, you can actually use even Java 1.6 to build out things like JSON-backed RESTful APIs that talk to databases and queues spending 98% of your time writing business logic. For most real-world problems its hard to get much better than that.
You're special forces then? That's great! I just love your olympics!
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:
What exactly is the upside of defining a named function here? The downside is more code that is also located elsewhere, so you have to jump all over the place while reading the code and trying to understand it. OTOH, the single line above is both short and perfectly clear in what it does.