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.

Comments

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.

Re:Whew!

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

Re:Whew!

[guru42101]

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

Re:Whew!

[NatasRevol]

As long as Larry keeps getting paid well by the TLAs, he'll keep giving them first access.

Re:Whew!

[VGPowerlord]

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

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... relying on the java.vendor field to detect which JVM is running.

Re: How about...

[binarylarry]

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.

[bradley.meck]

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

Re:Don't break the web.

[ADRA]

http://www.w3schools.com/vbscript/

Yes, don't break my VBScript support or else!!!

Re:Don't break the web.

[VGPowerlord]

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.

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?

Re:default methods for interfaces

[Anonymous Coward]

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.

Re:default methods for interfaces

[stewsters]

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?

Re:default methods for interfaces

[mark-t]

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.

Re:default methods for interfaces

[Anonymous Coward]

AFAIK, you are absolutely right, meaning that the primary reason that Java was supposed to be better than C++ is now gone, so that Java could introduce a new feature, two YEARS after C++11 introduced the same feature (lambdas) into the language.

To be honest, I think the only reason C++ lost the language war was the lack of popular libraries and app servers. The fact that data structures and functionality useful for building web applications is packaged directly into a language remains the best part of Java today.

Don't get me wrong, I like Java and I'm happy it's here to stay, but I think the lambda feature was poorly implemented. Java, in effect, had closures already but they were simply too verbose; if this would have been implemented as something akin to a typedef on top of the existing anonymous class functionality, default methods never would have been necessary.

Re:default methods for interfaces

[sproketboy]

Explained here:

http://stackoverflow.com/questions/16764791/how-does-java-8-new-default-interface-model-works-incl-diamond-multiple-inhe

Basically it's a compiler error.

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.

Re:default methods for interfaces

[Anonymous Coward]

C++ lost the language war because it runs in an unmanaged environment without garbage collection.

Yes, yes, "but it's faster! and GC isn't necessary if you're only working with smart programmers!" In the real world, your application is IO-bound, and you are surrounded by idiots. Java is superior in this case.

Re:default methods for interfaces

[Anonymous Coward]

You are correct, and these same idiots also leak other resources like database connections. No language can fix stupid.

Re:default methods for interfaces

[emblemparade]

It's all discussed in the FAQ.

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:default methods for interfaces

[Atzanteol]

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:default methods for interfaces

[Atzanteol]

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:default methods for interfaces

[Anonymous Coward]

Luckily, memory represents 99% of the "resources" allocated by the software and the one smart guy on the team can keep an eye on the database connections and file handles that GC doesn't deal with.

Re:default methods for interfaces

[JAlexoi]

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.

Re:default methods for interfaces

[JAlexoi]

Your assumption of the intention for the default methods is incorrect. They were a result of mixin envy, not adding new default implementations for future proofing.
Java developers tend not to have issues with future proofing for new functions in interfaces.

Re:default methods for interfaces

[angel'o'sphere]

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:default methods for interfaces

[0123456]

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 runtime so you have no idea what the code does when you look at it.

Re:default methods for interfaces

[dkf]

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:default methods for interfaces

[LordKronos]

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 expects a B object as a parameter. In the upgraded library, that method takes advantage of the fact that B objects now have a Foo function, so it calls it. Except that the implementation of Foo in X that gets called is one that was designed to only deal with calls intended for objects of type A. Unless A.Foo and B.Foo have the same intended purpose, it's gonna fail until class X is upgraded to deal with the new B.Foo. 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? That's important because, if the purpose is different and the naming similarity is just coincidence, then you are going to need to do different things in each case.

Re:default methods for interfaces

[shutdown -p now]

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.

Re:default methods for interfaces

[angel'o'sphere]

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?
The caller is always calling on an A object. As B just an interface and no class.
Or put it other way around :D The caller is always calling on an B interface and does not care what kind of object it is.

Well, your analysis is right, however I doubt it will lead to big problems in the real world. After all the function foo() will serve some business purpose. And even if you have no single unit tests I assume you have high level integration tests on Business Cases?

Re:default methods for interfaces

[dkf]

But you're forgetting - he's been assigned by the PHB to a "more important" part of the program.

But you're forgetting — he's smart so he keeps an eye on what must be done as well as what some failed MBA thinks is required.

Oh Yeah!

[Greyfox]

Everyone's jumping on the lambda train! Choo Choo! You know what that means! Two years from now all code will be written with nothing but lambdas. All those programmers out there with a new hammer, looking for a nail and all. Don't get me wrong, I just posted up a bit of nitfy sorcery with the new C++11 ones that would have been a lot harder without them. I'm just not looking forward to maintaining any code written in the next couple years. If we actually did design reviews here, I'd have to demand that any usage of them be justified (Kind of like singletons a couple of years ago blah.)

Re:Oh Yeah!

[TheRealMindChild]

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!!!

Re:Oh Yeah!

[TheSkepticalOptimist]

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!

[Anonymous Coward]

Fellow Developer: Hey man, where is the vector sort function that we use in this code?
You: There isn't one. It is much easier that I put a lambda in the function that uses it! Find the function that uses the sort and it will be in there somewhere.

You've got to be kidding me. There is no downside to explicitly defining a function, except laziness and shortsightedness

Re:Oh Yeah!

[angel'o'sphere]

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:Oh Yeah!

[TheRealMindChild]

Why would you do that? You increase the stack usage, risk a branch fault, and make nothing easier.

Re: Oh Yeah!

[Dog-Cow]

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:Oh Yeah!

[shutdown -p now]

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!

[shutdown -p now]

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:

// Sort things by name
list.sort(Comparator.comparing(x -> x.name));

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.

Re:Oh Yeah!

[angel'o'sphere]

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:Too late

[sproketboy]

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:Too late

[Anonymous Coward]

If somebody can run cutting edge, (s)he probably long time ago switched to Groovy (http://groovy.codehaus.org/), Scala (http://www.scala-lang.org/)

Actually, my ideal environment would be polyglot Groovy, Clojure, Scala, and Java.

There are some problems with that for a production environment, however:

Groovy leaves generated classes all over PermGen, which is a deal-breaker in a module load/unload environment;
Clojure is reportedly up to 30x slower than native Java;
Scala is great, except for the fact that you can overload operators and generate "libraries" that make resulting code that uses those libraries look like line noise. (I'm convinced that Odersky is a hunt-and-peck typist based on how many stupid little annoying syntax-shortcut rules are in Scala.)

Can't wait for the OS/2 -eComStation port upgrade

[martiniturbide]

: ) http://svn.netlabs.org/java

Re:Too late

[abies]

My favorite one atm is Xtend. It has none of the disadvantages you mentioned above, but removed most annoying 'celebration' from java code.

Zero Trust

[Anonymous Coward]

Does anyone really trust Java anymore?
Not a troll. Serious here. Since Oracle took over trust has eroded. Have we reached the end of Java dominance in the corporate environment?

Re:Zero Trust

[PolygamousRanchKid]

IBM has a lot invested in Java. I wonder what their contract or rights to Java are . . . ?

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.

Re:Too late

[znrt]

Jvm/core libraries updates are very welcome - but the language level changes are just too late.

too young to die but too old to java? late for what?

If somebody can run cutting edge, (s)he probably long time ago switched to Groovy (http://groovy.codehaus.org/), Scala (http://www.scala-lang.org/) or Xtend (http://www.eclipse.org/xtend/).

which are java emmiters ... so what's your point? you seem to sugest that while it's ok for you to "cut edge" thanks to some platform, it's not ok for that same platform to "cut edge" too? why? if you are worried about competition, don't: it's oracle! let them do their thing. they'll be around for a while anyway.

Re:A Joke

[hawkinspeter]

Whose their?

Re:Too late

[rve]

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.

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:Too late

[rve]

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:Too late

[abies]

'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 were moved from java to other platform of choice here, it might not happen at all.

Yes, java is a safe language - same was as COBOL was for a long time. We will have maintenance work to do 30 years in future for sure. But I really wish we get jvm+libraries+ecosystem and change the language...

Java... is now..

[houbou]

learning from JavaScript ;)

Re:Java... is now..

[Lennie]

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:Java... is now..

[shutdown -p now]

They had a JavaScript engine in the standard library for ages. This is just a better one.

Re:Java... is now..

[HiThere]

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 predecessor was structured programing. And the best concept of functional programming is probably invariance...but not everything either can or should be made invariant.

OOP needs to develop a concept to allow it to deal with multiprocessing without requireing invariance. In database systems the analogous concept is called "eventual consistency". Something where when an object is in a state of flux it can accept inputs, but can only emit outputs whose state is not in doubt. This is clearly a superset of invariance.

Re:What do lambdas provide that anon classes do no

[abies]

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:A Joke

[RaceProUK]

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:Too late

[RaceProUK]

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:What do lambdas provide that anon classes do no

[firewrought]

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.

Re:Too late

[mellon]

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:What do lambdas provide that anon classes do no

[M. Baranczak]

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:A Joke

[Anonymous Coward]

Did you warn them?

Re:A Joke

[mitzampt]

Scale your application enough... The difference might bite you. But yeah, it's not as it's used to be.

Re:A Joke

[RaceProUK]

They hung up before I got the chance :(

Re:How about...

[Richy_T]

No one appears to be answering the really important question:

Which shitty toolbar(s) will this come bundled with?

Re:What do lambdas provide that anon classes do no

[abies]

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 for parallel collection processing, which is pretty tricky to express in plain java.

Re:Too late

[Reapy]

Googled Xtend for more info... what an unfortunate name they have for the language.

Re:What do lambdas provide that anon classes do no

[stdarg]

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:Meanwhile

[Anonymous Coward]

Javascript? Solve real problems? Bwahaha.

Keep on trollin'

Re:What do lambdas provide that anon classes do no

[mark-t]

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

Re:Too late

[angel'o'sphere]

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:What do lambdas provide that anon classes do no

[mark-t]

Hey... If its good enough for mathematical ring or group structures to have to explicitly spell it out instead of using arguably much more intuitive math operators, why should having to use anon classes instead of lambdas be any different?

Re:A Joke

[jeremyp]

Who's their?

Re:Too late

[Anonymous Coward]

FUD FUD FUD

toolbar

[snsh]

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

Re:toolbar

[VGPowerlord]

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"

Re:toolbar

[whizzter]

I heard rumours about our favourite Bonzi buddy

Re:toolbar

[hobarrera]

The one on my package manager does not depend on any toolbars. What kind of wierd distro are you using? :-|

Re:A Joke

[hawkinspeter]

Who's they're?

Re:TL DR

[idontusenumbers]

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.

Re:A Joke

[TheDarkMaster]

Depends. If you are using a PC with 256MB of RAM, you will see the difference quickly and brutally.

Re:Conservative Java teams will find it "interesti

[ADRA]

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:A Joke

[RaceProUK]

Like I said, 1990's :P

Re:What do lambdas provide that anon classes do no

[angel'o'sphere]

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:What do lambdas provide that anon classes do no

[Anonymous Coward]

TL;DR: Sometimes we are forced to work with outsourced Indian programmers.

FTFY.

Re:What do lambdas provide that anon classes do no

[phantomfive]

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-line function you'd have to jump to, instead of just looking at it where it gets executed. That's probably an over-simple example, but if you care you should be able to get the picture.

There are probably other places where lambdas are nice too, but that's what I see as the main one.

Re:Too late

[jdavidb]

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:Too late

[I'm New Around Here]

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:Conservative Java teams will find it "interesti

[gutnor]

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.

Re:What do lambdas provide that anon classes do no

[ndykman]

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, you have an external list of other objects that you want to match based on a person's name. You can just use this lambda as filter:

(l) -> (this.getFirstName() == l.getFirstName() && this.getLastName() == l.getLastName())

This is a natural expression. Note, that this doesn't work in an anonymous class, because this refers to the anonymous class, not the outer class.

Moving on from this, the new lambdas and functional interfaces allow you create much more generic functional methods. So, you can now write things like

aList.filter(o->o.getLength() > 0) and bList.filter(o->o.getName > 0).

As a C# developer (and secret Schemer, err, Racketeer), functional style programming is really useful and has a big impact on productivity and expressiveness. Sadly, Java Generics and type erasures imposes some limits compared to the C# implementation, but that doesn't discount how useful this style of programming is.

Re:Java modern?

[peppepz]

I for one hope that it never happens! To me Scala is a puzzler generator. I prefer complex, but readable code instead of shorter code whose complexity - and bugs, and unforeseen interactions - have been hidden away by the pantagruelic grammatical structure of a programming language.

Java generics, by the same author of Scala IIRC, were supposed to make our lives only simpler. They usually do. But then they also brought in type erasure; they introduced compiler warnings, their suppression mechanisms, and the concept of "unsafe" code into the language; we started to see confusing signatures such as Enum<E extends Enum<E>> ...

Re:What do lambdas provide that anon classes do no

[abies]

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:Too late

[sproketboy]

Sorry to hear that. Were in healthcare and were on Java 7 and we'll be on Java 8 in the new year.

Re:Java modern?

[pjt33]

The lead developer on Java generics was Neal Gafter, not Martin Odersky.

Re:Too late

[sproketboy]

Yeah except development costs are peanuts compared to *maintenance* costs.

Re:A Joke

[TheDarkMaster]

You in fact missed the point... Today we need to use gigabytes of RAM to do the same work we did earlier with only 256Mb (or much less). At least in my development school, this means that the current programs are much, much worse than your "ancestors".

Re:Too late

[mellon]

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:A Joke

[RaceProUK]

You were doing H.264 encoding in 1998?

Re:How about...

[Joce640k]

...and how many updates can we expect to have to manually install over the next year if we administer a few dozen machines?

Re:Meanwhile

[Cmdrx]

Average developers will continue using Java as forward-thinking engineers use Scala, JavaScript, and other progressive languages to solve real problems faster.

Employed developers will continue to use Java, COBOL, Pascal, or whatever their employer's code-base is written in. This seldom has anything to do with the skill of the developer, and almost everything to do with the cost of converting functional, stable code to a new language. The case to move to a new language must include benefits in excess of the stability of the existing code-base.

Average developers will make a mess of any code-base, regardless of the "new hotness" status of the language.

Re:Too late

[znrt]

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.

the availability of fancy code constructs (like closures and lambdas) is the last concern when it comes to choosing a software development platform. they may be a "nice to have" but what you want to priotitize is reliability, efficience, maintainability, stability, availability of tools, that sort of things.

and of course platform indpendence. so what has c# to do with this at all? it isn't even an option if you value platform independence. parent cited groovy and scala. well, there you have some fancyness that you can get for free *on top* of java, while all the pros and advantages of the java platform still apply. it's a different issue where it really just comes down to perceived language fancyness. opinionism, if you ask me, but everything else is the same.

Re:Too late

[dkf]

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:Java modern?

[rjstanford]

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.

Re:What do lambdas provide that anon classes do no

[dkf]

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:What do lambdas provide that anon classes do no

[mark-t]

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 graphics either?

And so a linguistic means that manipulates such necessary and often quite customized mathematical constructs in a concise and intuitive way would therefore inevitably be very useful. Whether or not the JVM performs such computations as efficiently at run time as a language designated for hard-core number crunching would is less of an issue than whether or not those computations are easy to read and understand at a source-code level.

Lambdas do nothing but offer a syntactic convenience beyond what was already possible in Java. I recognize that this is a significant issue however, and I don't mean to downplay it's importance, but it's equally the case that operator overloading is not really anything but a syntactic convenience either.

Functional Programming Isn't Scary. Is it?

[ndykman]

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, each order has a list of line items. I want to sum their prices up. Sure, the for loop version isn't too bad.

int price = 0;
for (Order o : orders) {
for (LineItem li in o.LineItems) {
price += li.getPrice();
}
}

And if we want to choose which orders and which lineItems, we add conditional statements. But, as one codes more and more, you will write code like this a lot. At some point, one thinks about you could somehow capture this "pattern" more concisely? One could go to the GOF and talk about a Iterators, Strategy, etc. But, that's a lot of classes. Functional programming does is give you a different, smaller set of building blocks to capture patterns like these. Let's do a LINQ version in C# of our Java code.

orders.Where(o=>o.CustomerId == customerId).
SelectMany(o=>o.LineItems).Where(li=>li.Price > 10.0).Sum(li=>li.Price);

Now, this code is more dense, but if you look at it, it states what you want, not how to get it. I read this as "For all orders for a given customer, select all the line items for which the price is more than 10.0, and give me the sum of the price for those line items). Now, imagine that the orders list is pretty big, and we want to see if a parallel version would do better. PLINQ makes that a breeze.

orders.AsParallel()... // same code as above.

Now, this isn't as efficient as a hand crafted parallel loop, nor it is magically going to work on a list of orders that can't even fit in one process, but with one change, we can see if we get a speedup, and if it is good enough, and if it isn't, then we can go for a handwritten version. In the era of multicores and parallel programming, a basic understanding of functional programming is very useful as it gives one a different set of tools for how to think about a problem. My apologies for the poor code formatting, but hopefully the ideas still come through.

Re:Functional Programming Isn't Scary. Is it?

[shutdown -p now]

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 library, too - but I doubt that people would use it much if they didn't also get the new concise lambda syntax.

Re:Functional Programming Isn't Scary. Is it?

[ndykman]

True, they aren't true closures. This is a important distinction to make.

What I missed is that the relaxation to allow effectively final variable capture applies to lambdas and inner classes; so I agree that this is syntactic sugar.

And I agree that this syntax does lead to wider adoption of the newer streaming parts than would occur without it.

Re:Too late

[maccodemonkey]

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:What do lambdas provide that anon classes do no

[cecom]

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:Too late

[shutdown -p now]

Which are less too, if developers use the new language features rather than abuse them.

Re:What do lambdas provide that anon classes do no

[shutdown -p now]

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:Not exactly.

[Cmdrx]

That's not how I read your comment.

Agreed, it's important to keep relevant, and to learn new languages, technologies, etc. Many of the new tools, just re-invent old solutions with incremental improvements. For most businesses, it's just not worth the cost to jump to something new. Also, the risk-adverse nature of high availability environments dictates an attitude of measured and careful change.

Your clarification on staying relevant makes your initial statement clearer.

In the end, most of us will be working with technology long out of date, because it pays, and occasionally with technology that is new, because we want too.

Re:What do lambdas provide that anon classes do no

[mark-t]

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:What do lambdas provide that anon classes do no

[shutdown -p now]

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?

Hope we soon get a new Java version

[sputti]

Will try out the new Java version too and hope it is soon finished. :-D

Re:What do lambdas provide that anon classes do no

[angel'o'sphere]

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:Too late

[angel'o'sphere]

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 this stuff in your version control system, but your *old* clients on your conserved machine (VM) can not connect to it anymore ...

Just running an old Java Version that miraculous still runs on the newest Solaris is not enough to be able to fall back.

Re:Too late

[angel'o'sphere]

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:What do lambdas provide that anon classes do no

[mark-t]

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).times(t).plus(a.plus(b).times(1-t)) instead of (a+b)*t+(a+b)*(1-t), for example, is very annoying. The function specification loses a lot of the notion of exact precedence, and particularly annoying to myself, it does not even *read* the same as the version described with math the formula.

The latter problem could be somewhat abated by renaming .add() to .plus(), .multiply to .times(), and so on... but then one would be using an inconsistent naming convention to operating with mathematical structures, since the numeric types that come with the java framwork, such as BigInteger, use the function names .add(), .multiply(), etc. Even more annoying, however, and to a certain extent regardless of what naming convention is utilized, it is not immediately obvious from the function name whether the function modifies the state of the object it is operating on, or if it returns a completely different one, whereas with mathematical notation, the stateless nature of the operators is explicit in the notion of understanding what the operators mean mathematically. If one wanted both functions... one to modify the state of the object, and another to return a new one, one is forced to adopt a particular naming policy which may not necessarily be intuitive for other programmers who might have to read the code to differentiate them.

And far from being a contrived complex example that would be useful in a small domain of programs, the formula that I described above is actually an extremely common one which can be used for doing a linear interpolation between the values of a and b, whatever their types may be, whether scalars, vectors or almost any other type of mathematical structure, and the pattern is extremely common in animation code.

Re:What do lambdas provide that anon classes do no

[shutdown -p now]

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

The main problem there is nulls. You can't just write a.equals(b). For full equality, you have to write (a==null && b==null) || a.equals(b). When one side is a literal, you can turn it around to save the null check, e.g. "foo".equals(b), which still looks silly to me, but the most generic case is really the worst because not only it's verbose by itself, but you have to write the left-hand-side expression twice; so if it's expensive enough, or has side effects, you need to introduce a temporary. Just to compare two strings!

Re:What do lambdas provide that anon classes do no

[mark-t]

The problem I would have with making == check for content similarity is that there are really two different notions of equality, one of which is to compare only the content of the two objects and the other compares the identity of the objects. If == were to ever mean comparing their content, then there would be absolutely *no* means for comparing identity. This may be perfecty acceptable in a lot of circumstances, but imposing that limitation upon a programmer by making that trait part of the language ultimately makes the language less useful.

Re:What do lambdas provide that anon classes do no

[shutdown -p now]

For immutable types, there's no point in ever comparing identity - there's nothing useful that you can derive from knowing whether you have two references to the same immutable object, or two different ones (since you cannot do anything to that object that would make the difference observable). So having == do value comparison for strings is not really imposing undue limitation on the developer.

On the other hand, I do agree that it's not particularly neat to overload it like that. Object identity is reference equality, and value comparison is object equality. So this is basically like having an operator with variable indirection - sometimes it dereferences its arguments, sometimes it doesn't. That's confusing.

The ideal solution, to be, is to have two separate operators that cleanly separate value and identity comparisons. Furthermore, because value comparison is something that is much more common, I posit that == - or the equivalent operator that uses the standard equality notation - should be a value comparison for both value and reference types; and the object identity operator should have a different name.

Python has got both the design and the naming, in my opinion - "==" and "!=" are always value comparisons, and "is" and "is not" are identity comparisons.

Re:What do lambdas provide that anon classes do no

[mark-t]

Except, of course, that == is already an identity comparison operation. This would be fine if you were designing a language from scratch. It's anything but if you are wanting backward compatibility.

Re:What do lambdas provide that anon classes do no

[ndykman]

Well, I missed the section that they added the relaxation for effectively final variables for inner classes as well, so yes, this is just syntactic sugaring.

I still argue that the concision of lambda syntax is still useful, even if you don't get full on closures.

Even better

[toby]

You can use one of the open source distributions that were forked from OpenSolaris (more or less): Nexenta, Illumos, etc

ZFS alone makes this more than worthwhile, although you can now have ZFS with FreeBSD, OS X, and even Linux.

License

[hobarrera]

For those interested, the license seems to be GPL+Classpath Exception:

http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/LICENSE

Re:A Joke

[hobarrera]

I sure as hell can.

How to tell if it's a java app:
  * It's doesn't use the OS's look and feel.
  * It doesn't use the same font AA and hinting as everything else.
  * A simple two-button window will take several seconds to load (instead of 1s), regardless of hardware.
  * Memory usage jumps up, even if it's just a tiny console app.

Re:What do lambdas provide that anon classes do no

[hobarrera]

Which has really unusual formatting just to look shorter!

Re:How about...

[sharklasers]

I feel like the only geek/nerd/social outcast on Slashdot who's aware of the developer's download page for the JRE/JDK:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

It's where I get my Java downloads for development as well as end-user runtimes, and they're completely clean and without toolbars. I've given up being snarky to those who complain about the toolbar though - they just need to be educated, which is what this post is for. :)

I also feel like the only geek/nerd/social outcast on Slashdot who doesn't hate Java/Oracle.

Re:A Joke

[RaceProUK]

Then the developer should have spent more than 3 seconds developing it.

Re:What do lambdas provide that anon classes do no

[benhattman]

I haven't read through the entirety of the new Java spec, but the most general answer to your question is that to support lambda expressions, a language usually needs to support functions as a first order feature. Right now, if I want to make my class execute some operation provided by the caller, I need to write an interface (or worse a base class). The caller then needs to implement that interface, and so on and so forth.

By contrast, a first-order function doesn't require me to tell the caller anything beyond what they must know. I just write a function that has a return type and parameters, and anything they can squeeze into that pattern they can pass in. For instance, threads right now require runnable with a run method. What if I have a void exec() method already? I still need to write a void run() method. With functions, I don't have to create so many new (and redundant) methods.

Re:A Joke

[RaceProUK]

No... you do it in java now? are you masochist?

My point is about 50ft to your left.

Re:What do lambdas provide that anon classes do no

[cecom]

I don't dispute that it is useful, but it is less so than it might appear at first sight. IntelliJ IDEA already could automatically collapse anonymous inner classes into lambdas in the IDE, even with Java 6.

The huge disappointment is that they *could* have supported real closures, just like C#. I am not aware of a technical reason not to. But they didn't, and the whole hoopla is about a very mild syntactic improvement, just as generics were.

Re:Too late

[Beezlebub33]

As someone who used Sun Grid Engine, and then started using Oracle Grid Engine, this is not FUD. Oracle has changed the licensing to the point that I cannot use it any more. I cannot get it any more. And, worse, they have removed the old versions, so my clients can't get it any more either without going through Oracle licensing.

Re:A Joke

[hobarrera]

PORTABLE java apps with font antialiasing and native widgets just doesn't exist. You need SWT for that, which requires per-platform libraries.