Whiteboard results - Native XML

Whiteboards

Whiteboard results - Numbers

Null handling

This page documents the results from the Null handling whiteboard where all Javapolis 2006 participants were encouraged to participate with their ideas.

Avoid NPE in method/field access

The first proposal was to avoid the many not-null checks that we currently write:

String postcode = person#getAddress()#getPostcode();

this would be syntactic sugar for

String postcode = null;
if (person != null && person.getAddress() != null) {
  postcode = getPostcode();
}

This yielded comments:

• "I want this in Java 5.1 !"
• "Why not use ? instead of #"
• "How about ?. like Groovy"
  • ".? is two characters, one with shift key, # is one character"
• "Great idea, any JSR on it yet???"
• "Any way to handle this with AspectJ"
  • "I actually did something like this with AspectJ - a.getB().getC() would return null if a, b or c was null. Compared to using a real Null Object Pattern its a hack though.
• "Could we have a way to set a default in case of null: eg. String postcode = person#getAddress()#getPostcode() : 1000;"

A straw poll vote was taken on this issue - Should Java syntax be changed to help avoid NPEs?

Not null variables

This proposal was to be able to define fields such that they cannot be assigned to null.

"SQL has NOT NULL, why not Java"

Comments include:

• "Perhaps we could use # for this too: #String str = 'Hello' meaning that str cannot be set to null"
• "Won't this need a NullAssignmentException for runtime assignments"
• "Why not use @NotNull"
• "I think there is a JSR for static analysis of source code (JSR-305)"

Null types

This proposal was to have dedicated types for null handling.

Why not allow multiple NullType values?

class DomainObject {
  public static final NullType UNCHANGED = new NullType();
  ...
}

DomainObject obj = new DomainObject();
obj.setProperty(null);
obj.setProperty(DomainObject.UNCHANGED);

Setting the property to null would have the same effect as setting the property to UNCHANGED.

The intent was clarified by:
"I mean objects that have the same semantics as a certain class but can't be expressed with that class. Like a Date TOMORROW (implemented as a class) which evaluates to the date after the current whenever it is evaluated, but can be passed as a parameter. This could be implemented with the Null Object pattern sometimes, but not always, like in the case of a special long or Double object, because these classes can't be extended. eg. when you want to have the exact value PI instead of the nearest Double - like Double.INFINITY.

Comments were:

• "Is this about enforcing the null object pattern"

Aspects to check method parameters

This proposal was to check method parameters using annotations. All field mutation should be via the setter (not enforced), and the aspect would use the annotation to check the condition was true before the method code was called.

class Person {
  public void setAddress(@NotNull Address address) {
    ....
  }
  ...
}

Comments include:

• "How about including in the NPE which method parameter caused the NPE"