×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java 8 Developer Preview Released

Unknown Lamer posted about 7 months ago | from the now-contains-three-quarters-of-a-common-lisp dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

189 comments

How about... (0)

Anonymous Coward | about 7 months ago | (#44818435)

How about 'cool new features' like testing and code audits?

Java 8 will probably be as full of holes as the last iteration.

Re: How about... (4, Insightful)

binarylarry (1338699) | about 7 months ago | (#44818463)

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. (3, Interesting)

Bradley Meck (2961599) | about 7 months ago | (#44818491)

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

VGPowerlord (621254) | about 7 months ago | (#44821047)

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

Anonymous Coward | about 7 months ago | (#44819607)

Signed Applets are quite useful for internal websites. Make sure only applets signed by a trusted source can run and exploits are no longer an issue.

Re:How about... (5, Funny)

Richy_T (111409) | about 7 months ago | (#44819547)

No one appears to be answering the really important question:

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

Whew! (4, Interesting)

inking (2869053) | about 7 months ago | (#44818439)

The fact that Oracle didn't find any glaring issues is hardly a surprise. A better question is whether they would fix them even if they did find them, like that rather glaring security vulnerability that they've just decided to brush off until their next major release last year.

Re:Whew! (2, Insightful)

Anonymous Coward | about 7 months ago | (#44818479)

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! (0)

Anonymous Coward | about 7 months ago | (#44819877)

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.

Which security vulnerability are you referring to, the fact that people who don't understand or care about asymptotic performance guarantees were using hash tables?

A Joke (0, Funny)

Anonymous Coward | about 7 months ago | (#44818451)

"Knock knock."

"Whose there?"

.

(time passes)
.

.

(grass grows)

.

.

(paint dries)
.

.

.

"Java"

Re:A Joke (4, Insightful)

RaceProUK (1137575) | about 7 months ago | (#44819113)

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:A Joke (0)

Anonymous Coward | about 7 months ago | (#44819767)

Does your computer still have 640k of "base" memory? You need to enable "expanded memory" to run modern applications on your machine.

Too late (0)

abies (607076) | about 7 months ago | (#44818457)

Jvm/core libraries updates are very welcome - but the language level changes are just too late. 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/). For slow corporate clients, java 8 will anyway not happen until 3-4 years after official release.

Re:Too late (4, Insightful)

sproketboy (608031) | about 7 months ago | (#44818521)

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 (1)

rve (4436) | about 7 months ago | (#44818835)

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:Too late (1)

I'm New Around Here (1154723) | about 7 months ago | (#44821059)

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:Too late (1)

abies (607076) | about 7 months ago | (#44818941)

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

Meanwhile (-1)

Michael Ahlers (2939579) | about 7 months ago | (#44818957)

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

Re:Meanwhile (1, Funny)

Anonymous Coward | about 7 months ago | (#44819857)

Javascript? Solve real problems? Bwahaha.

Keep on trollin'

Re:Too late (1)

angel'o'sphere (80593) | about 7 months ago | (#44819977)

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:Too late (1)

jdavidb (449077) | about 7 months ago | (#44821015)

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 (1)

Anonymous Coward | about 7 months ago | (#44818533)

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

Re:Too late (1)

abies (607076) | about 7 months ago | (#44818555)

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

Re:Too late (1)

znrt (2424692) | about 7 months ago | (#44818705)

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:Too late (1)

rve (4436) | about 7 months ago | (#44818923)

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 (1)

RaceProUK (1137575) | about 7 months ago | (#44819177)

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:Too late (1)

mellon (7048) | about 7 months ago | (#44819275)

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:Too late (1)

Anonymous Coward | about 7 months ago | (#44820025)

FUD FUD FUD

default methods for interfaces (3, Interesting)

LordKronos (470910) | about 7 months ago | (#44818507)

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 (0)

Anonymous Coward | about 7 months ago | (#44818613)

Yes, they'll probably add "default member variables for interfaces" in a later release.

Re:default methods for interfaces (1)

Anonymous Coward | about 7 months ago | (#44818707)

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 (3, Interesting)

LordKronos (470910) | about 7 months ago | (#44818977)

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 (1)

Atzanteol (99067) | about 7 months ago | (#44819805)

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 (1)

angel'o'sphere (80593) | about 7 months ago | (#44820707)

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 (0)

Anonymous Coward | about 7 months ago | (#44819907)

C++ multiple inheritance is a gigantic mess - java interfaces cannot have state so this avoids duplicate variables and virtual inheritance. No matter which Foo you call it can only modify the state indirectly using other methods required by the interface.

The matter with incompatible default methods only affects new code right now as existing code does not use the features. For new code a simple advice avoid god objects that do everything - they are bad design.

Re:default methods for interfaces (1)

JAlexoi (1085785) | about 7 months ago | (#44820651)

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 (1)

stewsters (1406737) | about 7 months ago | (#44818711)

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 (1)

mark-t (151149) | about 7 months ago | (#44818743)

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 (1)

Anonymous Coward | about 7 months ago | (#44818829)

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 (1)

Anonymous Coward | about 7 months ago | (#44819259)

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 (1)

Anonymous Coward | about 7 months ago | (#44819453)

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

Re:default methods for interfaces (1)

Anonymous Coward | about 7 months ago | (#44819929)

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 (1)

Atzanteol (99067) | about 7 months ago | (#44819845)

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 (0)

Anonymous Coward | about 7 months ago | (#44818935)

This is really more like C#'s extension methods - and serves pretty much the same purpose.

Re:default methods for interfaces (2)

emblemparade (774653) | about 7 months ago | (#44819677)

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

Anonymous Coward | about 7 months ago | (#44819987)

The BIG problem with diamond graph inheritance is whether there should be one or two of the grandparent classes. Sometimes you want one and sometimes you want the other. Sometimes there is no good answer. If the inheritance graph becomes more complicated with multiple diamonds in there, things get even worse. However, this problem only concerns the member variables of the grandparent. Java interfaces still can't have member variables, so the BIG problem just isn't there. The name disambiguation problem is much less of an issue. For example, with a diamond graph, there is no issue with the methods, since the methods named the same ARE the same. I think Java finally nailed the sweet spot for multiple inheritance.

Re:default methods for interfaces (1)

JAlexoi (1085785) | about 7 months ago | (#44820599)

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.

Ok... where are the (0)

Anonymous Coward | about 7 months ago | (#44818511)

auto properties?

Re:Ok... where are the (0)

Anonymous Coward | about 7 months ago | (#44818665)

I was at JavaOne in 2010 and they said properties might be considered in Java 9, along with the Java Modules feature

Oh Yeah! (1)

Greyfox (87712) | about 7 months ago | (#44818513)

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! (2, Insightful)

TheRealMindChild (743925) | about 7 months ago | (#44818687)

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! (0)

Anonymous Coward | about 7 months ago | (#44818689)

Actually, using nothing but lambdas gets you a long way. You can (obviously) bin named functions (as being distinct from lambdas), by simply assigning lambdas to variables (hence giving them a name, and giving you the exact same feature). You can bin operators (which are only really 1 or 2 argument functions anyway), as being lambdas assigned to variables with symbolic names. Finally (and probably most contentious), you can bin methods, because they are simply functions with a little bit of implicit context –which is what lambdas are, only lambdas are more general. A lambda that captures a data structure named "self" has the exact same power as a method.

Combining these all into one place means that you get a single, standard, powerful way of interacting with your code, and don't have to deal with the individual corner cases of each of them. It means that every aspect of your language becomes more consistent.

Of course, if you'd asked a mathematician, or functional programmer (a mathematician I guess) this years ago, they would have pointed all of this out to you way back then. I for one, look forward to our new, happy, consistent world where all the special cases that are just lambdas in disguise don't exist any more.

Re:Oh Yeah! (3, Insightful)

TheSkepticalOptimist (898384) | about 7 months ago | (#44818931)

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! (1)

Anonymous Coward | about 7 months ago | (#44820363)

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

Zero Trust (1)

Anonymous Coward | about 7 months ago | (#44818559)

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 (0)

Anonymous Coward | about 7 months ago | (#44818587)

I'll bite. Why don't you trust Java?

Re:Zero Trust (0)

Anonymous Coward | about 7 months ago | (#44820241)

Because he is young and believes all the FUD the hipster say

Conservative Java teams will find it "interesting" (3, Interesting)

Chrisq (894406) | about 7 months ago | (#44818619)

Having played with Java 8 I can see that it can be used in two ways. One is using a few of the enhancements but basically sticking to the procedural/OOP paradigm. The other is to incorporate the functional programming paradigm. I can see a lot of conservative Java teams just sticking to what they know - which will be interesting because at some point they will have a new developer start using the functional capabilities. I can see the culture clash, with the old team members saying "we can't support this" and the new members saying "but its more efficient and inherently more supportable as the functional paradigm uses immutable objects and avoids side-effects.

Re:Conservative Java teams will find it "interesti (1)

ADRA (37398) | about 7 months ago | (#44820633)

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

What do lambdas provide that anon classes do not? (3, Interesting)

mark-t (151149) | about 7 months ago | (#44818903)

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:What do lambdas provide that anon classes do no (4, Insightful)

abies (607076) | about 7 months ago | (#44819039)

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

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

and

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

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

Re:What do lambdas provide that anon classes do no (2)

M. Baranczak (726671) | about 7 months ago | (#44819299)

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

Anonymous Coward | about 7 months ago | (#44819625)

Your Java version misses the point. The parent's style is extensible and composable, and declarative rather than iterative. This is a general trend as it leads to cleaner code, with more re-use of functionality.

Re:What do lambdas provide that anon classes do no (3, Insightful)

stdarg (456557) | about 7 months ago | (#44819849)

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

Anonymous Coward | about 7 months ago | (#44820775)

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

FTFY.

Re:What do lambdas provide that anon classes do no (1)

abies (607076) | about 7 months ago | (#44819703)

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

mark-t (151149) | about 7 months ago | (#44819927)

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

angel'o'sphere (80593) | about 7 months ago | (#44820741)

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 (2)

firewrought (36952) | about 7 months ago | (#44819243)

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

Anonymous Coward | about 7 months ago | (#44819603)

How much code are you going to write for that by anon classes?

MyIterable .Where(item => item.Name.Contains("box")) .Take(100) .GroupBy(item => item.Price % 1000) .OrderBy(group => group.Key) .Select(group => Tuple.Create(group.Key, group.Count()))

like, 50 lines?

Re:What do lambdas provide that anon classes do no (1)

mark-t (151149) | about 7 months ago | (#44819991)

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

Anonymous Coward | about 7 months ago | (#44820147)

Exactly! How the hell am i supposed to justify writing a class factory factory to create a factory that creates the class that has the function I need to pass to another function when I can just pass a lambda expression? There goes my KLOC metrics!

Java has jumped the shark and is no longer ENTERPRISE enough for me. I'm going back to COBOL!

Re:What do lambdas provide that anon classes do no (1)

phantomfive (622387) | about 7 months ago | (#44820875)

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.

Java... is now.. (1)

houbou (1097327) | about 7 months ago | (#44818989)

learning from JavaScript ;)

Re:Java... is now.. (1)

Lennie (16154) | about 7 months ago | (#44820063)

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.

a new Date and Time API (0)

Anonymous Coward | about 7 months ago | (#44819573)

Yay! A new Date and Time API! As if the first two weren't enough. Java is going to collapse under its Date/Time, I/O, and threading APIs.

TL DR (0)

Anonymous Coward | about 7 months ago | (#44819961)

Is Swing thread-safe yet? TL:DR //java developer

Re:TL DR (2)

idontusenumbers (1367883) | about 7 months ago | (#44820581)

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.

toolbar (1)

snsh (968808) | about 7 months ago | (#44820213)

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

Re:toolbar (1)

VGPowerlord (621254) | about 7 months ago | (#44820881)

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

Yes.

Wait, I thought you said "and"

I'll be the first to say it... (0)

Anonymous Coward | about 7 months ago | (#44820663)

Adding multiple inheritance and lambda was a mistake. In theory these are great, the specific design decisions are terrible.

Java Generics could have turned out great, but the design was horribly crippled due to backwards compatibility and now Generics causes more problems than it solves. Readability just went out the window.

Similarly with Lambdas, the syntax they chose is hardly readable or familiar to Java developers. Sometimes a slightly more verbose syntax is preferable, so long as it looks more familiar and readable.

I hope they get a strong push-back from the community for these problems.

Solaris? (0)

Anonymous Coward | about 7 months ago | (#44820737)

People still use Solaris? Just asking. I might download a free version if I find one.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...