You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Rainer Schwarze <rs...@admadic.de> on 2008/07/18 17:06:26 UTC
changed API when introducing ss to hssf, add old as @deprecated?
Hi,
I'm trying to work with JasperReports 3.0.0 which is built against
POI-3.0.1-FINAL. When I use a newer POI library, it complains, because
interfaces changed such as HSSFCell.setCellStyle(HSSFCellStyle) being
now HSSFCell.setCellStyle(CellStyle).
Would it be interesting/possible to include the "old style" API again as
deprecated? (And throw it away with - say - 4.0?) Are there critical
issues, which prevent the old API being there?
(in addition to setCellStyle(CellStyle) have the method
setCellStyle(HSSFCellStyle) too)
Thanks and best wishes, Rainer
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as
@deprecated?
Posted by Nick Burch <ni...@torchbox.com>.
On Sun, 24 Aug 2008, Wonne Keysers wrote:
> While trying to use Jasper Reports (2.0.4) I get the stack trace below.
> Would it be possible to re-introduce the method
> org.apache.poi.hssf.usermodel.HSSFSheet.addMergedRegion(Lorg/apache/poi/hssf/util/Region)
addMergedRegion(Region) is deprecated in trunk and ooxml, so I'm not sure
about the value of adding back the overloaded method. The method that
takes CellRangeAddress is the prefered way to do it now.
If you re-compile your app against the new poi jar though, it ought to
pick up the superclass method signatures, and work fine. That might be a
better bet for you
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as
@deprecated?
Posted by Wonne Keysers <Wo...@realsoftwaregroup.com>.
Hi,
While trying to use Jasper Reports (2.0.4) I get the stack trace below.
Would it be possible to re-introduce the method
org.apache.poi.hssf.usermodel.HSSFSheet.addMergedRegion(Lorg/apache/poi/hssf/util/Region)
in order to get things working again?
Or are there other (better) solutions?
Thanks
Wonne
java.lang.NoSuchMethodError:
org.apache.poi.hssf.usermodel.HSSFSheet.addMergedRegion(Lorg/apache/poi/hssf/util/Region;)I
at
net.sf.jasperreports.engine.export.JRXlsExporter.createMergeRegion(JRXlsExporter.java:515)
at
net.sf.jasperreports.engine.export.JRXlsExporter.initCreateCell(JRXlsExporter.java:488)
at
net.sf.jasperreports.engine.export.JRXlsExporter$1.handle(JRXlsExporter.java:384)
at
net.sf.jasperreports.engine.export.data.StringTextValue.handle(StringTextValue.java:47)
at
net.sf.jasperreports.engine.export.JRXlsExporter.createTextCell(JRXlsExporter.java:380)
at
net.sf.jasperreports.engine.export.JRXlsExporter.exportText(JRXlsExporter.java:370)
at
net.sf.jasperreports.engine.export.JRXlsAbstractExporter.exportPage(JRXlsAbstractExporter.java:540)
at
net.sf.jasperreports.engine.export.JRXlsAbstractExporter.exportReportToStream(JRXlsAbstractExporter.java:416)
at
net.sf.jasperreports.engine.export.JRXlsAbstractExporter.exportReport(JRXlsAbstractExporter.java:195)
at
org.springframework.ui.jasperreports.JasperReportsUtils.render(JasperReportsUtils.java:113)
Nick Burch wrote:
>
> On Sun, 20 Jul 2008, Rainer Schwarze wrote:
>>> 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!
>>
>> Thanks. Here is another case with JasperReports 3.0.0:
>>
>> HSSFCellStyle.setFont([HSSF]Font)
>
> OK, that's back in now. Shout if there are any more simple, common ones
> like that!
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/changed-API-when-introducing-ss-to-hssf%2C-add-old-as-%40deprecated--tp18531440p19138734.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as
@deprecated?
Posted by Nick Burch <ni...@torchbox.com>.
On Sun, 20 Jul 2008, Rainer Schwarze wrote:
>> 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!
>
> Thanks. Here is another case with JasperReports 3.0.0:
>
> HSSFCellStyle.setFont([HSSF]Font)
OK, that's back in now. Shout if there are any more simple, common ones
like that!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as @deprecated?
Posted by Rainer Schwarze <rs...@admadic.de>.
Nick Burch wrote:
> On Fri, 18 Jul 2008, Rainer Schwarze wrote:
[...]
>> 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.
I would expect that complete binary compatibility is not possible.
However, if adding "a few old methods" (and removing them in the next
major release) solves a certain amount of issues, its probably worth it.
> 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!
Thanks. Here is another case with JasperReports 3.0.0:
HSSFCellStyle.setFont([HSSF]Font)
In "my" project I added some more old interface methods to be sure, but
simple tests seem to show that adding "old" setCellStyle and setFont
should be enough.
(While testing different versions, I had troubles with POI 3.1, but this
deserves a specific bug report if I found out what is the cause.)
>> 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 above!
Ok. Thanks for the information :-)
Best wishes, Rainer
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as
@deprecated?
Posted by Nick Burch <ni...@torchbox.com>.
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
above!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as @deprecated?
Posted by Rainer Schwarze <rs...@admadic.de>.
Nick Burch wrote:
> On Fri, 18 Jul 2008, Rainer Schwarze wrote:
>> I'm trying to work with JasperReports 3.0.0 which is built against
>> POI-3.0.1-FINAL. When I use a newer POI library, it complains, because
>> interfaces changed such as HSSFCell.setCellStyle(HSSFCellStyle) being
>> now HSSFCell.setCellStyle(CellStyle).
>
> I'm guessing this is on the 3.5 / ooxml branch?
I'm using an adjusted POI library, but the issue exists also with
poi-3.5-beta1-20080718.jar .
> HSSFCellStyle extends
> CellStyle, so you shouldn't see any difference - we've made the method
> call more accepting, not less.
I get this when I use the 3.5 beta with JasperReports:
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)
Since JasperReports is built against POI-3.0.1 and no rebuild of
JasperReports should be necessary, binary compatibility is needed.
Regarding such issues, I found this page quite handy in the past:
http://wiki.eclipse.org/Evolving_Java-based_APIs_2
There is a section "Evolving API classes - API methods and constructors"
which has a row containing:
"Change type of a formal parameter - Breaks compatibility"
I think this happens when the type of the cell style changes from
HSSFCellStyle to CellStyle.
So to keep the binary compatibility the setCellStyle(HSSFCellStyle)
should still be there, shouldn't it? Is binary compatibility
> It's possible to compile almost all of the unit tests from poi 3.1
> against the jar of poi 3.5, certainly all the cell style ones, so I'm
> not sure why you're hitting a problem. (It's only MissingCellPolicy
> and HSSFFormulaEvaluator.CellValue that need to change, see
> docs/spreadsheet/converting.html)
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?
Best wishes, Rainer
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: changed API when introducing ss to hssf, add old as
@deprecated?
Posted by Nick Burch <ni...@torchbox.com>.
On Fri, 18 Jul 2008, Rainer Schwarze wrote:
> I'm trying to work with JasperReports 3.0.0 which is built against
> POI-3.0.1-FINAL. When I use a newer POI library, it complains, because
> interfaces changed such as HSSFCell.setCellStyle(HSSFCellStyle) being
> now HSSFCell.setCellStyle(CellStyle).
I'm guessing this is on the 3.5 / ooxml branch? HSSFCellStyle extends
CellStyle, so you shouldn't see any difference - we've made the method
call more accepting, not less.
It's possible to compile almost all of the unit tests from poi 3.1 against
the jar of poi 3.5, certainly all the cell style ones, so I'm not sure
why you're hitting a problem. (It's only MissingCellPolicy and
HSSFFormulaEvaluator.CellValue that need to change, see
docs/spreadsheet/converting.html)
Are you sure you only have the one version of poi on your classpath? It's
only the 3.5 version of HSSFCellStyle that extends CellStyle, so if you
have an old version too that might confuse things
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org