The following WebDSL statement

parent.assignments.set(i, a);

generates this code

if(i0 - 1 >= 0 && i0 - 1 < this.getParent().getAssignments().size())
{
this.getParent().setInAssignments(i0 - 1, this);
}

It causes a Null Pointer Exception in the condition, which can only be due to the size() call (as deduced by previous statements that access parent and assignments without causing an NPE).

exception during execution of action
java.lang.NullPointerException
at webdsl.generated.domain.Assignment.up_(Assignment.java:3921)
at webdsl.generated.templates.assignmentCollectionAssignmentCollection__String__Bool_ta6Assignment__List_Assignment___Bo126String__AssignmentCollection__String__Bool__List_Assignment___Assignment_Template$3.run(assignmentCollectionAssignmentCollection__String__Bool_ta6Assignment__List_Assignment___Bo126String__AssignmentCollection__String__Bool__List_Assignment___Assignment_Template.java:602)

This code used to work. Has there been a change in the implementation of size?

Submitted by Eelco Visser on 8 October 2012 at 11:14

By the way: it seems expensive (in terms of code size) to perform these tests at call site of the set operation; why not do it in the definition of setInAssignments?

The implementation of size did change, to fist fetch the complete collection when automatic filtering was applied. However, if the NPE occurred there, then I would expect the methods that make up its implementation to be part of the stack trace. In the provided code sample I think it is more likely that this.getParent() returns null, because it seems to be a single-value property and the collection property is not null, because Hibernate does not make a distinction between null and an empty list and would initialize the property with an empty list.

The setInAssignments(index, value) operation already contains the index check, because it calls webdsl.generated.domain.AssignmentCollectionAssignmentsList.set(index, value), which performs the check. The check is probably also performed at the call site, for when the collection is not a property of an entity, which also means that it is not persistent.

We figured out the problem, there was an additional .set call above it which replaced the current item in the list of the parent, which also set the parent to null because of inverse annotation. The second .set call would then fail because parent==null.

The generic bounds check is generated at the call site to cope with all possible lists in WebDSL, which indeed are not always entity properties.