class MyWicketApplication extends Application {
   .....
    private boolean isProd =
        "Production".equalsIgnoreCase(
            System.getProperty("com.google.appengine.runtime.environment"));

    @Override
    public String getConfigurationType() {
        return (isProd ? "DEPLOYMENT" : "DEVELOPMENT");
    }
}

Bam – Wickety GAE love!

Related posts:

1. visural-wicket 0.5 released – ready for action!
2. Announcing – visural-wicket
3. Testing Abstract Classes With Mockito and JUnit

• I’ve added Javadocs to the source for all the major pieces of functionality
• I’ve created an example application which demos all the key features and how to use them
• The example application is deployed LIVE on Google App Engine
• I’ve done a lot of testing on each component across all the major browsers
• Lots of bug-fixes and corner cases fixed
• Some reconsideration and tweaking of the API to reduce the likelihood of future changes as much as possible

Anyhow – it’s all up for download at the visural-wicket project page. Comments and feedback and welcome, via this blog, or the discussion group.

Related posts:

1. Announcing – visural-wicket
2. Wicket On Google App Engine (GAE) – Deployment Configuration
3. My “utility belt” now open-sourced…

It seems like it’s practically a requirement that all business reporting tools be difficult to learn, use and work with. JasperReports / iReport is no different. Don’t get me wrong it’s a good solution to a certain kind of problem (and it’s free and open source which doesn’t hurt), but the iReport UI is (and I’ll try to be kind) utilitarian at best.

Anyhow, to do any non-trivial report with iReport, you’ll probably need to use sub-reports, which are not very clearly documented as to how the hell they work.

I’ll be talking strictly about Java-bean collection data sources for this article, so you will need to translate if you are doing direct SQL queries or something else.

The Java-bean data source is nice because we can utilise our existing domain layer in order to create our report, rather than replicating the same logistics in SQL (or worse – stored procedures) and thereby having two places to update when requirements change.

To easily understand how sub-reports work, we need to understand how JasperReports works in general.

JasperReports are stored in XML files (JRXML) – if you’ve created any report you’d be familiar with these files. These XML files are translated to Java source code by JasperReports, and then compiled into regular Java CLASS files, which are executable by the Jasper engine. You could say that Jasper compiles the JRXML files into Java, and then Java will compile these into byte code.

When you execute a report you are essentially executing Java code. Keep this in mind when filling out expression fields in your report, and things will start to make more sense.

Generally you use a sub-report in a situation where you have a two or more child lists of data relating to a single parent element. A common use case would be a report with multiple details bands of different types. I say “different types”, because if you have nested children that relate to the same data set, then generally you can achieve formatting using groups with breaking on certain fields in the data set. Things get complicated though where you have one big report, which has multiple unrelated data sets inside it.

To avoid getting too meta – here’s a concrete example…

This report has a single main detail band (contact details – first and last names) and two sub-detail bands for each contact – addresses and phone numbers.

In Jasper we need to use two sub-reports to implement this. But before we get too far, let’s look at how we would create Javabeans to store this data.

The addresses:

package com.visural.report;

public class AddressBean {

    private String type;
    private String address;

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getType() {
        return type;
    }

    public void setType(String type) {
        this.type = type;
    }
}

The phone numbers:

package com.visural.report;

public class PhoneBean {

    private String type;
    private String number;

    public String getNumber() {
        return number;
    }

    public void setNumber(String number) {
        this.number = number;
    }

    public String getType() {
        return type;
    }

    public void setType(String type) {
        this.type = type;
    }
}

And the contact (parent) bean:

package com.visural.report;

import java.util.List;

public class ContactBean {

    private String firstName;
    private String lastName;
    private List<AddressBean> addresses;
    private List<PhoneBean> phones;

    public List<AddressBean> getAddresses() {
        return addresses;
    }

    public void setAddresses(List<AddressBean> addresses) {
        this.addresses = addresses;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public List<PhoneBean> getPhones() {
        return phones;
    }

    public void setPhones(List<PhoneBean> phones) {
        this.phones = phones;
    }
}

Finally, we need a test data source to use in developing our report. Here’s the factory for the report pictured earlier…

package com.visural.report;

import java.util.Arrays;
import java.util.List;

public class ContactFactory {

    public static List<ContactBean> create() {
        ContactBean stub = new ContactBean();
        stub.setFirstName("John");
        stub.setLastName("Smith");

        AddressBean address1 = new AddressBean();
        address1.setType("Home");
        address1.setAddress("123 Fake St\nFaketown\nFK 12345");
        AddressBean address2 = new AddressBean();
        address2.setType("Work");
        address2.setAddress("321 Bogus St\nFaketown\nFK 12345");
        stub.setAddresses(Arrays.asList(address1, address2));

        PhoneBean phone1 = new PhoneBean();
        phone1.setType("Home");
        phone1.setNumber("03 9876 1234");
        PhoneBean phone2 = new PhoneBean();
        phone2.setType("Work");
        phone2.setNumber("03 1234 9876");
        PhoneBean phone3 = new PhoneBean();
        phone3.setType("Mobile");
        phone3.setNumber("0432 123 456");
        stub.setPhones(Arrays.asList(phone1, phone2, phone3));

        return Arrays.asList(stub);
    }
}

The thing to notice here is that we have modelled the Javabeans exactly as we would if they were being used for some other purpose, i.e. we haven’t done anything special to make them usable in JasperReports / iReport.

In Jasper we configure a Javabeans data source that is created from a Collection, using our ContactFactory.create() method. We then add fields as follows, and create our report layout:

Note that the field names correspond to the Javabean property names.

Now for the important part. We then need to set the data source on the sub-report’s properties:

So we can just use an “data source expression” as our connection for the sub-report, and for the expression we create a data source on the fly using our collection of java beans from our current data source’s “addresses” and “phones” fields. “new net.sf.jasperreports.engine.data.JRBeanCollectionDataSource(datasource.getPhones())” is the Java code we would write if we were to create a Javabean data source in our regular Java code. JasperReports will replace $F{phones} with “datasource.getPhones()” (or its equivalent) as part of it’s JRXML to Java compilation process.

The rest is simple; our sub-reports define fields that match the AddressBean and PhoneBean properties:

With all that in mind, it really is a case of “it’s simple when you know how”, but be that as it may, I couldn’t find a concise description of how to do this in my googling. Hopefully this post will fill that gap. Perhaps everyone is still writing SQL-based reports against a single database? I don’t know, but using Javabeans is a nice flexible alternative to use SQL-based reports that gives you a lot of options in the long term.

If you’re still confused you can download the above code, and the JRXML reports in a Netbeans 6 project here.

Related posts:

1. Wicket On Google App Engine (GAE) – Deployment Configuration
2. NetBeans 6.7 Broke My Parameterized Tests
3. Testing Abstract Classes With Mockito and JUnit

The last few months have been dominated with getting married, home maintenance and Christmas preparations, and so I’ve had little time for much else. I did manage to fit a much needed holiday in there though, and I’m hoping to hit 2010 with a renewed sense of energy.

That said, I did start the visural-wicket project not too long ago, and that is where much of my open-source energy has gone of late. The project is being developed in my spare time, largely to support the application I’m creating in my work time, but with a view of becoming a key dependency for open-review, an as yet unannounced project I started a while back, but then put on the back-burner for a number of reasons (time, design considerations, etc).

Once I’ve fleshed out a few more of the “must-have” components in visural-wicket, I will start to push for feedback and co-contributors, should the reception be positive.

I also open-sourced my visural-common code, which forced me to do a clean-up and clear-out of some stuff which had been hanging around in my source tree for far too long.

At work, things have really be head-down, bum-up and WORK for the month or two, so I haven’t had the time or inclination to post any little “techy tid-bits” on the blog as a result. What I am considering doing in a short while though, is to put together a Wicket training series as a series of blog articles, as I think that would be valuable for the community and an interesting exercise for myself.

Anyhow, I’m rambling, so here’s to a great 2010!

Related posts:

1. visural-wicket 0.5 released – ready for action!
2. Announcing – visural-wicket
3. My “utility belt” now open-sourced…

Well I just open-sourced mine – http://code.google.com/p/visural-common/

Primarily this is to support visural-wicket and another open-source project I’m working on a little. Also, I end up rewriting this stuff at pretty much every job in some form or other. So if this code is open-source I won’t have to write it again – at least in theory

My “belt” used to be a lot bigger, but there’s more and more other open implementations of these sorts of things which I’m really happy with, and happy not to have to maintain by own version of. This is stuff that’s left over, and for a large part is just part of my style of code writing.

There’s not much of great interest in there – I personally think some of the small “helper” methods that are in there can make code read very elegantly, but hey, this is my “utility belt”, so I’m biased.

In any case – my reasons for open-sourcing this are purely pragmatic, but take a look through and take out the stuff you like.

Related posts:

1. Announcing – visural-wicket
2. visural-wicket 0.5 released – ready for action!
3. markdown-doclet Updated to v2

At work we’ve taken the plunge with Apache Wicket, which I have to say,

is a fantastic web framework. I’ve used a lot of them over the past few years and Wicket is by far, the best I’ve used (including non-Java frameworks such as Rails – just my opinion). Wicket’s component based, approach and it’s abstraction of the request-response cycle (e.g. handling of AJAX) is extremely elegant, without going to the extremes that frameworks such as GWT go to.

Something I have found surprising though, is that there doesn’t seem to be much of a Wicket component marketplace or community. I don’t know whether it’s complexity of building them, whether everyone is rolling their own, or whether everyone is pretty much happy with what’s there out of the box, but for my own needs I’ve started an open-source project to create the Wicket components I wish I had, and a few Wicket related utility classes etc.

http://code.google.com/p/visural-wicket/

visural-wicket is licensed under the Apache 2.0 license and is 100% free and open-source. The only work that I’ve done thus far is a new type of “drop down box” component, similar in some ways to the YUI Auto-complete control. Unlike that control though it has a mode which requires a list value to be selected (like a regular drop down box) and you may disable filtering (auto-complete) completely if you’d like. In essence it’s more of a drop down component and not really an auto-complete. I have some other neat features planned for this component too, such as the ability to exclusively select values from the source lists when you use multiple instances of the drop down on a single page.

The project is currently in alpha stages of development, however the drop down component is currently functional, if a bit buggy.

I have some other major items I want to contribute to this project, which I will discuss once I have a solid design to talk about.

Definitely interested in comments, feedback or collaborators on visural-wicket….

Related posts:

1. visural-wicket 0.5 released – ready for action!
2. My “utility belt” now open-sourced…
3. Wicket On Google App Engine (GAE) – Deployment Configuration

Rails apps can be a bit mysterious to deploy on Windows server’s however, so here is a 1 minute guide to installing Redmine on Ruby on Rails on Windows!

You will need an Internet connected Windows PC or server to get started. If you don’t have an Internet-enabled PC, you can do the install on an Internet connected PC and move the Ruby folder tree to your target machine, but I’ll assume you live in the 21st century and do have Internet connectivity.

1. Download version 1.8 of Ruby – the link is to the “all-in-one” installer for Windows. You need version 1.8, not 1.9 as Redmine only works on 1.8 right now.
2. Set up so Ruby’s “bin” folder is in your system or command prompt path. You should be able to type “ruby” at the command prompt and not get any “file not found” errors.
3. Create yourself some sort of “Ruby apps” folder and open a command prompt at that location, e.g. C:\Ruby\Apps or something
4. At the command prompt: “gem install rails“
5. At the command prompt: “gem install mongrel“
6. Download the latest stable version of Redmine and unzip into a subfolder of your Ruby apps dir (e.g. C:\Ruby\Apps\Redmine)
7. Configure the database.yml for Redmine to point to a database for your Redmine instance to use (I’ll leave that up to you)
8. In the Redmine folder, at the command prompt: “rake db:migrate“
9. If you’re using Redmine v0.8.7 or above, at the command prompt: “rake generate_session_store”
10. Test your Redmine installation is working, at the command prompt: “mongrel_rails start“, then hit http://localhost:[port]/ in your browser where [port] is the port Mongrel started with. Kill the server with Ctrl+C once you’ve verified Redmine is working.
11. At the command prompt: “gem install win32-service“
12. At the command prompt: “gem install mongrel_service“
13. Install Redmine as a Windows service, at the command prompt: “mongrel_rails service::install -N Redmine -c [your redmine folder] -p [portno] -e production“, replacing [your redmine folder] with the full path to the Redmine folder in the filesystem, and the [portno] being the port you’d like redmine to server on, e.g. 80 for standard http port 80.

If at any time you wish to remove the Redmine windows service (uninstall), you can enter “mongrel_rails service::remove -N Redmine” at the command prompt to remove it.

If you get an error at any one of the steps above, well, you’re going to have to go hit up Google for some solutions. But from a fresh install the above should work just fine – happy mining…

Related posts:

1. eBooks + DRM = Fail
2. The Results Are In…

This version fixes the {@link ClassNameEtc} Javadoc notation, which was broken due to the case-sensitivity of the markdown library.

It is highly recommended to upgrade to the new version

Related posts:

1. Markdown Doclet for Javadoc
2. visural-wicket 0.5 released – ready for action!
3. Automatic release packaging w/ version numbers for Netbeans Java Projects…

No related posts.

For example, say we wanted to filter out the classes in the package com.mycom.dbautodao, we could create a findbugs_filter.xml which contains:

<FindBugsFilter>
  <Match>
    <Package name="~com\.mycom\.dbautodao\..*"/>
  </Match>
</FindBugsFilter>

This uses a regular expression to filter out checks against all contents and sub-packages of the com.mycom.dbautodao package.

Similarly it’s possible to do the same with a <class name=”myregex”/> element rather than a <package/> element for finer control.

To enable the filtering we just need modify the tag in our Ant build file to include the filter, e.g.

<findbugs home="${findbugs.home}" output="xml" outputFile="${basedir}/dist/findbugs/findbugs.xml" excludefilter="findbugs_filter.xml">

While on the topic of regular expressions, I often find myself using this online regex checker tool which uses Java’s regex syntax – http://www.fileformat.info/tool/regex.htm. It’s a really quick and handy way of writing and testing a regular expression, since you can enter test string which provide both positive and negative test cases to develop against.

Related posts:

1. Automatically Updating Your Source File Headers With Ant’s ReplaceRegExp Task
2. Using Bottom-Up Iterative Object/Database Layer With hbm2java and warp-persist
3. Simple Guide To Sub-reports in JasperReports / iReport

Due to the legacy data structures (which are mostly in need of major refactoring, that can only occur in a long-term iterative fashion), we are completely segmenting the DAO layer from the business domain layer. The DAO layer and associated @Entity beans are generated automatically (and frequently) using the hbm2java tool which is part of Hibernate. To make things even more complex, our business layer also supports multiple logical databases…. We are using Guice, and the excellent warp-persist library to manage the JPA transactions and bootstrapping across these multiple databases (multi-unit support is relatively new in warp-persist).

The problem then comes though – unless we manually add all of our 1000’s of @Entity beans to the JPA configuration for each persistence unit (which is a potential source of bugs, and a pain in the ass), how do we figure out which beans belong to which database unit? Well annotations is the way that warp-persist implements this, unfortunately, hbm2java doesn’t know that… (i.e. it won’t add the annotations against the relevant classes).

This is actually easily solved using the same trick with Ant and the regex replacement from my last post…

   <target name="gen_hibernate" description="generate hibernate classes">
        <hibernatetool>
            <jdbcconfiguration revengfile="src/hibernate.reveng.xml"
                               configurationfile="src/hibernate.cfg.xml"
                               packagename="com.mycom.db.model"
			       detectmanytomany="true"
                               />
            <hbm2java destdir="src" ejb3="true" jdk5="true"/>
        </hibernatetool>
        <loadfile property="javaheader" srcFile="lib/standardheader.txt"/>
        <replaceregexp match="^package " 
                       replace="${javaheader}// DO NOT EDIT THIS FILE - THIS CODE IS AUTO-GENERATED${line.separator}package ">
            <fileset dir="src/com/mycom/db/model">
                <include name="**/*.java"/>
            </fileset>
        </replaceregexp>
        <replaceregexp match="/\*\*.*generated by hbm2java.*\*/" 
                       flags="sm" 
                       replace="/**${line.separator} * @version $Id$ ${line.separator} */${line.separator}">
            <fileset dir="src/com/mycom/db/model">
                <include name="**/*.java"/>
            </fileset>
        </replaceregexp>
        <replaceregexp match="@Entity" 
                       replace="@Entity @MyDbUnit">
            <fileset dir="src/com/mycom/db/model">
                <include name="**/*.java"/>
            </fileset>
        </replaceregexp>
        <replaceregexp match="import javax.persistence.Entity;" 
                       replace="import javax.persistence.Entity; import com.mycom.db.MyDbUnit;">
            <fileset dir="src/com/mycom/db/model">
                <include name="**/*.java"/>
            </fileset>
        </replaceregexp>
    </target>

You’ll notice I threw in a couple of bonuses there too… the following changes are automatically made to all of the generated code -

1. Our “standard header” (copyright / licence info) is added to the top of the file above the package …. descriptor.
2. The @version $Id$ Javadoc tag is added to the class level Javadoc (this is assuming you’re using SVN or CVS – replace as necessary).
3. The database unit annotation (@MyDbUnit in this case) is added next the @Entity annotation.
4. Finally we add the import for the @MyDbUnit annotation (this would only be required if it’s in a separate package – which it in our case it is).

We then copy / replicate this job for each database in the system (with appropriately separate hibernate.cfg.xml and hibernate.reveng.xml configurations).

Well I think this takes the cake for the most esoteric and narrow detail blog post yet… but my whole goal in setting up and posting to this blog is for my own future reference; if other people find it useful then that’s great, but really when I implement something that was kinda interesting, tricky, or indeed esoteric, then this is my own reference for later. YMMV.

Related posts:

1. Add Package (or Class) Filtering To Your Findbugs Ant Task
2. Automatically Updating Your Source File Headers With Ant’s ReplaceRegExp Task
3. Automatic Javascript and CSS Compression For Java Webapps

My “best case scenario” was there was a way to automate this with Subversion (or another source control system), similar to how the keywords substitution works for things like $Id$, etc.

The answer I accepted in the end was that you need to automate this substitution programmatically as part of the build process (or separate process).

As it turns out this is pretty straightforward to perform with Ant’s ReplaceRegExp and LoadFile tasks…

<target name="replace_headers">
    <loadfile property="javaheader" srcFile="lib/standardheader.txt"/>
    <replaceregexp match="(/\*.*\*/.*)??^package " flags="sm"
        replace="${javaheader}${line.separator}package ">
        <fileset dir="src">
            <include name="**/*.java"/>
        </fileset>
    </replaceregexp>
</target>

So first of all we have placed our “standard text” in lib/standardheader.txt, and we then use a regular expression to find the first instance of a comment block (if one exists – optional) followed by the package header (I’m assuming .java source here, so you would modify the regex as required for other languages).

We use the LoadFile task to reader the text into a property used for replacement.

This is a very neat solution which can live in your build file ready to be used if your standard header text happens to change. You could apply the same type of trick to standardise class javadocs to include certain keywords such as $Id$ if were so inclined as well.

Related posts:

1. Using Bottom-Up Iterative Object/Database Layer With hbm2java and warp-persist
2. Add Package (or Class) Filtering To Your Findbugs Ant Task
3. Automatic Javascript and CSS Compression For Java Webapps

import java.util.Collection;
import junit.framework.TestCase;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

@RunWith(Parameterized.class)
public class MyParamTest extends TestCase {

    public MyParamTest(String s1, String s2) {
        // do something with s1 and s2
    }

    public static Collection getParams() {
        // return test parameters
    }

    public void testSomeStuff() {
        // testing testing testing
    }
}

You may have found when you upgraded to Netbeans 6.7 (with the improved JUnit test runner) that your tests suddenly started failing.

This is because any class extending TestCase is run as a regular JUnit test and so will fail if it’s actually a parameterized test. Just change the code to use the static import instead:

import java.util.Collection;
import static junit.framework.TestCase.*;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

@RunWith(Parameterized.class)
public class MyParamTest {

    public MyParamTest(String s1, String s2) {
        // do something with s1 and s2
    }

    public static Collection getParams() {
        // return test parameters
    }

    public void testSomeStuff() {
        // testing testing testing
    }
}

Bob’s yer mother’s brother.

Related posts:

1. Testing Abstract Classes With Mockito and JUnit
2. 5 Reasons Why NetBeans Rocks
3. Simple Guide To Sub-reports in JasperReports / iReport

So what’s an easy way to test this sort of pattern?

A mock is not an appropriate solution, since we don’t want to mock our abstract class, we want to provide an implemention of the abstract methods, which we can mock to test the logic of the parent class.

There is a neat solution to this problem, using the great mocking framework for Java – Mockito -

public abstract class MyAbstract {
  public String concrete() {
    return abstractMethod();
  }

  public abstract String abstractMethod();
}

public class MyAbstractImpl extends MyAbstract {
  public String abstractMethod() {
    // we have to provide an implementation that will run without error
    return null;
  }
}

public class MyAbstractTest extends TestCase {

  public void testConcrete() {
    MyAbstractImpl abstractImpl = spy(new MyAbstractImpl());
    doReturn("Blah").when(abstractImpl).abstractMethod();
    assertTrue("Blah".equals(abstractImpl.concrete()));
  }
}

So what’s going on here?

Well Mockito (1.8+) implements a “spy” feature which doesn’t mock the object, it creates a “spy” wrapper around the real method implementations. This allows us to override the return values / exception behaviour of some methods, but leave other methods to implement their usual behaviour.

In the code above, we override the abstractMethod() which is part of the implementation class, to test the concrete() method in our abstract class. Of course, usually the abstract class would be doing something more interesting than simply returning the implementor’s value, and so we would implement tests in the ususal fashion to test the different code paths in our concrete() method.

Related posts:

1. NetBeans 6.7 Broke My Parameterized Tests
2. Simple Guide To Sub-reports in JasperReports / iReport
3. Unfortunately Interesting Java Generics

Read on for 5 features that might not be obvious to someone test-driving NetBeans for the first time…

#1 Project Local Libraries

Ticking the innocent looking “”Use Dedicated Folder for Storing Libraries” checkbox on creating a new Java project will simplify project portability down to a complete non-issue. All JAR dependancies are stored in the “lib” folder underneath your project and are automatically copied to the distribution folder at build time. You can guarantee to take your project to any machine and run the build with Ant (or NetBeans) and it just works.

#2 Customisable Ant Builds

NetBeans uses Ant (by default) for managing all aspects of building, running, testing and documenting your Java projects. And while the builds are machine-generated they’re not impossible to read and work with.

However, you don’t even need to modify the NetBeans generated build logic – there are a whole bunch of “override points” in the build logic in which you can embed new logic, or override the default behaviour.

And since NetBeans uses Ant to build, deploy and run, you can guarantee that if it worked in your IDE, then it’ll work on the build server or anywhere else you want to build the project.

#3 Built-in Profiler

The built in Java code profiler in NetBeans kicks ass. There are certainly equally useful, or better, tools available commericially, but for a pain-free out-of-the-box experience, the NetBeans profiler is great.

Features include -

• Real-time display of run-time profiling
• Filtering of profiled classes
• Memory usage and garbage collection stats
• Saveable profiling results for future comparisons
• Low barrier to entry – very straightforward and simple to get started

#4 Refactoring Tools

The refactoring tools are exactly what you would expect and allow you to move, rename and safely delete any code element as you need. The “Introduce Method” is particularly useful for refactoring code blocks that start to get a little too large. “Introduce Method” is probably not the logical name (it was renamed from “Extract Method”) but it does the job none-the-less.

#5 Call Hierarchy

Tucked away in the context menu is the under-rated “Call Hierarchy” tool. Right click on any method and invoke the tool and immediately see all the callers, and their call stacks. Flip the switch and see the call stack that this method makes to other methods. This one tool can give you a very fast detailed understanding of what a method’s dependancies are. It’s a great way of coming up to speed on a code base without doing heaps of opening, closing of files and manual “eye-balling”.

Related posts:

1. Automatic release packaging w/ version numbers for Netbeans Java Projects…
2. Automatic Javascript and CSS Compression For Java Webapps
3. Testing Abstract Classes With Mockito and JUnit

I had planned to use separate interfaces bound to a single implementation class with Guice – thereby keeping a single implementation so long as the models are in sync, and having an interface contract that will be break should a developer try to modify the model without understanding the implications to the dependent layers.

This seemed like a great approach, but my less-than-deep understanding of Java Generics has thrown a spanner into the works.

This article at IBM Developerworks is a good read -

[Generics] bear a superficial resemblance to templates in C++, both in their syntax and in their expected use cases. But the similarity is only skin-deep — generics in the Java language are implemented almost entirely in the compiler, which performs type checking and type inference, and then generates ordinary, non-generic bytecodes.

This key point here is that generics are implemented almost entirely in the Java compiler. This was something I was aware of, but hadn’t really given any thought as to what that means. At the simplest level, that makes a class such as this one, invalid -

  public class DoesNotCompile {
      public void setList(List<String> stringList);
      public void setList(List<Integer> integerList);
  }

Whereas the non-generic equivalent is perfectly valid -

  public class CompilesJustFine {
      public void set(String string);
      public void set(Integer integer);
  }

This is because that while List<String> and List<Integer> are differentiated at compile time, they are both just List classes that are indistinguishable from one-another.

Because of erasure, List<Integer> and List<String> are the same class, and the compiler only generates one class when compiling List<V> (unlike in C++). As a result, the compiler doesn’t know what type is represented by V when compiling the List<V> class, and so you can’t do certain things with a type parameter (the V in List<V>) within the class definition of List<V> that you could do if you knew what class was being represented.

Also, parent-child class relationships don’t work as you might expect on first perception. For example you might think it is reasonable to use a List<Integer> where a List<Number> is required. Integer is a child class of Number, why isn’t that valid?

It turns out there’s a good reason it doesn’t work that way: It would break the type safety generics were supposed to provide. Imagine you could assign a List<Integer> to a List<Number>. Then the following code would allow you to put something that wasn’t an Integer into a List<Integer>:

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));

But. we can work around that by using List<? extends Number> instead, thereby making it clear we’re not fussed if it’s a Number, or any of it’s children.

learning to use generics will almost certainly provide some opportunity for head-scratching (and sometimes cursing) along the way.

Yep.
And as for my actual problem with the interface binding? Well my question at stackoverflow.com tells the story

Related posts:

1. NetBeans 6.7 Broke My Parameterized Tests
2. Testing Abstract Classes With Mockito and JUnit
3. Automatic Javascript and CSS Compression For Java Webapps

Recently I was involved in recruitment for a number of development positions. Although I have reviewed CVs and done interviewing before, it had been specific roles with only a couple of candidates, whereas the recent positions had a large number of applicants for multiple positions.

This was a very interesting process to be involved in, and has given me a different perspective on the job application process which I believe will be helpful in the future when applying for IT jobs. Read on for the common problems and some tips I found when reviewing candidates applications…

NB. This is solely based on my personal experience and (of course) I am not a HR professional, but often for technical roles it will be a technical resource that evaluates the candidates, so with that in mind, read on…

Key Point

Think about the person who is reviewing your application and communicate to them.

They probably have a whole pile of CVs and application letters to read through, and they have a good idea of the sort of candidate they have for the job(s). They are trying to eliminate as many people as they can on that basis, as quickly as possible.

And, more than anything else, they want to know how well does your experience match up with the job needing to be filled?

With that in mind, tailor your application to make the reviewer’s job as easy as possible.

Tip #1 – Keep it simple and concise.

You have no idea how many people have applications numbering almost 10 pages. With a CV of that size you are telling the reviewer one of two things:

• You don’t know what skills are important to the job, so you are putting down everything in the hope that something will be relevant.
• You are too lazy to tailor your application to the position you are applying for.

So you’re either inept or lazy, neither of which are desirable in prospective employee. Keep your CV to 3 or 4 pages at the most, less if you can. Don’t add lists of skills you say you have, but can’t back up with some tangible experience or qualification.

Which leads me to the next tip…

Tip #2 – Remember that the reader is a skeptical one.

The reader will be skeptical of your past work, performance and achievements. It is your task to prove to them that you are as good as you say.

Make it clear what you did.

Some people seem to think that being in a team that was building a product “X” or using a technology “Y” means you can say you are an expert in creating and using “X” or “Y”. That might get you an interview if you’re lucky, but you better have the skills to back it up.

In most cases, it is very time consuming and difficult for someone reviewing an application to figure out what the applicant actually did in their past work.

So make sure you write your past experience in the context of what you did while you were there, and what you contributed specifically!

Make it clear the technologies you used to do the things you did.

Just because someone in your team used [technology X] doesn’t make you an expert in [technology X]. The person reviewing your application knows that, so tell them what tools you used to achieve the things you said you did.

Notice I wrote, “the things you said you did”. A large number of applicants write a big box at the start of their CV’s with 50 different technologies / languages / frameworks and a number of years experience. Someone reviewing your application is very unlikely to take something like that at face value, and similar to my first tip, shows that you are just trying to get a foot in the door on the basis of some buzzword. It might work, but it adds more noise than signal, and again, you better be able to back up all those technlogies with skills and experience.

Tip #3 – Write your past work experience in layman’s terms.

Unless you are applying for a job at a workplace in the same industry or business domain as your last one, try to explain all your past projects in layman’s terms. Avoid domain-specific language or buzzwords, and concentrate on the value delivered to users and types of systems (technology) that you built and delivered.

My rule of thumb would be -

Explain your past work experiences as you might explain them at a dinner party with friends.

Industry-specific jargon and buzz-words will be lost on the reader if you are applying for a job in a different domain, and just add noise to your message. You want the reviewer of your application to understand what you did, not be baffled by it.

Tip #4 – Ditch baggage.

This is an extension of Tip #1 – more is not always better.

If you have 10+ years industry experience, you don’t need to include a university transcript with all your results. For any professional position that requires tertiary qualifications, you certainly don’t need to mention your primary and secondary school activities!

Similarly, if you have past experience that you’re not proud of, for example poor university results or a job at a company that didn’t reflect well on you, leave it out! You need to sell yourself (without distorting the truth), so leave out old baggage. You can talk about some of those things at the interview if you are asked, and maybe comment on those less-than-stellar experiences in the context of learning experiences, but don’t present them on a CV where you can’t put them into context for the reader. (Remember the reader is a skeptical one!)

Tip #5 – It’s okay to have a personality!

The vast majority of applications read very professionally, and very dry. Most people have interesting personalities, likes, dislikes, quirks and interests. It’s okay to present yourself with a little personality. In fact it is the single easiest way to set yourself apart from other applicants.

Talking about the hobbies and interests you have outside of work (and consider writing a sentence about them, not just personality-less dot-points) is a good way to let the reader know what sort of person you are.

If you are passionate about, something, anything - talk about it. Appear as a person, not a “professional”. We work with people, not professionals on a daily basis, despite what some companies or cultures want you to believe.

Your past experience and technical knowledge are only 50% of what contribute to getting you a job, the other 50% is personality and attitude. If you don’t have a personality on paper you are hiding half the information the employer needs to make a decision on whether to hire you.

A note about including photos of yourself…

Including a photo of yourself is one way to add personality to your application; but make sure it’s a good photo! If you include a weird, poorly lit or too casual photo then you’re better off not to include one at all. I would recommend that you err on the side of not including a photo, unless you feel very sure that it will add value to your application.

Related posts:

1. Recruitment from the Other Side – Part 2

This means at least, stripping out all the white-space, comments and other non-essential character data from your files, but can also mean code compression / obfuscation as well.

One of the best tools for this task is Yahoo’s YUI Compressor, which does a fantastic job of compressing down both .js and .css files.

Better yet, it is very easy to automate this compression process as part of your Ant build process for a standard Java web application.

Read on for the details…

We’ll need a couple of add-on JAR libraries; firstly (and most obviously), YUI Compressor, which is available from Yahoo as a single JAR which can be placed into our “lib/” folder of our web project (or similar location – I will assume lib/ for now).

Secondly we will need an add-on task for Ant in the ant-contrib project which allows us to iterate the file system, performing tasks (the <foreach> task). Note, that the sourceforge site for the ant-contrib project is a little confusing, you may have to view “all downloads” to find the actual ant-contrib JAR download.

Again place this download in the lib/ folder of the web project.

Now we can change our build file to compress…

    <taskdef resource="net/sf/antcontrib/antcontrib.properties">
        <classpath>
            <pathelement location="lib/ant-contrib-0.6.jar"/>
        </classpath>
    </taskdef>

    <target name="yuicompress"
            description="Compresses a CSS or JS file using YUI compressor">
        <java jar="lib/yuicompressor-2.4.2.jar" fork="true">
            <arg value="-o"/>
            <arg value="${yuicFile}.comp"/>
            <arg value="${yuicFile}"/>
        </java>
        <move file="${yuicFile}.comp" tofile="${yuicFile}"/>
    </target>

    <target name="-post-compile">
        <foreach target="yuicompress" param="yuicFile">
            <path>
                <fileset dir="build">
                    <include name="**/*.js"/>
                    <include name="**/*.css"/>
                </fileset>
            </path>
        </foreach>
    </target>

The key task to invoke is the “-post-compile” task. This is based off a standard Netbeans web project build.xml, but you can use this in a free-form build.xml just as easily by calling the -post-compile target as a dependancy of your packaging / WAR target.

Essentially after the build step and prior to WAR packaging we compress in-place the .CSS and .JS files in the build folder. The nice thing about this approach is that we can work on human-readable CSS and Javascript in our IDE but deploy compressed content automatically. There is no need to maintain a “myCode.js” and “myCode.min.js” and you can even work with the “non-minified” versions of your favourite API should you wish to as well.

Yahoo!

Related posts:

1. Automatic release packaging w/ version numbers for Netbeans Java Projects…
2. Automatically Updating Your Source File Headers With Ant’s ReplaceRegExp Task
3. 5 Reasons Why NetBeans Rocks

I spent some spare time this week creating a mash up of sorts… a “markdown” doclet for Javadoc.

Markdown-Doclet Project on Google Code

Markdown is a light-weight markup language which reads much like plain-ASCII-formatted-text, as opposed to HTML which reads like… well HTML.

In fact HTML is pretty damny unreadable, which is why is frustrates me to see developers putting a whole <ul><li>bunch</li><li> of</li><li> html</li></li> <li>tags</li></ul> in their code’s Javadoc comment boxes only to rended it almost impossible to read in the place where you’re most likely to read it (in the code).

The idea of the Markdown doclet is that you can write simple (markdown) text into your Javadoc comments and they will be translated nicely into HTML in your final Javadoc output.

The hardest part of this doclet was figuring out how the hell to patch the standard Sun doclet post Java 1.5. In fact the answer to this is that you need to duplicate the whole damn thing, since they effectively stopped anyone using any part of the current class tree by putting a hard lock into the code.

I was quite suprised at how badly supported the whole Javadoc tool is by Sun. I would see Javadoc as being one of the best out-of-the-box features of the Java platform and probably one of the biggest reasons for it’s wide adoption in the early years.

Anyhow, I have basically glued together the (GPL’ed) Sun doclet (with some changes), MarkdownJ (a Java implementation of Markdown) and UMLGraph.

UMLGraph? – Well I love the UMLGraph doclet which embeds UML class diagrams into your Javadocs. The UMLGraph doclet works by calling the Sun standard doclet and then doing some mods on the files that are generated, so the markdown doclet can work interchangeably with UMLGraph, albeit I had to patch UMLGraph to make that happen, since the Sun standard doclet doesn’t implement any standard interface which would allow a drop in replacement!

I hope other developers can make use of this doclet, and we can keep HTML in our browsers where it belongs!

Related posts:

1. markdown-doclet Updated to v2
2. 5 Reasons Why NetBeans Rocks
3. The 5 Minute Guice Primer

To summarise my experiences – Guice is a Dependancy Injection and Aspect Oriented Programming framework for Java. This is the turf that’s normally owned by Spring of course.

So how is Guice different to Spring?

• No XML!
• Narrower scope: Guice only does DI and AOP, unlike Spring which covers a wide gamut of requirements.
• Heavy and mandatory use of annotations.
• …and in my opinion, a more refined and elegant design.

I think one of the main reasons I like Guice so much is the absence of XML. I really hate XML and Guice’s “Module” concept is a great replacement for text configuration. I would be interested to know how often in practice that Spring’s XML configuration is changed in situations where a rebuild of the application is impossible. The argument for that sort of configuration has always seemed like a straw man to me. As a bonus of the Guice Module approach, you get type checking and compilation of your configuration. [It would be interesting to see if someone does implement an XML configurator for Guice though - I'd say it's only a matter of time].

How to get up to speed real fast?

1. If you’re not familiar with DI and/or AOP then do some reading. A framework can only solve a problem that you know you have.
2. Watch the recent Google IO tech session for the 60 minute fast-track introduction.
3. The Guice wiki is helpful, but I found the external links and discussion group to be more helpful.
4. Write something! It’s a dead easy framework to get your head around, and the fastest way to solidify your knowledge is to do.

Related posts:

1. Using Bottom-Up Iterative Object/Database Layer With hbm2java and warp-persist
2. 5 Reasons Why NetBeans Rocks
3. Wicket On Google App Engine (GAE) – Deployment Configuration