This is a aggregate bug for recent changes in classes from using short or int to using enums with codes. Benefits: * self-explanatory usage rather than needing to list the valid constants in the javadocs * easier to distinguish arguments in function signatures (not just a 5 ints) * clearer error messages, no functions needed to convert code to string * free range checking (less boiler plate code that does the same) * type safety Drawbacks: * some permgen overhead * type checking execution overhead Overall, this seems like a good thing. In effort to maintain backwards compatibility, the following is suggested: If there is currently int getSomething(); void setSomething(int); Then we should add enum getSomethingEnum(); void setSomething(Enum); And deprecate void setSomething(int); int getSomething(); It's a bit tricky handling getSomething/getSomethingEnum while maintaining backwards compatibility because at some point the signature will abruptly change. Both getters should be offered for a while with a note encouraging users to use the constants or enums rather than using literal values. This is good coding practice anyway to not hard-code literal values, but is especially important with regard to backwards compatibility here. At least 2 releases later, but not later than POI 4.0: Delete void setSomething(int); Delete int getSomething(); Rename enum getSomethingEnum(); to enum getSomething(); In the end, we will have enum getSomething(); void setSomething(enum); as the only two methods.
Todo: update https://poi.apache.org/spreadsheet/quick-guide.html
https://poi.apache.org/apidocs/org/apache/poi/xwpf/usermodel/XWPFPictureData.html#getPictureType() XWPFPictureData.getPictureType() could return https://poi.apache.org/apidocs/org/apache/poi/sl/usermodel/PictureData.PictureType.html
preparation for removing those many HSSFColor subclasses with an enum via r1779866