Next Generation Java is Not Very Different From Today's Java
In a recent post, Stephan Schmidt makes several suggestions in order to write "Next Generation Java". Unfortunately, I disagree with most of them... Let's take them in turn:
This is guaranteed to make your code littered with final keywords and therefore, impair readability significantly (same problem as Python's self pollution). And it really doesn't buy you that much, I can't even remember last time I was bitten by a bug involving the reassignment of a variable to a different value within a code block. For what it's worth, final on non fields is banned from Google's style guide (except where it's unavoidable, such as when you need to pass variables to inner classes).
It would be nice, but it's just not realistic. Sometimes, you really don't want to put that many parameters in a constructor (and the Builder pattern doesn't solve this problem either). Besides, it's convenient to be able to mutate object if you want to use pools. As for not using accessors overall, Stephan is not the first one to argue that they should be removed from OO programming overall, but this claim is easily debunked.
Java is not very well suited to a functional style, so I think the first example is more readable than the second one that uses Predicates. I'm guessing most Java programmers would agree, even those that are comfortable with comprehensions and closures and especially those that aren't.
Use one liners
Depends. Sometimes, breaking down the expression and introducing variables clarifies the intent of the code and it also makes it easier to use break points.
Use objects with interfaces
A good advice overall, but don't go overboard. I have argued something similar in the past under the name Quantum Software Design but introducing too many interfaces can result in an explosion of little classes that cloud the intent of your high level classes.
Again, it's dangerous to use a programming style that Java was not designed for. java.util.concurrent is a treasure trove of very useful constructs and I'd rather see a set of well architected Java abstractions built on top of it than an emulation of Erlang's actor architecture.
Now that's an interesting recommendation since it contradicts directly Stephan's suggestion of not using setters, because make no mistakes: fluent interfaces are setters in disguise. So, Stephan, which one is it? :-)
Use public fields
No. Just, no. You will never regret adding accessors to your classes if you need the data, but I can promise you that you will rue the day where you decided to be lazy and to make a field public.