NPE in Table

I am using Vaadin 6.5.0 and encountered a problem. What could possibly lead to following exception:

SEVERE: Terminal error:
        at com.vaadin.ui.Table.paintContent(
        at com.vaadin.ui.AbstractComponent.paint(
        at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.writeUidlResponce(
        at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.paintAfterVariableChanges(
        at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(
        at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(
        at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(
        at javax.servlet.http.HttpServlet.service(
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(
        at org.apache.catalina.core.StandardWrapperValve.invoke(
        at org.apache.catalina.core.StandardContextValve.invoke(
        at org.apache.catalina.core.StandardHostValve.invoke(
        at org.apache.catalina.valves.ErrorReportValve.invoke(
        at org.apache.catalina.core.StandardEngineValve.invoke(
        at org.apache.catalina.connector.CoyoteAdapter.service(
        at org.apache.coyote.http11.Http11Processor.process(
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(

What most surprises me is the fact that none of my classes is mentioned in the stack trace above. Also the line which is causing problem should never cause a NPE - that would mean that first of the rendered columns is null inside the Table implementation…

Putting it simple - I’m stuck, any help would be appreciated.


That’s really odd. The line in question is
, where total is an int, so the NPE is strange. Are you able to reproduce this exception in a small test application or does it only happen in your application? If you can find a way to reproduce it we can debug it.

Have you tried updating to 6.5.1 and see if that has any effect?


Hello and thank you for reply.

The problem occurs on a semi-production environment and inside a quite large application. I couldn’t reproduce it locally and updating to 6.5.1 there would require some work.

In Vaadin 6.5.0 the line in question looked like:

        int rows;
        if (reqRowsToPaint >= 0) {
            rows = reqRowsToPaint;
        } else {
2317:       rows = cells[0]
            if (alwaysRecalculateColumnWidths) {
                // TODO experimental feature for now: tell the client to
                // recalculate column widths.
                // We'll only do this for paints that do not originate from
                // table scroll/cache requests (i.e when reqRowsToPaint<0)
                target.addAttribute("recalcWidths", true);

        if (!isNullSelectionAllowed() && getNullSelectionItemId() != null
                && containsId(getNullSelectionItemId())) {

This is probably related/similar to the issue
where getVisibleItemIds() is called before the table is rendered for the first time, but what triggers the problem in your case is not clear to me. What operations are you performing on the table after it has been displayed (adding/removing columns, modifying alignments, changing the data source, …)?

As for the line numbers not matching up between SVN and the packaged classes, the packaged files have a small license header that causes a fixed offset.

After going through the server logs I found that there is an issue with my code. One of ValueChangeListeners added to this table failed with NPE. I’m not sure if it caused NPE mentioned in this first post, but I believe it might have.

I will be able to tell if fixing NPE in listener resolved my problem only after the server environment is updated. In the meantime - can such listener mess Table’s lifecycle?

It might be possible if the exception occurs between some operation that resets the internal buffers of the Table server side component and re-rendering the Table.

Sorry for re-opening a 5 year old discussion, but looks like the problem still exists, at least in the 7.5 stream.
I attached a snippet to reproduce at issue
Bad thing on this is that the application even doesn’t recover after Browser refresh. So affected users either have to remove their session cookie or restart the server :frowning:

Edit: Attached a patch to the aforementioned ticket that resolves the issue.