Modern Java – A Guide to Java 8

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

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

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.

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

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

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.

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

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.

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

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

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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