Details
Minor Description
FileUploadField at one point in its history (as far as I can tell) only supported uploading a single file (as did HTML). Thus FileUploadField.getFileUpload() returned a FileUpload or null if there was no file uploaded. This is correct and works as expected.
After browsers added support for multiple file uploads, Wicket appropriately added the FileUploadField.getFileUploads() method, which returns a List<FileUpload>. This method's API documentation doesn't indicate whether it returns null, a deficiency which itself should be corrected. In fact the documentation seems to imply that null will never be returned. The expectation from common practice is that a method returning a collection will never return null, unless null indicates something semantically distinct from an empty collection.
Unfortunately this method returns null when there are no files selected for upload. This goes against developer expectation, and moreover serves no semantic value, as an empty list would be just as appropriate (more appropriate, actually) to indicate that no files were selected. It makes the developer add extra, unnecessary code:
if(fileUpload.getFileUploads()==null || fileUpload.getFileUploads().isEmpty()) { return; //no files to process }
I recommend changing FileUploadField.getFileUploads() so that it never returns null (but may return an empty list), and indicate such in the API documentation. The currently implementation runs the risk of an unexpected NullPointerException for the developer who followed common practice expectations and was given no warning from the documentation.