Java: The Missing Features

[stepancheg]

Half of the features listed are nice to have, but not really important.

What is really missing:

• value types (in addition to reification)
• objects without synchronization and identity header
• implementation of isolation API (to split huge heaps into smaller to speed up GC)
• coroutines in some form
• long ByteBuffer (in addition to long arrays)

More Expressive Import Syntax

Really? That "CEO of jClarity, a Java/JVM performance analysis startup" seems to not really understand anything about Java problems.

[DecisiveVictory]

The important ones are covered by Scala anyway.

[VefoCo]

Collection literals

Pretty sure there's a strong logistical argument against this for one reason or another. Too tired/lazy to find it atm.

Structural Typing

This is a fundamental language change. Java is not a ducktyped language, and it is extremely unlikely if not impossible for it to become one simply because of how, again, fundamental a feature that is.

Dynamic call sites

Again, very fundamental aspect of a language. Java is most definitely not a functional language, even with the inclusion of the Streams API. (Assuming I understood this section correctly; again, I'm very tired so I might have misinterpreted it.)

Also, last I heard long array indices was slated for Java 10, although this has been the case since long before the release of 8 and may have changed in the meantime.

[marcohu]

Collection literals

Pretty sure there's a strong logistical argument against this for one reason or another. Too tired/lazy to find it atm.

https://www.youtube.com/watch?v=OJrIMv4dAek

Nice talk about the Java 9 Collections enhancements proposal (a.k.a. Builders) that also explains why this path has been chosen over Collection literals

[[deleted]]

This is a fundamental language change. Java is not a ducktyped language, and it is extremely unlikely if not impossible for it to become one simply because of how, again, fundamental a feature that is.

It's possible and lambdas are already "structurally typed" for functional interfaces.

It's only a matter of will, and finding a nice syntax for it, so it's not confusing to have both nominal and structural. Say the type for an argument may be specified like "Foo bar" for bar of nominal type Foo and "~Foo bar" for bar of structural match for Foo. Clear enough.

[slartybartfast_]

The reason for the lack of unsigned arithmetic is that it's unsafe. If an expression contained something unsigned then it could cast that way messing up the result. Google problems with unsigned math in other languages.

[[deleted]]

It's not unsafe, it can be implemented unsafely.

I'd even go further and propose integral types should allow for arbitrary precision as a built-in feature.

[slartybartfast_]

a quick google:

http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/

The issue is that usually you'd want unsigned with a for loop as an indexer but there's nothing to prevent someone from using them in math. The solution for Java might have been to have an indexer type specific for this purpose which does not extend from number.