Bug 17126 - [RFE]Encapsulate Font and CellStyle records managed as Flyweight into org.apache.poi.hssf.usermodel package
Summary: [RFE]Encapsulate Font and CellStyle records managed as Flyweight into org.apa...
Alias: None
Product: POI
Classification: Unclassified
Component: HSSF (show other bugs)
Version: 2.0-dev
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2003-02-17 12:30 UTC by Toshiaki Kamoshida
Modified: 2004-11-16 19:05 UTC (History)
0 users

Input Excel File for the Testcase. Name "Input.xls" (13.50 KB, application/octet-stream)
2003-03-05 06:44 UTC, Toshiaki Kamoshida
Testcase for see this problem. (1.01 KB, text/plain)
2003-03-05 06:45 UTC, Toshiaki Kamoshida

Note You need to log in before you can comment on or make changes to this bug.
Description Toshiaki Kamoshida 2003-02-17 12:30:37 UTC

I request a minor enhancement.
(I can't use english well,please read with patience...Can you understand my 

Font and CellStyle records are managed in Workbook object,and used Flyweight 
If two cell's attribute(cell style and font) are all same,we must set same 
object at both cell to avoid generating invalid Workbook,because attribute 
object's number is over a limit.
But it is not convenience for users.(and for some commiters?  because many 
report about it is submitted to ML repeatedly... )
Please implement cell's attributes like this(or on some better idea.I don't 
know the implementation deeply:) ),

1.HSSFCell#setCellStyle(HSSFCellStyle) causes like String#intern(String).If 
there are already registered a object that has same attributes,instead of 
registering parameter object,the cell use the object already regeistered as the 
cell's attribute.

2.HSSFCell#getCellStyle() returns, not raw attribute object's reference,but a 
shallow copy of it,to make users disable to change the cell's style attribute 

3.and other some implementation for it.

Thank you for reading.
Comment 1 Glen Stampoultzis 2003-02-17 12:52:19 UTC
Hi.  Your English is just fine.  I have though about this and I think it's a
good idea and it should be possible to implement something like this.  I don't
personally have time to pick this one up at the moment but hopefully another
developer might be able to look into it.
Comment 2 Andy Oliver 2003-02-17 13:59:08 UTC
No it shouldn't be done.  The reason being is you can manage groups of cells's
style.  Excel behaves in this way.  We should however throw an exception if
someone creates too many of them.
Comment 3 gr_nico 2003-02-19 10:59:34 UTC
I made a system to manage this:

An ExcelDocument that behaves like HSSFWorkbook but
   - uses Hashmaps to store created HSSFFont and HSSFCellStyle
   - don't return any HSSFCellStyle

An ExcelFormat that contains the same data as HSSFFont and HSSFCellStyle

An ExcelFormatKey that contains a HSSFCellStyle

When a developper want to create a style for a cell, he uses ExcelFormat.
When he want's to apply it on a cell he has to use the ExcelFormatKey 
corresponding to it.
He gets ExcelFormatKeys through ExcelDocument that checks if HSSFFont and 
HSSFCellStyle exists, if not a single HSSCellStyle or both HSSFFont and 
HSSFCellStyle are created.

The developper doesn't the see the "POI" objects.
It is slower, but it is easer not to store all the existing HSSFFont and 

Perhaps this way of solution could help you

Question : Is there any forum where we can discuss about poi? 
Comment 4 Rainer Klute 2003-02-19 11:59:01 UTC
There's a mailing list. Just send an e-mail to poi-dev-help@jakarta.apache.org
and see what happens.
Comment 5 gr_nico 2003-02-19 13:35:04 UTC
I tried to send a mail to this adress but I received :

"Hi! This is the ezmlm program. I'm managing the
poi-dev@jakarta.apache.org mailing list.

I'm working for my owner, who can be reached
at poi-dev-owner@jakarta.apache.org.

This is a generic help message. The message I received wasn't sent to
any of my command addresses."
Comment 6 Rainer Klute 2003-02-19 14:08:49 UTC
Yes! Just keep on reading that e-mail and you'll see what you are looking for.
Comment 7 gr_nico 2003-02-19 14:50:51 UTC
Ok, my fault : I thought of help on POI and not help on using poi's list :-(
Comment 8 Toshiaki Kamoshida 2003-02-20 08:10:54 UTC

Now I'm making a Wrapper Library of POI in my business.
In my library I made a management system of font and cell's style attribute.

In my library there are workbook,sheet,font,cell's style and etc classes,
and user can freely create instance of font and cell's style,and set it to
each cell object.Thease classes are not related to POI's classes.

And when user call serialize method of it,my library create a HSSFWorkbook,
and other POI's objects as the model of my library.And in this turn,my library 
do like this,

1.Collect each cell's style and font.
2.Check duplication of thease objects and dispose duplicated one.
3.Create HSSFFont and HSSFCellStyle object based on this adjusted collection.
4.Set it to each HSSFCell.

I feel,if usermodel package behave like this(User neet not to understand low 
layer architecture of POI and neet not to manage thease attributes on user's 
responsibility),we can use POI more easily.

Of course,the policy of POI usermodel is already exist and it can't permit this
plan,I feel it is a reasonable decision and I will respect it.

To tell the fact, I feel troublesome to implement the system in my library, and 
if POI support this part, it make me more easily :)

Comment 9 gr_nico 2003-02-20 08:25:41 UTC
Good idea. I had the same problems as yours!

But I have a few questions for you :
   Are you able to represent easily with your own model: merged regions, ... ?
   How long does it take to serialize a file containing 10,000.00 rows and 7 
columns on each row ?
Comment 10 Andy Oliver 2003-02-20 12:58:36 UTC
can you like, join the mail list?   Secondly, I'm pretty sure this already
exists in the contrib module.  Talk on the mail list, not bugzilla.
Comment 11 Toshiaki Kamoshida 2003-03-05 06:44:34 UTC
Created attachment 5155 [details]
Input Excel File for the Testcase. Name "Input.xls"
Comment 12 Toshiaki Kamoshida 2003-03-05 06:45:54 UTC
Created attachment 5156 [details]
Testcase for see this problem.
Comment 13 Toshiaki Kamoshida 2003-03-05 06:53:44 UTC
Sorry, I made a confuse about this problem.
I submitted a simple testcase to see this problem.
In "Input.xls",Cell A1 and A2 in the sheet "Test" has same attribute about 
cell's style.And In the testcase source is simply do

1.Load "Input.xls"
2.Get HSSFCellStyle about Cell A1.
3.Call HSSFCellStyle#setBorderBottom() ande change style attribute A1's cell.
4.Save as"Output.xls"

And checking "Output.xls",Both A1 and A2 Cell's style is changed.
It is correct behavior under the structure like now,but user may feel it is bug 
or not convinience.
What do you think about it?

Thank you.
Comment 14 Toshiaki Kamoshida 2003-03-05 06:58:46 UTC
Sorry, not "A1 and A2",but "A1 and B1".
Comment 15 Andy Oliver 2003-03-29 00:33:16 UTC
-1 On removing the abillity to have duplicate cell styles.  -1 on putting
anything in the core API which allows people to thoughtlessly iterate throw A
LIST of cell styles so that they complain later on how slow HSSF is when they
misuse this for thousands of operations.  +1 on an acceptable utility class
however I'm pretty sure that there is one in the contrib module.  If it isn't
Pattern-correct, thats certainly not my itch, but patches are welcome.

Making HSSF fit into your conceptualization of what the file format is, thats
your job (the application developer).  We're mapping what it ACTUALLY is, which
is that two equal in appearence but actually different styles can and often do
get written to the file.  Changing one of the visually equal styles changes a
group of cell styles.  This is used by one of my clients and I'd be HARD pressed
to disable this feature just for convienence.  Come up with a solution that
preserves the behavior and submit a patch.  If its unspoken ineffieciency or is
complex (such as iterating through a list over and over) then please patch
against the contrib module.

Note that on the whole I try to keep the API easy to use but I don't like
cluttering it with convienience functions at this stage.  Once all hard problems
(formulas, graphing, embedded graphics, memory, io-mapping) are solved then
we'll talk.  However I don't want to clutter the core API with a lot of bells
and whistles that WE have to maintain until then.  (Thats what contrib is for)

I'm closing this bug and putting it as invalid.  MOVE THIS ONTO THE DISCUSSION
LISTS.  If you're having trouble posting to the disucssion list (aimed at
gr_nico), perhaps you should consider reading directions (hint: subscribe).

Toshiaki, I think you'll get along great in the POI community and I look forward
to continuing this discussion on the developer list.