Everything about Java 8

Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but...

- Getters and setters, C# style. That is, instead of

    private int foo;
    public int getFoo() { return foo; }
    public void setFoo(int value) { foo = value; }

write this:

   public int Foo { get; set; }

which is both easier to write and makes code more readable and understandable.

- Mandatory exception declarations in methods. I still don't understand why this is necessary. It ends up either leading to stupid errors (see the following example from the article)

    void appendAll(Iterable values, Appendable out)
            throws IOException { // doesn't help with the error
        values.forEach(s -> {
            out.append(s); // error: can't throw IOException here
                       // Consumer.accept(T) doesn't allow it
        });
    }

, or to lots of methods just throwing Exception (bad practice, I know, but it's easy to fall in), or to useless empty try-catch on methods that won't throw an exception (because you've checked it) and don't want to add the throw declaration.

- Modifying external variables in a lambda expression. Just as everyone is used to in Javascript, Ruby, C#... It's pretty useful, even more when you're using lamdbas for common operations such as forEach.

- Operator overloading. When you're using data classes (for example, models from a database) where different instances actually point to the same object, overriding == it's more comfortable than foo.equals(bar). Also, the downside of using .equals is that, if foo is null, you will end up with a nice NullPointerException out of nowhere.

- Events! I'm amazed how easy is to do events in C# versus how hard (and bloated) in Java. Take this as an example: http://scatteredcode.wordpress.com/2011/11/24/from-c-to-java...

- Pass by reference. Just as if you were passing a pointer in C. I find it surprising how few languages implement this feature, which is pretty useful...

And I'm sure I'm missing something...

Edit: added three bullet points.

Without operator overloading you cannot write an EDSL.

Java 8 looks good enough to make Java a reasonable candidate for Java.Next. Especially given that there doesn't appear to be a clear winner between the alternatives (Scala, Groovy, Clojure, Kotlin etc.).

Java 8 seems to have borrowed a lot from Guava (Optional, Function, Predicate, Supplier etc.).

Extension methods as well as default methods on interfaces would have been nice.

At least with respect to checked exceptions, my read of modern popular convention is simply to avoid using checked exceptions unless there is a very strong use-case. In our own code, we have transitioned to using predominantly unchecked exceptions with no decrease in code quality that we have yet perceived.

Agreed on assuming the trivial getters and setters if they are not expressly defined. That would be nice.

As for modifying variables in lambdas, you need to have a final reference available, meaning you can't modify a primitive. However, you can accomplish roughly the same thing by using a final reference to a boxed (or if parallel, atomic) primitive.