FP and OOP are compatible styles. In fact, I would argue that FP is more object orientated than procedural code such as loops.

Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.

In support of FP and OOP being compatible:

      The venerable master Qc Na was walking with his student, Anton.
  Hoping to prompt the master into a discussion, Anton said
  "Master, I have heard that objects are a very good thing - is this true?" 
  Qc Na looked pityingly at his student and replied, "Foolish pupil -
  objects are merely a poor man's closures."

      Chastised, Anton took his leave from his master and returned to his
  cell, intent on studying closures.  He carefully read the entire
  "Lambda: The Ultimate..." series of papers and its cousins, and
  implemented a small Scheme interpreter with a closure-based object
  system.  He learned much, and looked forward to informing his master of
  his progress.

      On his next walk with Qc Na, Anton attempted to impress his master by
  saying "Master, I have diligently studied the matter, and now understand
  that objects are truly a poor man's closures."  Qc Na responded by
  hitting Anton with his stick, saying "When will you learn? Closures are a
  poor man's object."  At that moment, Anton became enlightened.

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Nothing in OOP requires mutable state.

    Thing changedThing = oldThing.change();

When you start writing code like this, Java can be quite pleasant.

It's only very special circumstances where my POD types do not consist entirely of `final` fields. Though I usually skip defensive copying within PODs... One should know better than to trust values from random places. So I defensively copy at use time instead if I want to modify it.

Kotlin, Java's superior offspring, is even better, as the use of data classes provides an automatic implementation of a `copy` command. (Scala does too, but Scala also explodes when I look at it, so, enh.)

Since lambdas and streams are optional, what is your critique of them?

I'm guessing they work on a team, and other members of the team are using them.

Please explain how "I don't have to init an ArrayList and add to it manually" is such a heaven-forfend perversion of that traditional, solid language.

To be fair, the implementation of Streams within Java is certainly filled with ugly boilerplate compared to LINQ in C#. But that's no reason to criticize their mere existence.

Yes, adding lambdas to Java is as silly as adding function pointers to C.