I'll meet you halfway:

      ints.sort((o1, o2) -> {
          if (o1.equals(o2)) {
            return 0;
          } else if (o1 < o2) {
            return 1; 
          } else { 
            return -1;
          }
      });

Or may i suggest a version with a guard clause and a simple ternary:

      ints.sort((o1, o2) -> {
          if (o1.equals(o2)) return 0;
          return (o1 < o2) ? 1 : -1;
      });

There's definitely no need for the 'new Comparator' boilerplate any more. That's not the kind of verbosity that adds clarity; it's just ceremony.

shrug. This seems like a pretty standard use of the ternary operator to me. I mean, just google examples of Comparator, and you'll find tons of examples like this:

   @Override
   public int compareTo(Object arg0) {
       Country country=(Country) arg0;
       return (this.countryId < country.countryId ) ? -1:
              (this.countryId > country.countryId ) ? 1:0 ;

   }

(http://www.javacodegeeks.com/2013/03/difference-between-comp...)

But that's orthogonal to my point, which is that lambdas offer significant improvements to readability because they remove the irrelevant cruft and simplify the code.

And lambdas (or similar) has existed in C#, Python, Scala, Javascript and other languages for years. I still thinks this means that those languages has had large benefits compared to Java (7 and older). Now that Java 8 has lambdas even Java developers can learn to write better and more readable code. I also thinks that Java 8 is good enough for most projects now but Java 7 wasn't. Just my thinking.

I'd have to agree, the GP is very bloated when a simple ternary will suffice.

one line is way more readable than 7 lines taking up valuable vertical and brain space

it could also be accomplished with

    return -1 * o1.compareTo(o2);

Why not:

    return o2.compareTo(o1);

because the o2 vs o1 is easy to miss, while the -1 makes it obvious i'm intentionally reversing. my .02

Not if you give them more descriptive names

No, you can't. In particular -1 * Integer.MIN_VALUE == Integer.MIN_VALUE.

That would probably never matter in practice, though—I've rarely seen compareTo() return anything other than -1, 0, or 1; certainly never anything approaching MAX/MIN_VALUE. Still, bravo for considering all of the edge cases.