Question

When working with Java from Scala, we have to account for null.

HttpServletRequest getters (getAttribute, getHeader, etc.) for example, all potentially return null.

I know I can manually do a case/match or map operation on each call to an HttpServletRequest method, but that’s a bit tedious. Also, method calls like request.getHeader(“Accept-Encoding”) are a mouthful.

I came up with an enrichment to handle both issues:

class Servlet_Request_Provides_NullSafe_Getters (r: HttpServletRequest) {

  def header(s: String) = Option( r.getHeader(s) )
  def attrib(s: String) = Option( r.getAttribute(s) )
  def remoteHost        = Option( r.getRemoteHost )
  def accepts = header("Accept-Encoding")
}
implicit def request2Option(r: HttpServletRequest) = 
  new Servlet_Request_Provides_NullSafe_Getters(r)

1) Is there another/better way than enrich-my-library to achieve the same/similar affect?
2) If this is “the” way to go, what are the performance impacts/risks? In other words, can one get burned by the apparent utility/conveniences of this pattern?

Sorry if this stuff is obvious, only just started enriching the other day, and it really seems quite useful. Just want to make sure I’m applying the pattern in the proper scenarios…

EDIT
@dhg pointed out that Option.apply() and:

def safe[T](v: T) = v match {
  case null => None
  case x => Some(x)
}

are equivalent, so the getter methods now use Option(f()) instead of my extraneous safe(f()) wrapper

Thanks

Answer 1

As already mentioned in the comments:

def safe[T](v: T) = Option(v)

Option(v) is equivalent to:

v match {
  case null => None
  case x    => Some(x)
}

Also the safe method is unnecessarily public and part of the class. I would suggest simply inlining it.

2) If this is “the” way to go, what are the performance impacts/risks?

Generally adapting Java legacy APIs to utilize Option is a good idea. I do this often with EntityManager.find() that can return null.

Your implicit conversion is also fine. However don’t use underscores in class names, Java/Scala naming conventions prefer CamelCase.