Actually, I waffle on checked exceptions; it seems every 8 months or so I have a different opinion of them. Right now they suck.

It always bothered me that Java forces me to explicitly handle/rethrow exceptions, yet happily overflows my ints without batting an eyelid.

Initially I threw a Runtime (ie: non compile time) exception. After going to production I realized that these were bubbling up to the UI and giving the user very intimidating error messages. So I changed the exception to a Compile time exception and then the compiler caught every place I let the error slip through to the UI. In my opinion it saved me a lot of time and made my code easier to maintain.

1: EG: Who is Java to say that this IOException should be handled in code? Perhaps this IOException should not happen and requires a developer's intervention.

  I'm so tired of writing null checks ...

I guess I kinda wonder if I could avoid the null checks in C# somehow ... I figured using a design by contract approach might be used to reduce the null checks somewhat.

[0]: http://stackoverflow.com/questions/156395/sending-a-message-...

It's definitely NOT awesome. This stupid behaviour causes bugs all the time as you think you're doing an action but it's actually a no-op because something else failed and you get a nil. An NPE is awesome - it crashes immediately and you know exactly what is wrong. A silent no-op is the worst thing to debug.

http://msdn.microsoft.com/en-us/library/ms173224.aspx

Without seeing your code it is hard to say, but using an object extension might work?

On many occasions I've used object extensions to hide checking code deep inside the extension.

C# really got that feature right.

https://github.com/benjiman/expressions/blob/master/src/test...

implementation

https://github.com/benjiman/expressions/blob/master/src/main...

Let's not forget about type-erasure generics. And the existence of arrays. And the fact that people still use arrays.

Type-erasure generics are a fortuitous platform decision, because its what enables languages on the platform to have a good interop story while still having a more robust type system than Java does -- case in point, Scala, and why the .NET version died.

But type-erasure of generics - that's the decision with which we will need to live till the end of time.

  - no multiple implementation of same generic interface
  - http://stackoverflow.com/questions/2723397/java-generics-what-is-pecs
  - small performance hits..
  - casts
  - a lot more but I'm just sleepy right now.

I hear you.

I assumed this was a reference to the unequal handling of "primitive" types vs Object types, with only the latter being able to be used with generics. Except for the weird "dual" object types which sortof are and sortof are not equivalents to the primitive types (int -> Integer, etc). WHich for methods needing to take actual primitives leads to having to do abominations of repetition such as http://www.docjar.com/docs/api/java/util/Arrays.html.

Some other bad things (not necessarily "complicated" but it does complicate the code that needs to be written):

Enumerations all have to have the same constructor params and therefore the same "shape". SOrt of defeats the purpose of enumerating ALTERNATIVES, I would say (this is part of the lack of sum types that was mentioned, though).

Others mentioned nullability. Some other things I didn't see others mention:

Botched covariance of arrays which leads to runtime failure where compile time should have been sufficient, http://k2java.blogspot.com/2011/07/parametrized-types-and-ar....

Some other minor things, such as botched clonability system, where Cloneable is a "marker" interface that doesn't tell you whether some type is really cloneable, a bizarre unforced error where a simple interface (you know, with an actual method called "clone") would have sufficed.

http://download.java.net/jdk8/docs/api/java/util/Optional.ht...

    optionalF.map( _.whatever ).getOrElse(fallback)

    (optionalF <+> optionalFallback).getOrElse(finalFallback)

    optional match {
      case Some(x) => whatever(x)
      case None    => fallback
    }

The speed benefit is well known, as is the corollary, premature optimisation. I expect checking for null is even faster if speed is the main concern. It's an engineering tradeoff, just like making the abstraction to a monad (or monad plus). In the normal course of events I'm more concerned about flexibility than performance and would prefer the abstraction.

  resultOption match {
    case Some(x) => println(x)
    case None => println("error")
  }

  if (resultOption.isDefined) {
    println(resultOption.get)
  } else {
    println("Error")
  }

  import java.util.Optional;

  public class Scratch {
      public static void main(String... args) {
          Optional<String> foo = Optional.of("foo");
          Optional<String> bar = Optional.empty();

          System.out.println(foo.orElse("Error"));
          System.out.println(bar.orElse("Error"));

          foo.map(Print::print).orElseGet(() -> Print.print("Error"));
          bar.map(Print::print).orElseGet(() -> Print.print("Error"));

          foo.ifPresent(Print::print);

      }

      static class Print {
          public static <T> T print(T val) {
              System.out.println(val);
              return val;
          }
      }
  }