Java is weighed down by null and embarrassed by its halfhearted Optional type. It is certainly possible to have a codebase in which NullPointerExceptions are practically never seen, but the reality is that this is hard work. Oracle muddied the waters by telling developers not to use its Optional for field or parameter values, but as with many features introduced in Java 8, it was good enough and was adopted into the mainstream usage of Java.ĭepending on its age, your Java code may use some or all of these strategies for dealing with absence. They came to appreciate the advantages of using an Optional type (named Option in Scala’s standard library) when absence was possible, and plain references when it was not. More crucially, though, Java 8 also introduced a standard Optional type.īy this time, many JVM developers had dabbled in Scala. Java 8, released in 2014, enhanced support for annotations to the extent that tools like the Checker Framework could statically check much more than just null safety. Some codebases opted to use and annotations instead, often supported by tools that would check for correctness. Within a codebase, this works well enough (even if it is a little verbose, and requires eternal vigilance to avoid the scourge of NullPointerExceptions).
So we might name a field addressLine3OrNull, or a method previousAddressOrNull. Over the years, your authors and their colleagues settled into a convention where Java references are assumed to be nonnull unless otherwise flagged. We can deduce that methods that return an item from a collection must be able to return null, but can addressLine3 be null, or do we use an empty string when there is no information? Prior to Java 8, Java relied on convention, documentation, and intuition to distinguish between references that could or could not be null. This is another area where the grains of Java and Kotlin are different.
Perhaps Kotlin’s most attractive feature for Java programmers is its representation of nullability in the type system.
0 kommentar(er)
