Since the class java.lang.Package is available without import, failing to explicitly import org.apache.poi.openxml4j.opc.Package may cause confusing compiler errors. As a general rule, POI classes should not have names that clash with any jdk-public (or other well known) class. This is a change which would be good to get done before the 3.5-final release.
Created attachment 23386 [details] svn diff Please consider this patch and give feedback. In this patch I have created a new base class called "OPCPackage". The existing Package class has been deprecated and now extends OPCPackage. The rest of POI code has been changed to use the new non-deprecated class. The new name 'OPCPackage' is negotiable. Other names I considered were 'OpenPackage', 'OpenPackageContainer', 'XMLPackage' and 'PackageBase'. If maintaining binary compatibility with previous poi-ooxml versions is important, we will need to re-add deprecated versions of many methods which take OPCPackage as a parameter. Most of the usage of Package was internal, however there are some notable public methods/constructors, like XSSFWorkbook(Package). An unrelated change was to restrict the class hierarchy of Package to only POI subclasses (i.e. ZipPackage). This was done because POI discourages client classes from inheriting from POI classes.
+1 to this change. I agree that name clash with java.lang.* classes is undesirable. However, it's normal to have collisions with other packages, namely, with java.awt.*. There are Shape and Polygon objects both in HSLF and AWT and I think that they can co-exist happily. Even Java itself comes name clashes: java.awt.Shape vs javax.swing.Shape, java.util.List vs java.awt.List, etc. As to binary compatibility, I think it's OK to require users to re-compile their applications while we are still in a beta phase. I'm very reluctant to pollute the code with overridden methods for the sake of binary compatibility: foo(Package pkg) and foo(OPCPackage pkg). Regards, Yegor
I'm happy with going for the change, with no binary compatibility extra methods as we're in beta I'd probably lean more towards OOXMLPackage, rather than OPCPackage, but that's only a slight preference
Applied in svn r755699
(In reply to comment #4) Applied in svn r755699 . (sorry somehow lost the last digit)