[–] BrokenVoat ago 

How about multiple inheritance?

[–] DukeofAnarchy ago 

[–] BrokenVoat ago 

Ok boomer

[–] SithEmpire ago 

I've been watching the JDK releases quite closely, though haven't pulled the figurative trigger since 8 in 2014 (very major release, introduced lambdas).

Since then, a few things look interesting such as the native executable tools and the pattern matching features, but the modest convenience has not quite been enough to justify allocating time for moving large projects to a new JDK.

Now while I'm also not about to get the team to move anything to Kotlin, if a JDK release would introduce Kotlin's notion of "nullable" variables then that would justify an update. This is where (for example):

  • A String type is guaranteed not to be null
  • A "String?" type may be String or null ("nullable")
  • It is a compile error to access members of a String? type
  • Conditional code which has tested that a String? is not null may proceed to access it as if casted to String (the pattern matching comes really close to this, just lacks the actual identifier notation)

It would be difficult to integrate though, possibly needing compiler options or annotations in classes where it should be enforced, or perhaps do it more easily the other way round (e.g. String is nullable but String! must not be null).