Modern Java – A Guide to Java 8

https://github.com/winterbe/java8-tutorial

by aronhunt470 • 11 years ago

404 197 11 years ago

escherize• 11 years ago

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

eklavya• 11 years ago

A type system (at least scala)? Although Clojure does have one, it's not as good to use as Scala's (personal opinion).

struppi4• 11 years ago

Disclaimer: I personally prefer clojure, but earn most of my money as a consultant / coach helping clients develop Java code.

For Java code, it's often easier to predict the performance characteristics of a part of the code. But you shouldn't trust your judgements anyway - instead use a profiler - so this is not really a reason.

Speaking of performance: I once talked to someone working for Elasticsearch, and they told me that they cannot use clojure for most of their code because of their performance requirements. Clojure collections are almost as fast as Java collections in many scenarios, but that is apparently not fast enough for them. This is probably not a valid reason for most projects, though.

There is a huge number of Java developers out there, and Java is easier to learn for someone coming from C++ or C# or JavaScript than clojure (at least I am pretty sure about that). So hiring cheap developers might be easier if you use Java. You might count that one as a political statement.

There are some great tools for Java out there: IntelliJ Idea, Yourkit Profiler, JRebel, ... Cursive Clojure is great, but IntelliJ for Java has even more integrated workflows.

There are very mature open source libraries / frameworks / tools for Java: JUnit, Spring, Guice, Dropwizard, Gradle, Elasticsearch, ... You can have commercial support for many of them. Most of the libraries I use with clojure are version 0.3 or something like that with no possibility for commercial support (but they work fine anyway).

Static typing: A lot of people complain about it, but it can really help you to create maintainable code. See for example http://talks.samirtalwar.com/use-your-type-system.html

mullr• 11 years ago

Really high performance Java code tries to avoid any allocations on the hot paths, since that requires GC. This means a lot of in-place mutation on pre-allocated objects. (Lucene does this, for example) While this isn't impossible in Clojure, you do have to give up a lot of the immutable goodness that makes it such a pleasant development environment.

RyanZAG3• 11 years ago

In the same way some people pick C++ over Lisp, some would choose Java over Clojure for similar reasons.

It's not some kind of war or personal affront to you - some people simply prefer the Algol style to the Lisp one. This even includes people who are very fluent in the Lisp style.

dvanduzer2• 11 years ago

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

dvanduzer2• 11 years ago

There is no non-political reason to enumerate choices of languages limited to those that run on the JVM.

Clojure and Scala exist because of the JVM, not because of Java. Java 8 will or won't be an interesting language independently of the JVM, oddly enough.

bad_user4• 11 years ago

There's a gravitational pull towards popular languages because popular languages have more books, more (idiomatic) libraries and tools, copy-pasteble examples all over the web and a big pool of developers that can be productive from day 1 on simple problems.

In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometimes it's worth it, sometimes it isn't. For a startup, with a small but capable team that's trying to outrun its competition to market, then using the most productive tools possible is a good choice. In other contexts though, like in a big company where long-term maintainability might be more important than speed to market, well, Java might be the better choice, and not because of the language per se (I think Java code is often unreadable), but more because the cost of maintainability is low due to its popularity and its slow pace of change.

manyxcxi• 11 years ago

I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly.

I'm not saying Java is good looking by any means, but I've never found it to be heard to read in the "I can't completely grasp exactly what everything is supposed to do" kind of way. I often find Python and JS to have enough shortcuts, callbacks, and anonymous functions to find other people's code much harder to grok than other people's Java.

kazagistar• 11 years ago

more (idiomatic) libraries and tools

Except almost all the tools work with the pre-java-8 way of doing things (and often even pre-java-7). Thus, you end up with layers of different idioms, all of which are not quite compatible with each other.

oweiler2• 11 years ago

Apart from the slightly better performance, memory consumption. Clojure's persistent collections require a fair amount of memory (which in most cases doesn't matter as memory is cheap).

jinst8gmi4• 11 years ago

Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Other than no new learning required I can't think of many reasons to pick Java as a first choice. Java tends to be popular because it's the oldest, most familiar default for the JVM rather than any particular strength.

ubertaco2• 11 years ago

If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice.

Put another way: if you're on a dev team where nobody knows Clojure/Scala, and everyone knows Java, (and, optionally, the codebase is already in Java), and your team doesn't have time for everyone to learn an entirely new language (including cleaning up the beginner's mistakes that come with that process), then Java's the better choice.

Don't get me wrong, Java grinds my gears sometimes, and I frequently wish I could use Kotlin or F# or some kind of typed Ruby in my Java-shop workplace, and I enjoy picking up the cool ideas from languages like Idris (dependent types are really cool!) in my free time. But I'm sympathetic to my coworkers in the environment where I work: 4 devs in the whole company, startup pressure to get to a break-even point so we don't go under, and a backlog longer than all of us could finish this year even if we froze it now.

Sometimes circumstances require what looks like a short-term decision in order to ensure that there's a long term to worry about later.

justinhj• 11 years ago

There's an irony that your comment is in a thread about learning new features of Java 8

lugus35• 11 years ago

Java shines by the number of java professionals available on the market.

fulafel• 11 years ago

Many people have a gut-level aversion to dynamically typed languages.

aardvark179• 11 years ago

I love clojure, but on a large code base I find good refactoring tools to be extremely helpful when trying to evolve how things are implemented. In that respect Java wins hands down just because of the tooling around it. It also may be easier sometimes to use Java for working with particular libraries.

There are however areas where I'd use clojure every time. Luckily the JVM is really good for doing mixed language work on, so you don't have to work entirely in one language.

winterbe3• 11 years ago

Most parts of software development probably is not about starting new projects from scratch but about maintaining existing code bases. That's where Java really shines due to its (often hated) backwards compatibility.

lmm12• 11 years ago

All IME, and as a Scala fan:

Clojure has a weakly integrated type system (an inherent disadvantage of optional type systems). At the simplest level this makes silly errors much easier and means you have to write more tests to maintain the same defect rate.

The lack of types mean you require extensive use of macros for advanced functionality. IME macros have major maintainability issues in a multi-person codebase.

Both these things are major disadvantages for automatic comprehensibility of code. Autocompletion can be more-or-less usable but will never be as good as in Java or Scala. Automated refactoring is inherently unsafe in the presence of macros (Scala's fancier typed constructs (typeclasses, for/yield with custom types) mean you need macros much less often; Java tends to force you to expand these things out by hand (or else use annotations which act as de facto macros), which has its own maintainability issues but does at least mean automated refactoring will work correctly).

Some of the language culture pushes people towards less principled abstractions. From this side of the fence that looks like anti-intellectualism; no doubt from their side it's pretension on typed programmers' part. But either way I think they're setting themselves up for long-term maintainability issues (e.g. the semantics of clojure transducers in the presence of errors are infuriatingly not-quite-right, which will either remain a painful gotcha forever, or necessitate a painful migration in the future).

As a minority language Clojure may not be as well supported in the surrounding ecosystem - partly things like IDEs but also code coverage tools, profilers, monitoring.... Remember the JVM ecosystem is wider than just the languages themselves.

There are good things about Clojure, but it's by no means clear-cut.

raspasov2• 11 years ago

What do you think is not quite right about errors in tranducers? When you use them with core.async channels you can supply an optional exception handler, which is quite nice.

In terms IDEs, Cursive for IntelliJ is great, and it gives almost Java-like capabilities (with limitations inherent to more dynamic languages, of course).

ubertaco2• 11 years ago

IME macros have major maintainability issues in a multi-person codebase.

I have heard this a bunch, and I believe it, but I've never personally had an opportunity to use a language that supports macros for a multi-person codebase. I'd be interested to learn what are some of the pitfalls you've seen, if you don't mind sharing.

cageface• 11 years ago

A while ago I decided to teach myself how the common machine learning algorithms worked and, to make things interesting, decided to implement them in parallel in both Clojure and Scala. I expected Clojure to be a better fit for this since Lisp has historically been strong in AI. But I found as my codebase grew that the Scala code was much easier to maintain, refactor and understand. So these days I am a big fan of static typing provided it's in the form of a sufficiently expressive type system (Scala, Ocaml, Haskell, Swift etc).

Lisp got a lot of things right but I'm not sure dynamic typing and s-expression syntax were among them.

jvz• 11 years ago

The lack of types mean you require extensive use of macros for advanced functionality.

Could you elaborate?

meekins• 11 years ago

Java EE is currently an excellent framework for complex distributed enterprise applications.

pjmlp14• 11 years ago

It is the systems programming language of the Java platform, if you see the JVM as an OS.

So you need to be comfortable with it, as there will always be cases you need to jump out of the alternative language into Java.

Also, most companies will only hire to work with Java on the JVM, because they don't want to be hostage of the cool language some of the dev team guys/contractors decided to use instead.

It is very rare to see traditional Java shops to use alternative languages.

Usually the ones using them are either startups or companies like Facebook and Twitter, which aren't the typical business culture.

jbooth• 11 years ago

Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance.

They're conservative about adding features, so they've managed to keep the language pretty small, and the core concepts of "what is good Java code" have been mostly the same for like 15 years, even through major releases like 1.5.

jinst8gmi4• 11 years ago

I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java.

Java developers usually consider features which the language doesn't have to be bad or make code unreadable, that is until those same features are added to Java, when suddenly they are a source of pride and a sign of Java being "modern". In reality Java's feature freeze until Java 8 was largely driven by Sun's financial woes.

mark_l_watson3• 11 years ago

I have been using Java since the first beta, and have written a large pile of Java books (pun not intended), but I too prefer Clojure as a practical, simple to use and simple to read language. That said, Clojure / Java interop is really nice. I frequently find myself simply adding existing Java code to my lein project file.

I would suggest just keep using Clojure and when it makes sense, mix in Java when you want or need to.

chvid• 11 years ago

This might sound like a snarky comment but it is actually not.

If you want a dynamic language on the Java platform; then why not use JavaScript?

There is an easy-to-use engine in Java 8 and JavaScript is widespread and somehow familiar to Java-developers.

malcolmgreaves3• 11 years ago

IMO Java doesn't shine anywhere. It's statically typed, but lacks support to be flexible. Thus many Java programs rely on reflection at runtime or casting. This negates all of the benefits of static typing, turning the language into a dynamic one.

The main choice is then either Clojure or Scala. This comes down to dynamic versus static type checking. With a dynamic language, one is significantly less sure if a program is correct. In large programs that use dynamic languages, many tests must be created that are essentially doing the work that a type checker in a static language would do automatically.

In a static language, entire classes of bugs are eliminated. Scala provides the best support for strong, static typing on the JVM.

incepted8• 11 years ago

Scala provides the best support for strong, static typing on the JVM

I'd argue that Ceylon and Kotlin offer most of Scala's advantages with none of its baggage and bloat. And drama.

struppi4• 11 years ago

This is a really nice overview of the new Java 8 features. I like how this tutorial communicates mostly with code snippets and has "read more" links for most topics.

If you are using Java and have not tried Lambda Expressions, method references and default methods, do so now! After that, you'll think "How was I able to live without that?".

I also think that the way Java integrates lambda expressions (via functional interfaces) is really nice. Sure, you have to write some boilerplate code in some scenarios. But since they re-used interfaces and did not event some "function" type (or similar), it fits really nicely into the existing language.

If you don't know Java, this tutorial will probably not be enough - But that probably wasn't the intentian anyway. It's a great intro to what has changed with Java 8 (and all those changes are real improvements for the Java language, IMHO).

KfZ• 11 years ago

Modern here obviously doesn't mean "Java is modern", but rather "the modern form of Java"

struppi4• 11 years ago

Did you intend to answer to my comment? I never used the word "modern" :)

rifung• 11 years ago

If you are using Java and have not tried Lambda Expressions, method references and default methods, do so now! After that, you'll think "How was I able to live without that?"

I think instead of "How was I able to live without that?", people are more likely to exclaim "about time!"

pjmlp14• 11 years ago

Yep, somewhere at Xerox PARC in the early 80's

    coll := ((1 to: 100) select: [:x| ( x * x ) > 3]) collect: [:x | (x * 2)].

struppi4• 11 years ago

Well... depends on who you ask. I, personally, was more in the "about time!" camp. But I have met several programmers who didn't think they'd need those "newfangled features" at first. Especially in the "early days" of Java 8... And sometimes I still meet people like that. So that scentence was targeting those developers that are still stuck with Java 5 or 6 or 7 and have never tried Java 8.

Also, I was once co-teaching a C# workshop where we showed people how to work with LINQ and extension methods (long, long time ago ;) ). Some participants asked us if there was a way to configure the compiler to forbid those features for their team.

Not everybody likes "modern" features, I guess ;)

tootie• 11 years ago

Java lambdas are no different than an anonymous Runnable or Callable. It's just nicer syntax.

michaelcampbell2• 11 years ago

Depends where on the Blub scale you are. For those above java, sure.

mhaymo2• 11 years ago

maps don't support streams

This is very misleading. There is not a #stream method on Map because Map supports three different streams:

    map.keySet().stream()
    map.values().stream()
    map.entrySet().stream()

tokenizerrr• 11 years ago

But those are streams on sets.

mhaymo2• 11 years ago

Those are streams on views on the map. My complaint is that a reader seeing "maps don't support streams" with no further explanation is unlikely to get the correct idea, and may infer that something like

  map.entrySet().stream().filter(e -> e.getKey().equals(e.getValue())).findAny()

is not expressible.

masklinn6• 11 years ago

They're streams on map views, a stream on Map itself doesn't really make sense because there are multiple ways to interpret a map as a sequence and it's not clear what should be the default (e.g. Python defaults to the equivalent of keySet().stream(), but Rust defaults to entrySet().stream()).

keySet() and entrySet() return Set-conforming objects because they can, values() can't and only returns a Collection, but these three objects delegate much of their logic to the map itself.

oweiler2• 11 years ago

Furthermore, Maps have a .forEach method

m.forEach((key, value) -> System.out.println("key: " + key + " value: " + value));

winterbe3• 11 years ago

Thanks for your feedback. I've improved the section about maps to better reflect the capabilities of streaming maps:

https://github.com/winterbe/java8-tutorial/blob/master/READM...

hitekker• 11 years ago

Thanks for your hard work here!

Side note: http://winterbe.com looks quite similar to angel.co. Or does angel.co look quite similar to your website? :-)

aslakhellesoy• 11 years ago

Those methods are not on Map, but on Set and Collection.

dschiptsov8• 11 years ago

Sorry, I absolutely cannot stand this "modern" meme.

  (define-syntax stream-cons
      (syntax-rules ()
          ((_ x xs)
              (cons x (delay xs)))))

  (define (stream-cdr xs)
      (force (cdr xs)))

  (define (stream-map f xs)
      (stream-cons (f (car xs)) (stream-map f (stream-cdr xs))))

  (define (stream-filter f xs)
      (if (f (car xs))
          (stream-cons (car xs) (stream-filter f (stream-cdr xs)))
          (stream-filter f (stream-cdr xs))))

  (define (stream-take n xs)
      (if (<= n 0)
          '()
          (cons (car xs) (stream-take (- n 1) (stream-cdr xs)))))

  (define (repeat x)
      (stream-cons x (repeat x)))

  (define (iterate f x)
      (stream-cons x (iterate f (f x))))

  (define (replicate n x)
      (stream-take n (repeat x)))

  (stream-take 5 (stream-filter odd?
      (stream-map (lambda (x) (* x x)) (iterate (lambda (x) (+ x 1)) 1))))

Not mentioning all these different flavors of Common Lisp streams packages.

As for other features, Scala is around for almost a decade.

chillydawg• 11 years ago

It may not be modern computer science, but it is modern Java. This post is about modern Java and explains the new (in v8) features very well. What's your problem?

dschiptsov8• 11 years ago

OK, what then is Java < 8?)

The point was that if one has a proper old-school computer science (to realize the crucial importance of first class procedures and the power of uniformity 20 years ago) all these modern features are coming for free, to which the code above is an illustration.

But who cares. There is a whole industry which praised Java for almost two decades even without these "modern features".

Any PL student of a decent school, if he is not a hypocrite, would tell you that Java is the worst thing that happened to CS since MS DOS, but who cares about PL theory or even CS? Availability bias and Cargo Cult is enough.

kriro• 11 years ago

I've always had some sort of mistrust of Java (neo-Cobol ohnoes!) but I'm liking it more and more. Mostly I've come around to the fact that static typing isn't as bad as my young self thought (and can in fact be quite cool). The verbosity and "enterprisy" and committee oriented feel are still a bit off putting but I've made a commitment to try some Java on a couple of weekends. Did a bit of research and there's actually nice looking lean web-stuff, too (Spark Framework, Ratpack). Played with the J8 features back when it was released and they are pretty cool.

Cliffnotes: I think I have discriminated against Java mostly on a "religious" basis. I think it's a great time for people like me to give it another shot (especially if you have grown accustomed to functional ideas form other languages in the meantime).

The repo is an excellent resource, bookmarked.

masklinn6• 11 years ago

Mostly I've come around to the fact that static typing isn't as bad as my young self thought

That's not exactly a point for Java though, considering it doesn't really have a good static type system.

cfontes• 11 years ago

Could you define good?

pjmlp14• 11 years ago

Good luck with your experiments.

Many of us in the 90's jumped into Java, in spite of its issues, because it made it more pleasing to write cross platform code, than using C or C++ with CORBA/COM across OSes with compilers that were still playing catchup with the standards.

haxeny14• 11 years ago

I never understood the following : Eiffel had a better syntax, better support for core issues, Void type, design by contract, multiple-inheritance and an intermediate virtual machine for portability although the most common target was C code. To name a few. I was using Eiffel in a small side project just about when Java released their 1.1.4 (a version before the object serialization library, iirc). It was a sticking point for me. Add to that, to program in java before IBM Visual Age was released was to using vi/notepad(++?) editors. Coming from Smalltalk env that was a bit of a shock. Eiffel commercial IDE from ISE was way better and its clever use of pick event on the mouse's right click to drop to compile/run targets was actually easier on my fingers, which is a side show, but good quality products demonstrate quality at unexpected places.

I am still programming in java in my day job, knowing fully well that Java was not my top five language choices. Eiffel's type system was a bit more advanced than Java even way back in those days, so not only was I stuck without an ide till VA for Java showed up or VisuallJ++ I also had to accept weak inheritance and design by contract models. Performance of course was not even close to an Eiffel compiled C code, which was probably addressed in later versions of java.

My point being, that just as Eiffel was something that was better and set aside by a few leading development shops, there must have been other languages that could/should have received a fair share in language evaluation by programmers, I dont necessarily mean limiting to Ruby, Python for example, despite them being excellent tools, they may fall short in an enterprise ecosystem. What happened at least I seem to think instead is a sort of groupthink to start coding in Java because of rubbernecking. All in all, I think that things could have been better if people paused to understand the Java language model and fixed in java 1.2/3, or some earlier version so we didnt have to wait till Java 1.8 to get these features. /rant.

MrBra2• 11 years ago

I had some little experiences with Java and now I'm approaching C# so I have a genuine newbie question regarding cross platform development: was Mono (or .NET core) a thing in the 90's, would you have chosen C# over Java?

ed_blackburn• 11 years ago

Where is aysnc await?

the84723• 11 years ago

CompleteableFuture[1] is the closest we got for now in the JDK.

[1] https://docs.oracle.com/javase/8/docs/api/java/util/concurre...

SloopJon• 11 years ago

I just started using CompletableFuture last week. The way each method ties your lambdas together without a bunch of type boilerplate is really nice. I still don't have a great handle on all of its methods, though; e.g., what's the difference between get() and join()?

pkolaczk• 11 years ago

In Scala: https://github.com/scala/async

ifdefdebug2• 11 years ago

interfaces with default implementations? Doesn't this look like... multiple inheritance?

the84723• 11 years ago

they only add behavior based on other already-present methods, they don't add fields.

ifdefdebug2• 11 years ago

Right, not adding fields makes all the difference.

microtonal• 11 years ago

You can still not have member variables, so the default implementations can only be implemented in terms of other methods. So it should probably be classified as 'limited multiple inheritance'. It does have the diamond problem though.

scott_s• 11 years ago

That was my immediate thought - this is closer to multiple inheritance, as it introduces the diamond problem: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo... According to that page, Java forces programmers to resolve the ambiguity by making it a compiler error. A reasonable approach, I think.

I've done more OO development in C++, and I've found this technique useful - putting a default implementation in a class which was mostly an interface because only a small number of subclasses needed specialized behavior.

mooreds• 11 years ago

My exact thought.

incepted8• 11 years ago

More like traits. Multiple inheritance of implementation is problematic because it allows parent classes to define state. Traits and Java 8's interfaces don't.

TurboHaskal• 11 years ago

Enjoy these features while you can.

It's a matter of time until your team lead takes a glance at the code-base, deems them unreadable and "too clever" (as in "where am I going to find cheap developers now?") and makes you revert all the way back to Java 6.

ctstover• 11 years ago

I am the only one that has been thinking for months now that "modern" is the most over used, pointless, and almost negatively connotative word in this industry? Thought exercise: Imagine the ugliest flat and incomprehensible UI widget you have seen lately, the most bloated website load that doesn't crash the browser, and some mindless office dialog about "rising cloud costs". Now pick one word. Survey says - you guessed it. So most certainly, if you need to be more "modern", I'm sure java 8 is a vehicle to take you there.

mark_l_watson3• 11 years ago

This is a really nice write up!

Java 8 is such a huge improvement over previous versions. One thing it still lacks is a better literal format for defining maps, etc.

I just self published a book that uses Java 8 (https://leanpub.com/powerjava if you will pardon a plug) and to be honest I got some pushback from a few people who like my books as to why I didn't use Clojure, Haskell, etc. To be honest I do prefer Clojure and Haskell, but the Java ecosystem is so huge, with so many good libraries that sometimes it is the more practical language to use.

mavelikara2• 11 years ago

Mark, I am sure you know this, but I am posting this for the benefit of others who might not.

For literal maps, I tend to use double brace initialization style. It is more verbose than languages with direct literal support for maps and creates an extra anonymous class, but it keeps the map in a single syntactic construct. For lists, I use Arrays.asList(a,b,c) style; if you static import the method it reads nicely as-list-a-b-c.

pjmlp14• 11 years ago

Which is a no-go in Android as it can prevent GC in some cases, because as anonymous inner class it holds a reference to its parent and you end up leaking Activities.

It is usually presented as anti-pattern in talks about Android performance.

stickfigure4• 11 years ago

Guava has some tools that make map literals a little prettier:

  Map<Foo, Bar> map = ImmutableMap.of(foo1, bar1, foo2, bar2, foo3, bar3, foo4, bar4);

There are overloads for up to 5 entries, and they're even key/value typesafe.

konne88• 11 years ago

Default methods cannot be accessed from within lambda expressions.

Why is that?

ygra• 11 years ago

If I had to guess, it's because the lambda will be expanded at runtime to an anonymous interface implementation. Then either the runtime part is the problem or maybe they use a different, but compatible functional interface for the ad-hoc implementation, which then has no access to default methods on the one you're assigning to.

pjmlp14• 11 years ago

That is not how lambdas work actually work in the reference JVM.

They make use of invokedynamic, there is no expansion taking place as many think.

http://www.infoq.com/articles/Java-8-Lambdas-A-Peek-Under-th...

mabbo4• 11 years ago

My Java code has improve dramatically since I started (ab)using Optionals.

  String foo = Optional.ofNullable(paramater)
                       .filter(...)
                       .map(a -> ...)
                       .map(b -> ...)
                       .orElseGet(() -> ...)
                       .orElse(defaultValue)

Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

grokys• 11 years ago

I'm not so up on Java, could someone explain why they chose "->" for lambdas instead of the "=>" that C# and ES6 use, as those languages seem to me like they would be the first place to look for inspiration.

LoneWolf• 11 years ago

While I don't know the reason i like it because for me is easier to type -> than => (portuguese keyboard, TBH dont know the difference from english)

WaxProlix• 11 years ago

AFAIK that's actually non-standard. Haskell and (more importantly, maybe) C++11 use the single-line arrow (->), as do Erlang and various ML dialects (interestingly, F# uses the single-line notation, too, while C# does not). Probably other languages as well.

kodablah4• 11 years ago

In addition to the other answers, I bet it's easier for a CFG to parse knowing that "->" can't also be "negate and greater than" (since negation is only a prefix op) whereas "=>" can easily be a fat arrow or greater-than-or-equal.

bigtunacan• 11 years ago

I have no idea why Java chose that, but thought it worth mentioning "->" has been in use for Ruby longer than the alternative .NET and ES6 syntax.

tajen• 11 years ago

I'm not an expert. C++ uses -> for pointer dereference, e.g. o->p refers to the property "p" of object "o". I would assume C# inherits from C++ and had to define another operator.

Java probably followed Scala's notation, which is probably derived from mathematics where ↦ is an application (a function) and ⇒ is a simple logical implication.

leothekim• 11 years ago

Hear hear. A couple more features that'd be nice:

- An `public Optional<T> or(Optional<T> other)` so if optA is empty, then `optA.or(optB)` would return `optB`

- A `toStream` method on `Optional` (I believe this is coming in Java 9) or have a `Stream.flatMap` signature that flattens `Optional`s without needing to call `Optional.toStream` (Scala does this, arguable if this is an acceptable munge of Monadic types, but it's really convenient)

wsh91• 11 years ago

Check out fugue: https://bitbucket.org/atlassian/fugue -- a proper monadic Option and more. :) (Full disclosure: I'm an Atlassian and I know/<3 the people who write it, but I also use it a fuckton in my own code.)

the84723• 11 years ago

Coming in java 9: http://download.java.net/jdk9/docs/api/java/util/Optional.ht...

kodablah4• 11 years ago

I believe this use is a real overuse and is definitely abusing. Sure, use optional as a return type when clarity is needed, but otherwise don't do all of this when you could use a simple conditional ala:

    String foo = defaultValue;
    if (parameter != null && ...) {
      foo = doAAndB(parameter);
    }

mabbo4• 11 years ago

Does that really look better to you? More understandable? Methods with the word "and" in them are really awful smells to me too.

Comparing your code and mine, I ask you this: which one do you thing is more maintainable after 5 years of edits?

Each time a new developer needs to add a new case, a new rule, a new whatever, on my Optional (ab)usage, they just add a new line in the appropriate spot, a .filter or a .map or whatever. In yours it's far less clear.

Optional, for me, is wonderful because it lets me have a single return statement. A lot of the code in Java I'm replacing with this pattern is the stuff that has 5 different returns after checks. Crusty old stuff, but the business logic it's running has grown the way it has for good reasons.

malcolmgreaves3• 11 years ago

Welcome to the world of functional programming =D. I personally (and professionally) suggest moving toward Scala when you feel that itch to dig deeper into FP.

incepted8• 11 years ago

Ugh, no. Skip Scala, which is on the decline and headed fast toward obsolescence, and pick a post-Scala language such as Kotlin or Ceylon.

guard-of-terra• 11 years ago

Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one?

Do standard collections have groupBy? You can go a long way with groupBy and zipWith operations, which are a pair like map-reduce but for in-memory handling.

RandomBK• 11 years ago

It might be simplified this this example, but if the mapping function is a method reference or some other reusable lambda, then it can be clearer to use consecutive .map-s

wtetzner• 11 years ago

Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one?

I believe they are automatically combined before the results of the stream are forced.

mabbo4• 11 years ago

Why two .map operations? Three reasons.

#1- If I'm dealing with some legacy code that I don't know well, and it's mapping from one object to a property of it that is another object... well, I'm not 100% certain it's not null.

   .map(a -> a.getB())
   .map(b -> b.getC())

if a.getB() is null, Optional eats it and I'm safe from NPE- I just an a non present Optional value.

   .map(a -> a.getB().getC())

If B is null, I'm going to NPE here (... right? I'm like 99% sure of that, but correct me please). And there are counter arguments like "never be null", etc, but I've got legacy code to cleanup, and no one taught the person who wrote it that particular lesson.

#2- Ease of understanding. Little jumps rather than big ones. Makes the code easier to understand for the next guy who has to work on it. As much as I can, I try to write code that requires no commenting- because it's so clean it's not needed.

#3- The compiler will (or will eventually) optimize it into a single map anyways. Compilers are smart and keep getting smarter. So long as my big-O runtime is fine, I just focus on ease of understanding of my code.

norswap2• 11 years ago

Two things. First, why is it better than:

    String foo;
    
    if (parameter != null) {
        foo = ... ;
    }
    else {
        foo = defaultValue;
    }

or even this, if you express all your transformations as a single expression:

    String foo = parameter != null
        ? ...
        : defaultValue

I don't get it. Your way of doing seem awfully more verbose. Please note that I'm not against Optional in general (although they are overplayed in my opinion).

Second thing, I can't shake off the feeling of inefficiency: building these closures up, calling them. Lots of indirection for something that's probably very simple. I wouldn't want to call this code in a hot loop. But then maybe it's not in a hot loop. Before you bring that up, the sufficiently smart (JIT) compiler doesn't exist. "Sometimes suprisingly dumb" is a better qualifier for many compilers.

Note that I work with Java, and use the Java 8 features a lot. I just think this isn't a really good example.

incepted8• 11 years ago

Actually, your way is awfully more verbose, but you didn't notice it because you ellipsized the verbosity.

If you actually take the time to translate OP's code with your own, you will soon find yourself indented six levels with "if (a != null) { ... if (b != null) { ... if (c != null) {...

You get the idea.

Monads (the type class that Optional belongs to) flatten all this boiler plate with a function called... flatMap! And you don't even need to know about it, all you need to do is chain the calls like OP did:

    Optional.ofNullable(paramater)
                       .filter(...)
                       .map(a -> ...)
                       .map(b -> ...)
                       .orElseGet(() -> ...)
                       .orElse(defaultValue)

without having to check against null every step along the way.

amyjess• 11 years ago

My company switched from 7 to 8 recently, and being able to use streams has been a colossal productivity boost.

I'm actually in the process of putting together a presentation on how to work magic with streams (because I'm one of the few people here who actually knows how to use them), and this will probably get a mention in a "further reading" slide, because it's really well written.

It's also inspired me to make a few slides focusing on the changes to Map and Comparator, which I wasn't aware of until now.

hoffcoder• 11 years ago

A really nice tutorial.

I have been writing Java code since 6 years. Although I can't say that I have programmed in many other languages (I have coded in C/C++ and Javascript), Java has been always very comfortable to use. It's easy to think of a solution in the Object Oriented paradigm, and I think refactoring (when a requirement changes) has not been much of a problem for me. It's only bad designs that make the code more verbose than it should be, and I think verbosity is actually a good way to articulate your thoughts, and see them evolve in front of you. Recently when I started learning Haskell a bit, I found that there are much faster and concise ways of writing code, but I still prefer Java because of the clarity of the way it allows me to express my logic. People would say that writing a line of code in Haskell would do what 10 lines of code in Java would do, but in the long run, I have found that expressing programming paraphernalia like interfaces and classes actually helps the coder in his job (not necessarily results in wastage of time).

mkobit2• 11 years ago

It wasn't touched on in this document, but I think more people should hear about Nashorn. It is the new JavaScript Engine that, I believe, supports ES 5.1. It allows you to do some pretty neat things with Java/JavaScript interacting in the same VM. Java 9 is planning on supporting ES6 <source needed>.

You can see an introduction on this Oracle documentation: https://docs.oracle.com/javase/8/docs/technotes/guides/scrip...

neemsky123• 11 years ago

so... when is this coming to android?

on_and_off• 11 years ago

Support for java 8 will come with jack & jill. It might also need a new API level (24 ? ), which would seriously hamper its adoption. This is why many people see kotlin as a great thing for the future of Android (even though kotlin on android could also benefit from java 8 as a target)

thelastnode• 11 years ago

You can use a good number of these today with Retrolambda: https://github.com/orfjackal/retrolambda

vvanders• 11 years ago

Really like quite a few Lambda stuff in Java8, sadly once you need to touch any of the intrinsic types it gets ugly real fast. Wanted to do some byte manipulation with Lambda and I'd be creating a new Byte object for each byte I touched.

stephen• 11 years ago

For people getting into Java 8, jOOL is a great, small library with a "Seq" class that fills in the gaps missing in j.u.stream.Stream:

https://github.com/jOOQ/jOOL

E.g. if you're coming from groovy/Scala and wonder "why doesn't Stream have this method?", Seq probably either already has it, or the maintainer will be open to adding it for you.

So, use jOOL. It's great.

That said, I still cringe that we have to do "someCollection.stream()..." (or use fill-ins like jOOL) at all, because these methods aren't on j.u.List/etc. itself...

My naive impression is that the JDK designers fixated on making streams support parallelization (because fancy!), and so made some compromises on the API, when in reality 98% of collections are small/not parallel, and I assert a non-parallel, more complete API (e.g. more default methods directly on j.u.List/j.u.Iterable themselves) would have been a net-win to most programmers.

And the parallelized version could be a separate library/jar/something.

mkobit2• 11 years ago

That library has some fun/interesting generics declarations like this one (https://github.com/jOOQ/jOOL/blob/master/src/main/java/org/j...)

static <T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16> Seq<Tuple16<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>> crossJoin(...

arjie• 11 years ago

Sort of like http://www.scala-lang.org/api/current/index.html#scala.Tuple...

masklinn6• 11 years ago

Pretty much all languages with generics will have that kind of declarations, the only question is how many type parameters they'll go up to. In C# Action goes up to 16[0] while Rust's tuple go to 12[1] and GHC goes to 62[2] (intending 100, but a comment notes declaration of a 63-wide tuple constructor segfaults)

[0] https://msdn.microsoft.com/en-us/library/dd402872(v=vs.110)....

[1] https://github.com/rust-lang/rust/blob/master/src/libcore/tu...

[2] https://downloads.haskell.org/~ghc/7.2.2/docs/html/libraries...

guelo• 11 years ago

The changes are breathtaking. It doesn't feel like Java.

snambi2• 11 years ago

Gosh... java is getting uglier by these weird syntax.

Modern Java – A Guide to Java 8

Related Stories