With these patches,
[sorry for the break] With these patches, it is possible to derive classes from HSSFCell and the linked classes HSSFRow, HSSFSheet and HSSFWorkbook. This can be very useful if you want to use inherent references between these objects in your own code which uses additional attributes e.g. of cells. That way, one does not have to create one's own ArrayLists, e.g. of the cells of every row. Plus you get all HSSFCell methods for free without any code. The main change to make this possible was to create working public constuctors in HSSFSheet, HSSFRow and HSSFCell. Before, there were only creator methods in the respective superior class, e.g. createRow in HSSFSheet. These continue to exists, but they simply call the respective constructors. There are some details beyond this concerning how to get the newly created e.g. HSSFCells into the administration of their HSSFRow, but you can look that up in the code. If you extend only one of these classes, be aware that you _must_ use its constructor for newly created objects. For example, if you extend HSSFSheet, you call "new HSSFSheet (HSSFWorkbook, String)" and pass it an existing HSSFWorkbook and the name of the new sheet. If you want to use the createSheet method of HSSFWorkbook, you have to extend that class and override that method, containing code like "result=new HSSFSheet (HSSFWorkbook, String)". The code contains hints like "##Override..." to quickly find the concerned methods.
Created attachment 22651 [details] Patch to make HSSFCell inheritable
Created attachment 22652 [details] Patch to make HSSFRow inheritable
Created attachment 22653 [details] Patch to make HSSFSheet inheritable
Created attachment 22654 [details] Patch to make HSSFWorkbook inheritable
From a functionality perspective, you are probably tryng to do something very sensible. Can you please attach some sample code that shows your goal? However, the technical change specified in these patches is contrary POI's current direction. POI avoids allowing API classes to be extended because of the difficulties that this presents. The trouble arises because inheritance is such an intimate form of coupling. The most discernible difficulty relates to maintaining of backward (source/binary) compatibility. This link has some useful tables classifying potential changes: http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs Much more subtle are the unexpected behaviour/logic consequences of inheritance. See this page for some well explained examples: http://norvig.com/java-iaq.html Most code using unwanted inheritance can be rewritten using delegation and/or the 'strategy pattern'. Don't get me wrong - inheritance isn't all bad. POI uses *plenty* of inheritance, just internally. My personal opinion is that "you should never inherit from a class that you do not control the source code of".
*** Bug 51574 has been marked as a duplicate of this bug. ***