poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Burch <n...@torchbox.com>
Subject Re: changed API when introducing ss to hssf, add old as @deprecated?
Date Sun, 20 Jul 2008 10:36:58 GMT
On Fri, 18 Jul 2008, Rainer Schwarze wrote:
> java.lang.NoSuchMethodError: 
> org.apache.poi.hssf.usermodel.HSSFCell.setCellStyle(Lorg/apache/poi/hssf/usermodel/HSSFCellStyle;)V

> at 
> net.sf.jasperreports.engine.export.JRXlsExporter.setCell(JRXlsExporter.java:208)
> ... (+ some more lines)

Ah, that's tedious. I think we've always re-compiled, and that probably 
would then work fine

> Since JasperReports is built against POI-3.0.1 and no rebuild of 
> JasperReports should be necessary, binary compatibility is needed.

I'm not sure if we have a decision on if 3.0 to 3.5 should be binary 
compatible or not. Source compatible in almost all cases we've already 
decided we're aiming for, but perhaps not binary.

However, I don't see why we can't add in the overloaded method for common 
cases that people use. So, I've done it for this case, and I'm happy for 
it to happen for other common ones, I just won't go looking for them!

> Regarding such issues, I found this page quite handy in the past:
> http://wiki.eclipse.org/Evolving_Java-based_APIs_2

It's currently refusing to load for me, but that might just be because I'm 
on the train... Will try to read it in the week though

> If the code which uses HSSF doesn't know about XSSF and only deals with 
> HSSF, should it still work with the 3.5 branch without modification / 
> rebuild?

Without modification, yes, in almost all cases. Without rebuild, see 


To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

View raw message