Yes, as best as can reasonably be managed while interoperating seamlessly with Java. null still exists but the community strongly discourages using it (and there&#x27;s a compiler plugin that will make it a warning or an error). Standard library methods don&#x27;t expect or return null (e.g. Map#get returns Option), and the ecosystem follows the same convention. Option is very widely used and supported in for&#x2F;yield syntax; better still it&#x27;s a normal type in the language that can be abstracted over by the usual mechanisms (e.g. scalaz defines a Monad typeclass for it, so generic methods like traverse will work for Option). When wrapping a Java library you have to use your own judgement to know whether a method can return null (it&#x27;s either that or force you to check every java method call, which some languages do but makes interop awkward); best practice is to wrap any calls to a possibly-null method in Option(...) immediately so that the null never &quot;escapes&quot; into Scala-land.<p>Of late the scala-native ecosystem has grown to the point where you can largely avoid using Java libraries at all. I can&#x27;t remember the last time I saw a null or a NullPointerException at my Scala job.