Re: Code Quality Metrics
Max Berger: > since this came up, here is a list of tools I use for software quality > checking (and all them them can check for generic list types). All of > them have Eclipse and maven plugins (and ant tasks, and ) Incidentally, I would be happy too if we had some written-down guidelines (or automatic checking) for code quality in Batik. Also, I’m looking forward to the results of the retroweaver experiments, as I would like to be able to use Java 5 syntactic features in Batik. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)
>- Oorspronkelijk bericht - >Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 08:40 PM > >You’re both right of course. I didn’t have that possibility in mind when >writing my post to fop-dev. No warning needed indeed :-) [Me: ] >>> * if it is not a table-cell or table-column, return a zero value to >>> avoid the property subsystem calling make(PropertyList) to construct a >>> default/initial value > >That’s not so simple IMO. column-number must be assigned its specified >value even when the object isn’t a table-cell nor a table-column. Right! I was contradicting myself here. First say that the property may be specified and significant (even if non-applicable), and then silently revert to a zero value... This is of course out of the question. :-) Thanks for the feedback! Cheers Andreas
Re: Print JPEG HeadlessException - Please Help
>- Oorspronkelijk bericht -
>Van: Surj [mailto:[EMAIL PROTECTED]
>Verzonden: vrijdag, juni 13, 2008 09:23 PM
>
>Yes the 'java.awt.headless=true' specified as a parameter when starting up
>the weblogic container, is there any other way of setting this i.e.
>programmatically during startup.
Can you also verify from within your code whether the setting was correctly
processed?
This you could check via:
System.out.print("java.awt.headless=" + System.getProperty("java.awt.headless",
"false"));
In theory, you could use System.setProperty("java.awt.headless", "true") to set
the value, but as is often the case with properties on the system-level, it
could be that setting it programmatically has no effect at all.
HTH!
Cheers
Andreas
Re: Code Quality Metrics
>- Oorspronkelijk bericht - >Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 08:31 PM >FWIW, I do re-assign local variables sometimes (rarely). When the new >value serves the same purpose, and creating a new variable with another >name would actually look more confusing. Do I have to slash my hand for >that? I wouldn't go /that/ far. With only one hand you wouldn't be able to code anymore... and that would be quite a loss for the FOP-community. ;-) No really, the fact that you do it /rarely/ says enough. As I hinted, IMO it should actually be the other way around, i.e. reserve a keyword to mark a parameter as an 'out' parameter that is supposed to be modified/assigned by the method. It's only reassignment that is prevented, and declaring the parameter final still does not prevent you from modifying the parameter itself. As long as it remains the same instance, you will get no compiler warning. It can still come out of the method as a 'different' object. Luckily, or we would not be able to append to StringBuffer-parameters or add to List-parameters. Cheers Andreas
Re: Print JPEG HeadlessException - Please Help
Yes the 'java.awt.headless=true' specified as a parameter when starting up the weblogic container, is there any other way of setting this i.e. programmatically during startup. Thanks Andreas Delmelle-2 wrote: > >>- Oorspronkelijk bericht - >>Van: Surj [mailto:[EMAIL PROTECTED] >>Verzonden: vrijdag, juni 13, 2008 05:07 PM >> >>Oh by the way i am using Java 1.4.2.8 if that makes a diff or not. >> >>Surj wrote: >>> >>> Ok i am using fop-0.20.5 and all I am trying to do is get a jpeg images >>> and send it to a postscript printer, i think this did work at some point >>> but it is difficult to tell with so many releases. So the code looks >>> something like this: > >>> In the logs i get the following error when printing the image and I have >>> set the java option >>> -Djava.awt.headless=true. >>> >>> [ERROR] Logger not set >>> [INFO] Using weblogic.xml.jaxp.RegistryXMLReader as SAX2 Parser >>> [INFO] building formatting object tree >>> [INFO] setting up fonts >>> [INFO] [1] >>> [INFO] [2] >>> [ERROR] svg graphic could not be rendered: null >>> java.awt.HeadlessException > > I'm not 100% sure, but it seems like the system-property setting somehow > is not correctly processed... Is 'java.awt.headless=true' specified as a > parameter when starting up the servlet container, or how precisely do you > set it? > > Another possibility is that it's something internal in the Java AWT > implementation, but I don't have Sun's sources at hand here, so can't see > which line in that class is causing the HeadlessException. > > > Cheers > > Andreas > > > > -- View this message in context: http://www.nabble.com/Print-JPEG-HeadlessException---Please-Help-tp17821038p17830363.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)
Chris, Andreas, You’re both right of course. I didn’t have that possibility in mind when writing my post to fop-dev. No warning needed indeed :-) > Andreas Delmelle wrote: >> The only modification would be: >> * surrounding the method body of >> ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a >> check for the type of FO for which the property is being constructed. >> If that isn't a table-cell or a table-column, then we /silently/ >> ignore it (after all, it's always possible that the value is referred >> to further down the stream) >> * if it is not a table-cell or table-column, return a zero value to >> avoid the property subsystem calling make(PropertyList) to construct a >> default/initial value That’s not so simple IMO. column-number must be assigned its specified value even when the object isn’t a table-cell nor a table-column. Simply, no check for column availability must be performed. Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Code Quality Metrics
Hi,
Thanks for your explanation.
Max Berger wrote:
>>> [1]
>>> http://pmd.sourceforge.net/rules/optimizations.html#MethodArgumentCouldBeFinal
>
>> +1
>> I must say, I’ve never really grasped the benefit of doing this. I’d be
>> happy to be enlightened, though.
>
> Sure:
>
> Declaring a parameter / variable as final makes it immutable in the
> method where it is used. This is:
>
> - required if the variable is used in an anonymous inner class (as a way
> of passing "parameters" into one)
Agreed on this one. I’ve used that once already. (More precisely,
Eclipse told me that it would refuse to compile my file as long as
I wouldn’t declare my parameters final, and I wasn’t in the mood for
fight back then.)
> - good coding practice on all methods: If a parameter is re-assigned,
> the value may not be what the programmer actually intended it to be.
Hmmm. But this safeguard becomes helpful only when the method starts to
get really long, so long that you can lose track of the places where you
re-assign the local variables. So long that it should actually be split
into several sub-methods, whose small sizes make this precaution
superfluous again. That’s why I’m not convinced by the utility of this
rule.
FWIW, I do re-assign local variables sometimes (rarely). When the new
value serves the same purpose, and creating a new variable with another
name would actually look more confusing. Do I have to slash my hand for
that?
> Example:
>
> void someMethod(List l)
> {
> if (l==null) l = new LinkedList();
> l.add("test");
> }
>
> or even worse, this attempt to fix it:
>
> List someMethod(List l)
> {
> if (l==null) l = new LinkedList();
> l.add("test");
> return l;
> }
>
> Here we have a very subtle code bug, which is triggered only in a few cases:
>
> List l1;
> List l2;
> ...
> l1 = someMethod(l1); // does not trigger
> l1 = someMethod(l2); // does trigger
Ahem, err, what’s the bug? :-\ In both cases l1 receives a new list
containing the string “test”. In both, l1 ends up being != the parameter
of someMethod.
> This rule is listed under "optimizations", because final can also be
> used as a hint for hotspot, and many people use it mostly for
> optimization (although the performance advantage is debatable).
Moreover, the time where our last resort to further improve performance
is to declare final all the arguments of all the methods of the codebase
is no near to be reached IMO ;-)
Vincent
--
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting
Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)
Andreas Delmelle wrote: In the meantime, I made this change locally, but stumbled on the fact that we do not have an event defined for non-applicable properties. Now I'm wondering whether we should warn about those at all. According to the XSL-FO Recommendation, any property may be specified on any FO. If the property is inherited, warning about its being non-applicable is more a nuisance than a feature. I, for one, would rather not get a warning each and every time I define the standard font-size on the fo:root, for example. That would leave the non-inheritable properties, but there we also have the possibility of specifying the property on an ancestor (to which it does not apply), and then retrieve the value on one of the descendants using from-nearest-specified(). Since we can't check for the use of that function at the time the property is constructed, I'd be inclined to leave the code virtually unaltered. The only modification would be: * surrounding the method body of ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a check for the type of FO for which the property is being constructed. If that isn't a table-cell or a table-column, then we /silently/ ignore it (after all, it's always possible that the value is referred to further down the stream) * if it is not a table-cell or table-column, return a zero value to avoid the property subsystem calling make(PropertyList) to construct a default/initial value If a user does supply a non-applicable property, this is not an error. He may scratch his head for while, trying to figure out why it doesn't work, but I don't think we can expect FOP to cater for /every/ possible mistake... In this case, all it takes is one look at the property definition (*) to find out that the behavior is only defined for fo:table-cell and fo:table-column. +1. I totally agree with your assessment. We don't want lots of warnings generated by font-family on fo:root or similar. The same is true for non inheritable properties as they may be used by functions like you said. We need to silently ignore column-number on non-applicable FOs to avoid NPE or similar errors during layout. The only other alternative is to make layout more robust, but that is a more difficult solution. Also it doesn't feel the right place to solve this proble, it should be dealt with in the properties package. Thanks, Chris
Re: Print JPEG HeadlessException - Please Help
>- Oorspronkelijk bericht - >Van: Surj [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 05:07 PM > >Oh by the way i am using Java 1.4.2.8 if that makes a diff or not. > >Surj wrote: >> >> Ok i am using fop-0.20.5 and all I am trying to do is get a jpeg images >> and send it to a postscript printer, i think this did work at some point >> but it is difficult to tell with so many releases. So the code looks >> something like this: >> In the logs i get the following error when printing the image and I have >> set the java option >> -Djava.awt.headless=true. >> >> [ERROR] Logger not set >> [INFO] Using weblogic.xml.jaxp.RegistryXMLReader as SAX2 Parser >> [INFO] building formatting object tree >> [INFO] setting up fonts >> [INFO] [1] >> [INFO] [2] >> [ERROR] svg graphic could not be rendered: null >> java.awt.HeadlessException I'm not 100% sure, but it seems like the system-property setting somehow is not correctly processed... Is 'java.awt.headless=true' specified as a parameter when starting up the servlet container, or how precisely do you set it? Another possibility is that it's something internal in the Java AWT implementation, but I don't have Sun's sources at hand here, so can't see which line in that class is causing the HeadlessException. Cheers Andreas
Re: Print JPEG HeadlessException - Please Help
Oh by the way i am using Java 1.4.2.8 if that makes a diff or not.
Surj wrote:
>
> Ok i am using fop-0.20.5 and all I am trying to do is get a jpeg images
> and send it to a postscript printer, i think this did work at some point
> but it is difficult to tell with so many releases. So the code looks
> something like this:
>
> PrinterID printerID = getPrinterID();
>
> Process process = Runtime.getRuntime().exec("lp -d " +
> printerID.getName());
> out1 = process.getOutputStream();
>
> driver = new Driver(inputSource, out1);
> driver.setRenderer(Driver.RENDER_PS);
>
> driver.run();
> driver.reset();
> out1.flush();
> out1.close();
> process.waitFor();
>
>
> In the logs i get the following error when printing the image and I have
> set the java option
> -Djava.awt.headless=true.
>
> [ERROR] Logger not set
> [INFO] Using weblogic.xml.jaxp.RegistryXMLReader as SAX2 Parser
> [INFO] building formatting object tree
> [INFO] setting up fonts
> [INFO] [1]
> [INFO] [2]
> [ERROR] svg graphic could not be rendered: null
> java.awt.HeadlessException
> at
> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:66)
> at
> org.apache.fop.render.ps.PSGraphics2D.getDeviceConfiguration(PSGraphics2D.java:872)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.getDestination(GraphicsUtil.java:543)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorModel(GraphicsUtil.java:557)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorSpace(GraphicsUtil.java:579)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:153)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:497)
> at
> org.apache.batik.gvt.RasterImageNode.primitivePaint(RasterImageNode.java:94)
> at
> org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
> at
> org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
> at
> org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
> at org.apache.batik.gvt.ImageNode.paint(ImageNode.java:37)
> at
> org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
> at
> org.apache.batik.gvt.CanvasGraphicsNode.primitivePaint(CanvasGraphicsNode.java:68)
> at
> org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
> at
> org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
> at
> org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
> at
> org.apache.fop.render.ps.PSRenderer.renderSVGDocument(PSRenderer.java:430)
> at
> org.apache.fop.render.ps.PSRenderer.renderSVGArea(PSRenderer.java:365)
> at org.apache.fop.svg.SVGArea.render(SVGArea.java:58)
> at
> org.apache.fop.render.ps.PSRenderer.renderForeignObjectArea(PSRenderer.java:352)
> at
> org.apache.fop.layout.inline.ForeignObjectArea.render(ForeignObjectArea.java:46)
> at
> org.apache.fop.render.ps.PSRenderer.renderLineArea(PSRenderer.java:813)
> at org.apache.fop.layout.LineArea.render(LineArea.java:320)
> at
> org.apache.fop.render.AbstractRenderer.renderBlockArea(AbstractRenderer.java:442)
> at org.apache.fop.layout.BlockArea.render(BlockArea.java:78)
> at
> org.apache.fop.render.AbstractRenderer.renderAreaContainer(AbstractRenderer.java:408)
> at org.apache.fop.layout.ColumnArea.render(ColumnArea.java:29)
> at
> org.apache.fop.render.AbstractRenderer.renderSpanArea(AbstractRenderer.java:57)
> at org.apache.fop.layout.SpanArea.render(SpanArea.java:52)
> at
> org.apache.fop.render.AbstractRenderer.renderBodyAreaContainer(AbstractRenderer.java:325)
> at
> org.apache.fop.layout.BodyAreaContainer.render(BodyAreaContainer.java:98)
> at
> org.apache.fop.render.AbstractRenderer.renderRegions(AbstractRenderer.java:494)
> at
> org.apache.fop.render.ps.PSRenderer.renderPage(PSRenderer.java:839)
> at
> org.apache.fop.render.ps.PSRenderer.render(PSRenderer.java:1096)
> at
> org.apache.fop.apps.StreamRenderer.queuePage(StreamRenderer.java:258)
> at org.apache.fop.layout.AreaTree.addPage(AreaTree.java:68)
> at
> org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:359)
> at
> org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:290)
> at
> org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:218)
> at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
> at
> weblogic.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:585)
> at
> weblogic.apache.xerces.impl.XMLNamespaceBinder.handleEndElement(XMLNa
Re: Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)
>- Oorspronkelijk bericht - >Van: Andreas Delmelle [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 03:56 PM > In this case, all it takes is one look at the property definition (*) to find > out > that the behavior is only defined for fo:table-cell and fo:table-column. forgot the link (*) = http://www.w3.org/TR/xsl/#column-number
Re: Code Quality Metrics
>- Oorspronkelijk bericht - >Van: Max Berger [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 01:11 PM > >> +1 >> I must say, I’ve never really grasped the benefit of doing this. I’d be >> happy to be enlightened, though. > >Sure: > >Declaring a parameter / variable as final makes it immutable in the >method where it is used. This is: Come to think of it, I've always found it /very/ tricky to use the word 'immutable' in case of objects, especially collections. Declaring a method parameter or a member as final prevents only reassignment, but the assigned instance itself definitely remains mutable, unless additional precautions are taken to prevent structural modification after the assignment. Doing this for each and every method seems to be a bit over the top. Especially if the method body is relatively short. Anyway, I don't think there are any devs in the team at the moment who are in the habit of reassigning parameters (the fact that Vincent did not immediately see the benefit of that rule is a nice demonstration). I look at it this way: it's much worse practice to reassign parameters (especially in public methods) than it is not to declare the parameters final. In that sense, I think the behavior in a language like PL/SQL (with roots in Ada) is much better defined: disallow any parameters from being reassigned, unless the programmer explicitly declares the parameter as such (OUT or IN OUT). Maybe an idea for Java 8. ;-) Cheers Andreas
Non-applicable properties? (was: ClassCastException when using Table Cells in FOP 0.95B)
>- Oorspronkelijk bericht - >Van: Andreas Delmelle [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 01:18 PM > >>- Oorspronkelijk bericht - >>Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] >>Verzonden: vrijdag, juni 13, 2008 12:17 PM >> > >> >>FOP lacks of robustness here since it crashes instead of just giving >>a warning that column-number doesn’t apply to fo:block. Can you please >>create a bug report on Bugzilla, attaching a complete FO file containing >>your snippet above as an example? >>https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop >> >>This will help us to keep track of the issue. Thanks! > >This is a very easy fix. I'll see if I can take care of it ASAP. I just >checked the SVN > history of the related source file, and apparently, I had initially added > such a check > in the wrong place (ColumnNumberPropertyMaker.make(PropertyList), which is > normally only called to 'make' implicit values; removed in the meantime). > The check should still be made, however, in make(PropertyList, String, FObj), > so > that it is instead called when making the property off an explicitly > specified value. In the meantime, I made this change locally, but stumbled on the fact that we do not have an event defined for non-applicable properties. Now I'm wondering whether we should warn about those at all. According to the XSL-FO Recommendation, any property may be specified on any FO. If the property is inherited, warning about its being non-applicable is more a nuisance than a feature. I, for one, would rather not get a warning each and every time I define the standard font-size on the fo:root, for example. That would leave the non-inheritable properties, but there we also have the possibility of specifying the property on an ancestor (to which it does not apply), and then retrieve the value on one of the descendants using from-nearest-specified(). Since we can't check for the use of that function at the time the property is constructed, I'd be inclined to leave the code virtually unaltered. The only modification would be: * surrounding the method body of ColumnNumberPropertyMaker.make(PropertyList, String, FObj) with a check for the type of FO for which the property is being constructed. If that isn't a table-cell or a table-column, then we /silently/ ignore it (after all, it's always possible that the value is referred to further down the stream) * if it is not a table-cell or table-column, return a zero value to avoid the property subsystem calling make(PropertyList) to construct a default/initial value If a user does supply a non-applicable property, this is not an error. He may scratch his head for while, trying to figure out why it doesn't work, but I don't think we can expect FOP to cater for /every/ possible mistake... In this case, all it takes is one look at the property definition (*) to find out that the behavior is only defined for fo:table-cell and fo:table-column. WDYT? Cheers Andreas
Re: Code Quality Metrics
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent,
Vincent Hennebert schrieb:
>> 18000 PMD violations is just sick. Things like rule [1] doesn't really help
>> the source code. We can do that if we get a budget for
>> nuclear-power-plant-grade
>> software.
> Same here I guess. Now may be the right time to launch the debate,
> actually. I’ll try to gather some energy in the next days for that.
PMD contains many different check sets. The main reason for the large
number of violations is that I've enabled many of the check-sets, among
those "optimizations" and "design", which are responsible for the large
number of error messages. Maybe we should start with the "basic" set and
go from there?
>> [1]
>> http://pmd.sourceforge.net/rules/optimizations.html#MethodArgumentCouldBeFinal
> +1
> I must say, I’ve never really grasped the benefit of doing this. I’d be
> happy to be enlightened, though.
Sure:
Declaring a parameter / variable as final makes it immutable in the
method where it is used. This is:
- - required if the variable is used in an anonymous inner class (as a way
of passing "parameters" into one)
- - good coding practice on all methods: If a parameter is re-assigned,
the value may not be what the programmer actually intended it to be.
Example:
void someMethod(List l)
{
if (l==null) l = new LinkedList();
l.add("test");
}
or even worse, this attempt to fix it:
List someMethod(List l)
{
if (l==null) l = new LinkedList();
l.add("test");
return l;
}
Here we have a very subtle code bug, which is triggered only in a few cases:
List l1;
List l2;
...
l1 = someMethod(l1); // does not trigger
l1 = someMethod(l2); // does trigger
This rule is listed under "optimizations", because final can also be
used as a hint for hotspot, and many people use it mostly for
optimization (although the performance advantage is debatable).
Max
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIUlXI+Gr+4pk71JwRAsf+AJsEKJgPlO528ArRQ2/QO05Xn0MBvwCfeRAY
VP8QJHJoHsccbd3b40xS7pU=
=/b+s
-END PGP SIGNATURE-
Print JPEG HeadlessException - Please Help
Ok i am using fop-0.20.5 and all I am trying to do is get a jpeg images and
send it to a postscript printer, i think this did work at some point but it
is difficult to tell with so many releases. So the code looks something
like this:
PrinterID printerID = getPrinterID();
Process process = Runtime.getRuntime().exec("lp -d " +
printerID.getName());
out1 = process.getOutputStream();
driver = new Driver(inputSource, out1);
driver.setRenderer(Driver.RENDER_PS);
driver.run();
driver.reset();
out1.flush();
out1.close();
process.waitFor();
In the logs i get the following error when printing the image and I have set
the java option
-Djava.awt.headless=true.
[ERROR] Logger not set
[INFO] Using weblogic.xml.jaxp.RegistryXMLReader as SAX2 Parser
[INFO] building formatting object tree
[INFO] setting up fonts
[INFO] [1]
[INFO] [2]
[ERROR] svg graphic could not be rendered: null
java.awt.HeadlessException
at
sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:66)
at
org.apache.fop.render.ps.PSGraphics2D.getDeviceConfiguration(PSGraphics2D.java:872)
at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestination(GraphicsUtil.java:543)
at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorModel(GraphicsUtil.java:557)
at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorSpace(GraphicsUtil.java:579)
at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:153)
at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:497)
at
org.apache.batik.gvt.RasterImageNode.primitivePaint(RasterImageNode.java:94)
at
org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
at
org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
at
org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
at org.apache.batik.gvt.ImageNode.paint(ImageNode.java:37)
at
org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
at
org.apache.batik.gvt.CanvasGraphicsNode.primitivePaint(CanvasGraphicsNode.java:68)
at
org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
at
org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(CompositeGraphicsNode.java:130)
at
org.apache.batik.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:500)
at
org.apache.fop.render.ps.PSRenderer.renderSVGDocument(PSRenderer.java:430)
at
org.apache.fop.render.ps.PSRenderer.renderSVGArea(PSRenderer.java:365)
at org.apache.fop.svg.SVGArea.render(SVGArea.java:58)
at
org.apache.fop.render.ps.PSRenderer.renderForeignObjectArea(PSRenderer.java:352)
at
org.apache.fop.layout.inline.ForeignObjectArea.render(ForeignObjectArea.java:46)
at
org.apache.fop.render.ps.PSRenderer.renderLineArea(PSRenderer.java:813)
at org.apache.fop.layout.LineArea.render(LineArea.java:320)
at
org.apache.fop.render.AbstractRenderer.renderBlockArea(AbstractRenderer.java:442)
at org.apache.fop.layout.BlockArea.render(BlockArea.java:78)
at
org.apache.fop.render.AbstractRenderer.renderAreaContainer(AbstractRenderer.java:408)
at org.apache.fop.layout.ColumnArea.render(ColumnArea.java:29)
at
org.apache.fop.render.AbstractRenderer.renderSpanArea(AbstractRenderer.java:57)
at org.apache.fop.layout.SpanArea.render(SpanArea.java:52)
at
org.apache.fop.render.AbstractRenderer.renderBodyAreaContainer(AbstractRenderer.java:325)
at
org.apache.fop.layout.BodyAreaContainer.render(BodyAreaContainer.java:98)
at
org.apache.fop.render.AbstractRenderer.renderRegions(AbstractRenderer.java:494)
at
org.apache.fop.render.ps.PSRenderer.renderPage(PSRenderer.java:839)
at org.apache.fop.render.ps.PSRenderer.render(PSRenderer.java:1096)
at
org.apache.fop.apps.StreamRenderer.queuePage(StreamRenderer.java:258)
at org.apache.fop.layout.AreaTree.addPage(AreaTree.java:68)
at
org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:359)
at
org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:290)
at
org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:218)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
at
weblogic.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:585)
at
weblogic.apache.xerces.impl.XMLNamespaceBinder.handleEndElement(XMLNamespaceBinder.java:898)
at
weblogic.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:644)
at
weblogic.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1008)
at
weblogic.apache.xerces.impl.XMLDocumentFragmentScan
Re: Code Quality Metrics
Hi, Jeremias Maerki wrote: > I'm scared by the thought of having a program "clean" our source code > changing lots of files. I prefer the approach that the devs shall try to > improve the code while they are working on it. Agreed. Even if that doesn’t prevent us from scheduling a big “code cleanupathon” when we’re ready, i.e., at a moment where there’s no active branch, only the Trunk. Far, far away? Probably ;-) > BTW, I think there's one or two rules in our Checkstyle file that > probably should/could be removed. For example, the frequent warning > about "field hiding" and "Utility classes should not have a public > constructor". But that's a separate discussion I guess. I’ve been wanting to lauch this discussion for a while. It definitely makes sense to re-visit all of the rules and decide upon a set that we really want to follow. That should encourage devs to take checkstyle warnings more into account, instead of just thinking: “That bl... checkstyle annoys me with all its stupid warnings”. I must confess that that’s what I’m thinking myself sometimes :-\ > 18000 PMD violations is just sick. Things like rule [1] doesn't really help > the source code. We can do that if we get a budget for > nuclear-power-plant-grade > software. Same here I guess. Now may be the right time to launch the debate, actually. I’ll try to gather some energy in the next days for that. > [1] > http://pmd.sourceforge.net/rules/optimizations.html#MethodArgumentCouldBeFinal +1 I must say, I’ve never really grasped the benefit of doing this. I’d be happy to be enlightened, though. > On 12.06.2008 08:28:35 Max Berger wrote: >> Dear Fop-Devs, >> >> Jeremias is right - you actually need to use the output of these >> reports. At this time there are: >> >> 1849 checkstyle violations >> 18702 pmd violations >> possible (find)bugs. >> >> Many of these could be automatically solved using the eclipse >> "cleanup" tools (which can actually be called on the whole src dir!). >> However, that would result in a change in almost every file, and >> making merging of separate branches almost impossible. This should >> therefore not be done until 0.95 is released, to allow backporting. >> The main question is, should it be done at all? >> >> Max Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Code Quality Metrics
Max Berger wrote: Hi Max, Many of these could be automatically solved using the eclipse "cleanup" tools (which can actually be called on the whole src dir!). However, that would result in a change in almost every file, and making merging of separate branches almost impossible. This should therefore not be done until 0.95 is released, to allow backporting. The main question is, should it be done at all? I just wanted to remind you that the 0.95 release branch is not the only branch being actively worked on. For example; Adrian has 2 AFP branches that he is currently developing. Simon also has a branch with an alternative layout algorithm So doing a global cleanup of the code in trunk only would cause all sorts of problems. Chris
