Trying to save PDF (with all the fields fillable) in hard-drive, instead of streaming to browser. All the fields in the PDF are fillable. These fileds get populated programatically with values. In the future, this populated PDF (which is also fillable) could be opened from hard-drive using CutePDF for further editing.
In that particular line? Or is there a stack trace that points to something that gets called by "setField"? If not, is "acroFields" null? (It's probably blatantly obvious that it isn't, but just to make sure.)
No, neither of these variables are null. The acrofields itself is not null. Nor the variables (filed and value) atre null. It throws only NullPointerException. No exception message is being thrown. And the exception is thrown by that line only.
I can successfully save PDF into hard-drive using iText bif and only if the fileds are non-editable (meaning that all the fields are set as partialFormFlattening as true. However, if this flag is set as false (meaning, fields are editable), I get exception in the line above.
With other variation of code (all the fields are still editable), I had NullPointer exception being thrown when trying to call close() on PDFStamper. PDFStamper itself was not null.
I am wondering it using iText API, if it is possible to save PDF form, if all the PDF fields are editable.
Well, if I had to choose between the theories (1) the acroFields variable is null, or (2) there is a mysterious design fault which causes NullPointerException to be thrown for no reason, then I would go with (1) every time.
The other theory I might follow up is that the exception is actually being thrown by a different line of code. I wouldn't bother with any theories which said that somebody else's code was at fault until I had excluded all possibility of my code being at fault.