Created attachment 26976 [details] Converts all occurrences of autoboxing / auto-unboxing into explicit conversions. As Autoboxing may cause some trouble during runtime, I propose to avoid it and use explicit conversions where needed. An example line of code for misunderstandings is this: [code] Integer index = 5; List<ExampleObjects> list = getExampleList(); list.remove(index); [/code] One might expect to have element at index 5 removed from the list. But the API will call the method with signature List#remove(Object), so nothing happens. If reading the code in terms of another issue, one can easily miss the difference and wonder why on earth the element at index 5 was not removed. Therefore, I added explicit conversion whereever I found autoboxing takes place in the XPWF classes. This includes a minor API change for two methods in XWPFDocument, where "Integer" was used as return type, while "int" is sufficient and fits better into the rest of the get-index-methods of XWPF. Of course, this is a matter of coding style. So this just a proposal.
I agree we should probably avoid returning Integer or Boolean from methods wherever possible. Possibly within the code too, but List<Integer> interchanging with int for example is one case where we probably don't want too much explicit code cluttering up. I'll try to review the patch shortly.
Whether to use or not to use Autoboxing, that is one of those issues that turn out to become religious conflicts. After I stumbled over the List API, I decided to avoid them. But yes, it tends to inflate the code. Just keep in mind, how easily the following lines can be misunderstood: [code] List<Integer> list = new ArrayList<Integer>(); list.add(0); list.add(1); list.add(2); list.add(3); list.add(2,4); list.add(7); list.remove(0); list.remove(3); list.remove(new Integer(3)); list.remove(7); [/code] Just my 2 cents. ;)
Applied (with a few tweaks) in r1102691, thanks!