javac from the command line

You are a Java developer and your platform of choice is Windows. I'll point you to a deeply nested directory with lots of source files in it and ask you to compile them. How do you do it?

If you immediately fire up your IDE, create a project, set it up with the source files and output directory and hit the Make button, then find out there is a quicker way to do it from the command line, an option many ignore:

cd the_directory_i_gave_you
dir /b /s *.java > source_files.txt
mkdir ..\out
javac -d ..\out @source_files.txt

one-option names

Is the name of a software shop important in making the business successful? I'd say no considering that many stupid-name companies do great. Back in my iQuest days, we used to work together with a UK software consultancy company called Conchango, how about that for a name?

Still I can't help wondering about companies whose names relate to current technologies and trends - what about the times when these will be obsolete? If you are thinking ObjectMentor, I think they'll survive, and it turned out it was a good name choice since object has become the synonym for good programming style.

But what about XML-INTL? These guys should have it in their mission to make sure XML never goes away ... it can't be that hard, we all love XML, don't we? XML Networks are clearly better positioned, networks will not go away soon, if ever.

A particular case are the names in the Microsoft world. The chances a technology will go obsolete are weaker in this self-contained corner of the world where the open source community who usually create novelty (thus obsolescence) is not so active.

One trend I find today is promoting the website and not the company name. Clearly a better strategy from this point of view: in rough times, just clone the website and advertise for another technology while still operating the same company.

So from a technological name point of view, the business success recipe is clear: the broader the meaning, the less chances to go out of business.

pmd applied or the chain of good things

Because the 'patching period' is close to finish and I have zero bugs in my queue now, I put some time into investigating tools that would reduce my frustration with the code, so I devoted the start of the week to PMD.

There are quite a few angles you can approach software quality from and PMD does this by analyzing the source code for mistakes and even ventures into reporting bad code design. By going after source code quality, you leverage the fact that there is greater consensus about whether code A is better than code B than if you were to decide on more general quality metrics like maintainability: how confident would you be in asserting that project A is more maintainable than project B?

It took me about one day to go over over the set of PMD rules applicable to my java desktop project; some of them I had to try out and I eventually filtered out those that I found controversial, reporting false positives and those that simply didn't feel right. I wish the project maintainers could exercise their veto more often against the rules submitted by various contributors, but I guess the philosophy is to let you use just the rules you like.

The way you can do that is create your custom rules file which will include only the PMD rules you want run - notice some of them can be customized with properties -

<ruleset name="My rules"
    xmlns="http://pmd.sf.net/ruleset/1.0.0"
    xsi="http://www.w3.org/2001/XMLSchema-instance"
    schemalocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
    nonamespaceschemalocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
  <description>A custom rule set</description>

  <rule ref="rulesets/basic.xml/EmptyCatchBlock">
    <properties>
      <property name="allowCommentedBlocks">
        <value>true</value>
      </property>
    </properties>
  <rule ref="rulesets/unusedcode.xml/UnusedPrivateField">
</ruleset>

and include it in the PMD classpath.

Two benefits I am expecting from PMD: a smaller code-base (rules like UselessOverridingMethod and UnusedPrivateMethod) and a slightly better/faster usage of the Java library classes (rules like StringInstantiation and InefficientStringBuffering). A collateral benefit could be that my team would learn to write better code after they'll correct their mistakes. What if they will be so thrilled with the experience that they will at their turn plug in new quality tools ... what if they will blog about this and spread the word to a wider audience? ... I can only imagine ...

In the end I'll just say that an improvement never comes alone: here is my humble shot at improving PMD itself: