Posted on

UUID’s in Java

UUID’s are useful for making unique reference numbers of things.  In an ideal world these UUIDs are so long, they never collide.

The first place to discuss UUIDs would be RFC 4122.  The next part would be the wikipedia entry for a more concise version.

So why generate UUID’s?  One reason could be to generate a unique code to identify a particular PC (mac address?).  Another is to identify points in time (and can include the machine aka node’s mac address that created the UUID).

Further refs:

Java 6 api UUID entry
Blog that touches on UUID support in Java

Posted on

Lessons in Jasper (i)Reports

I had some great fun today playing around with iReport. I used Dynamic Jasper before iReport so it was an interesting experience seeing the platform first hand and seeing all the capabilities it offered via the properties panels in iReport for the various report components. It was interesting to see the layout capabilities of a Jasper report and how Dynamic Jasper worked with these.  A quick refresher, a Jasper report is split into different bands: Title, Page Header, Column Header, optional group headers, various detail bands, optional group footers, optional column footer, Page Footer, Last Page Footer, Summary, a No Data and a Background band. DJ follows closely to the Jasper specification & its capabilities. There are some things it can do better than iReport and some it cant.  The most obvious DJ benefit is the programatic table layouts, which is all through code and means your dependent properties are known in advance when you refactor a business class – you should be able to know when your report is going to break.  One issue I’ve had with DJ is that laying out components doesn’t always happen as beautifully as you’d expect.  Sometimes the width of columns totals is too small with unexplained wrapping or sometimes the layout is just wierd.   And there is no way of knowing until runtime that the seemingly simple change has broken the layout of your wonderful report. iReport on the other hand is comprised of datasources, sql or xml, and a jrxml template you design.  You aren’t fixed into a particular table structure, you can have multiple group variables on the same field without any kind of reprocrussions and the WYSIWYG editor and preview allows you to quickly play with report layout and styles and know what you are getting.  You can also start with a SQL query as your datasource to prototype and then at runtime inject a proper JRDataSource (the same DynamicJasper uses) – easy! But in the end of the day both of these compile down to .jasper files that Jasper Reports then fills in with your data and turns into these jrprint files – effectively a softcopy of your final report that you can turn into PDF or feed into a screen viewer.

Column Headers above Group Headers

One neat feature that Dynamic Jasper provides is the ability to put the column labels in a tabular format report below the group label via its setGroupLayout() method. I didn’t realise that the only thing that Jasper supports is having a column header band above the group header band. So in iReport, this means you cant have group title followed by the column headers. The way around this in iReport is that in your Group Header, you move the column headers into the last Group Header band you want.  That way each time the group header gets displayed, so too will your Column header, underneath the Group label.

SubReports for non-data areas

The other trick I learnt was that when generating subreports that dont normally have data in them, for example a Header and Footer section, you need to be change the subreports ‘When No Data’ value to something like ‘All Sections, No Detail’ so that it doesnt simply show a blank page when you preview it and include it in a master report.

One thing that doesn’t work is that you can’t put the total page count in a subreport since its evaluated at report completion time and the subreport is already processed by the time its done.

You can’t do that on Television

Layout wise the iReport stuff really starts taking a big lead over DJ.  The biggest case in point was the Sales Report dashboard demo that shows a 2 x 2 panel dashboard with a graph, table, pie chart and timeline chart.  The right column isn’t as wide as the left and there are also some neat tricks about using the REPORT_COUNT variable thats in each jasper report to limit the size of the dataset to do Top 5, Top 10 style reports.   The video is worth watching just so you know some other little tricks.  For example a foreground alpha channel percentage setting that gives pie charts a futuristic look is worth knowing about.

Pain in the bum Error Messages

Here DJ is better than iReport.   One frustrating experience I had with iReport is an error message about an expression with unexpected ‘+’ token.  I looked through all the expression fields I could find, searched the XML but couldnt find the place it was talking about.  In the end I started the report again from scratch and slowly recreated the components from the old one trying to eliminate which was the problematic component.  One thing that I noticed in the screencasts is that the designers use the Preview button frequently after any change that introduces a new variable, param or field, or datasource, or whatever.  There are a lot of silent traps you can get into and therefore a lot of checks you need to do across the way. Dynamic Jasper is a bit better since

  1. you are limited in what you can do somewhat, you aren’t generally going to get a compile error,
  2. the error messages are a little clearer but not always,
  3. you have the source code and its a little easier to understand.

Conclusion

iReport and DJ both offer various views into the Jasper Reports framework.  Its certainly knowing both.  Since you can combine them, you can use iReport to do the complicated formating and embed DJ reports.

References

http://www.opentaps.org/docs/index.php/Tutorial_iReport
http://www.jasperolap.org/plugins/espforum/view.php?group_id=83&forumid=101&topicid=13489
http://jasperfor
http://jasperforge.org/plugins/mwiki/index.php/Ireport/Tutorialsge.org/uploads/publish/ireportwebsite/IR%20Website/tutorials/Getting%20started%20with%20iReport/Getting%20started%20with%20iReport.html

http://jasperforge.org/plugins/mwiki/index.php/Ireport/Product_Tour
http://jasperforge.org/plugins/mwiki/index.php/Ireport

Posted on

Time for a spruce-up

WordPress 3 has arrived and it coincided with a need to move my web host platform to one with an up to date php/mysql installation that could support WP 2.1+

The move to the new host was relatively straight forward and once confirmed working I proceeded to upgrade WP and take advantage of the new features.

Overall the admin screen is beautiful and the widgets editing is great.  I’m quite happy with the pimp up I’ve done so far and the fact I’m now free to write whatever I like without running into hurdles from my prehistoric WP version.

Posted on

Apache Commons reflectionHashCode builders

This was my response to this short post about using reflectionHashCode to implement your objects hashCode method dzone.com – overriding equals() and hashcode() – best practice

I’ve come to love the Apache commons builders over the last couple of years and use them where possible.  They avoid a lot of boilerplate.

Wanted to raise something with regard to the hashcode builder.  Today I watched a webinar, ‘Hash hash, away it goes’ (http://www.javaspecialists.eu/webinars/ and also described in text here: http://www.javaspecialists.eu/archive/Issue031.html) which was about writing hash code methods on your objects and using them as key objects in your HashMaps – and what happens when they arent written properly causing elements to not be retrieved from the map! 

One of the summary points of this article was that hashCode methods should be as fast as possible and one of the participants asked about the apache commons reflection hashcode builder.  Because the reflectionHashCode uses reflection it wont be the fastest possible implementation possible that you can write, so if you are concerned about performance, then you should consider using the other non-static implementation of HashCodeBuilder (granted not so dynamic).  The javadoc for HashCodeBuilder (http://commons.apache.org/lang/api/org/apache/commons/lang/builder/HashCodeBuilder.html) mentions reflection is slower than testing explicitly.

One thing you could do is if using dynamic fields though (say in a language like Groovy that allows fields added at runtime) is consider the fields which are immutable identity fields and have your hashcode builder just combine the hashcodes for those.  Presumably (and its a big presumption), your fields that are being added dynamically arent immutable and arent defining the identity of the object.  So the question is, do you really need to add those fields to your hashcode method in the first place?  You could then just define a hashcode builder on the immutable id fields that are in the base class and it shouldnt change how your HashSets and Maps behave regardless of dynamic fields added.  But if your new fields are added from subclasses to a parent domain, there is the appendSuper method on the HashCode builder