[jira] [Commented] (FILEUPLOAD-249) DiskFileItem lazy instantiation of dfos field is not useful

["Sebb (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FILEUPLOAD-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903583#comment-13903583 ] 

Sebb commented on FILEUPLOAD-249:
---------------------------------

Testing shows that dfos cannot be made final, as the class is Serializable, and dfos is not.

Since a deserialised instance of the class will always ensure that dfos is initialised  - readObject() calls getOutputStream() - maybe one solution would be to call getOutputStream() (or equivalent) in the constructor. That way, dfos would be initialised regardless of how the class is instantiated.

This would also help fix FILEUPLOAD-247.

> DiskFileItem lazy instantiation of dfos field is not useful
> -----------------------------------------------------------
>
>                 Key: FILEUPLOAD-249
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-249
>             Project: Commons FileUpload
>          Issue Type: Bug
>            Reporter: Sebb
>
> AFAICT, the lazy instantiation of the dfos field is not very useful, as many methods fail with NPE unless it has been defined.
> There is very little that can be done with the instance until the dfos field has been created - even toString() fails.
> In which case, why not create the field at construction time?
> It can then be made final.
> As a consequence, tempFile would also need to be created by the ctor.
> It looks as though dfosFile could then also be made final.
> [These fields are all private so the API would not change.]



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)