128-bit floating point? Why exactly? What hardware out there supports this, what problems does it solve that 64-bit floats or bignums don't? Why add more intrinsic types to the type system that will need vm and library changes when you could implement them in java?

Suggesting that fields and properties be the same thing suggests a lack of understanding as to why they are different. Traits, classes and interfaces, likewise, are not the same thing, and suggesting they are makes me wonder if the author knows what problems each feature is used to solve.

Only someone who doesn't know how hard date and time classes are to design would rattle off 'a better date and time' with no suggestion of what better looks like and how you achieve it.

Access to all variables at runtime? Sure, as long as you don't mind disabling dozens of important optimizations for a feature only debuggers have good reason to use. Bundle an assembler with the jvm? For what purpose? Java apps are already far less portable than they should be.

his comments on the class file format also suggest confusion: nesting types inside method definitions only makes sense in an environment like python where type definitions can be created dynamically at any time. Java simply doesn't work that way, so his proposed nesting would complicate class loading for no benefit. The 64k limit is ugly, but any method with 64k worth of code in it suggests deep architectural problems that will complicate everything - compilation, jitting, debugging, static analysis.

I never thought I'd be longing for sun's inept stewardship of java, but If this is what oracle has to offer...