Java 8 Features (infoq.com)

There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures.

But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null.

Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them).

Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for fcks sake?

There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures.

But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null.

Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them).

Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for f@@cks sake?

Unfortunately the legal fight between Oracle & Google has really made me doubt that the cool new language features will be coming any time soon to Android.

That would be a step backward, we really need generics and a reasonable support for exceptions on Android (or any large scale system, for that matter).

Go is a fine language at the system level or to replace Ruby/Python scripts but that's about it.

We're quite a bit slower at migrating existing applications (except for security issues), but because we code defensively, we are generally backwards compatible.

    Arrays.sort(arr, Concurrency.LEVEL)

ForkJoinPool forkJoinPool = new ForkJoinPool(2); forkJoinPool.submit(() -> // write your parallel query here ).get();

https://en.wikipedia.org/wiki/Coroutine

https://en.wikipedia.org/wiki/Coroutine#Implementations_for_...

Yup, the C# library is called Interlocked and it provides a variety of atomic operations. C# also has ref, which allows variables to be passed by reference, which greatly increases the power of the library.

I find Interlocked absolutely essential for getting maximum performance -- like in implementing lock-free data structures.

You aren't forced into sharing memory across parts of your program that have no business sharing memory. In Java you can easily end up in a situation where you can look at a program and not know what thread one line is executing in versus another line in the same file. The same instance of a class may be referencing one of its property in one thread or another, and that's sharing memory across threads. A simple if statement may fail you when you share memory across threads because after the if statement checking shared memory evaluates the underlying value for that property it may have changed before the next lines after your if statement executes.

Coroutines as they exist in Go or C# help programmers write code that don't share memory across threads. Akka does this, try it, it's amazing. Java needs native support. Threads are shit. Sharing memory across threads is a nightmare.

Edit: If you're going to downvote, explain why I'm wrong.

Why? The one issue I have with Task is the aggravating SynchronizationContext/continueOnCapturedContext. ConfigureAwait(false) really should have been the default. Otherwise, my experience with both seems about equivalent.

Aggression that's really the result of thread frustration in Java. I hadn't read about middlebrow dismissal before, I can see how my post came off wrong. I'm glad I posted what I said however, because I the responses taught me new things.

My company is running it on production with no issues.

  String result = "UNKNOWN";
  T a = X.getA();
  if (a != null) {
    T b = a.getB();
    if (b != null) {
      String c = b.getC();
      if (c != null) {
        result = c;
      }
    }
  }