Generics Type Erasure: If this generics info at runtime is important to you, you can get that with JVM languages like Kotlin.
"real" co/contra type variance generics: You can also get this on the JVM with Kotlin or Scala if this is an important feature.
first class functions: Pretty much every JVM language except Java has this.
Closures: Java has outer variable capture, which is the textbook definition of closures. Java has closures. Java does have the "final" requirement on outer variable capture, which some people argue that makes Java have not "real" closures, but this was done on purpose as letting programmers capture non-final variables would be a common source of programmer error as you see in C#.
Secondly, I'd argue that for overall language cleanliness and conciseness, languages like Kotlin and Scala go beyond C#/Java.
Thirdly, I'd argue that JVM has the broadest language support. Languages like Scala and Clojure and Fantom released both.NET and JVM versions, but only the JVM community really took them seriously and adopted them. The.NET culture is generally a very Microsoft-only place.
Dalvik had a bunch of design aims: faster load times, lower memory footprint, and reduce battery power draw. Long-running runtime performance has always been better on the Java HotSpot worktstation/server VM. Dalvik was never aiming to beat the traditional VM in this regard.
Slashdot Mirror
Generics Type Erasure: If this generics info at runtime is important to you, you can get that with JVM languages like Kotlin. "real" co/contra type variance generics: You can also get this on the JVM with Kotlin or Scala if this is an important feature. first class functions: Pretty much every JVM language except Java has this. Closures: Java has outer variable capture, which is the textbook definition of closures. Java has closures. Java does have the "final" requirement on outer variable capture, which some people argue that makes Java have not "real" closures, but this was done on purpose as letting programmers capture non-final variables would be a common source of programmer error as you see in C#. Secondly, I'd argue that for overall language cleanliness and conciseness, languages like Kotlin and Scala go beyond C#/Java. Thirdly, I'd argue that JVM has the broadest language support. Languages like Scala and Clojure and Fantom released both .NET and JVM versions, but only the JVM community really took them seriously and adopted them. The .NET culture is generally a very Microsoft-only place.
Dalvik had a bunch of design aims: faster load times, lower memory footprint, and reduce battery power draw. Long-running runtime performance has always been better on the Java HotSpot worktstation/server VM. Dalvik was never aiming to beat the traditional VM in this regard.