Tired of writing nonsense javadoc / xml-comments?

Getting Real is about skipping all the stuff that represents real and actually building the real thing.

-- 37signals

I can't make up my mind if writing javadoc (or xml-comments in .NET) is falling in the above category ... but often I have the feeling it is preventing me from getting real.

Very often it just doesn't generate any additional value. Usually JSF-Backing-Beans are a good example for this: In most cases the comment does add exactly nothing compared to the property name...

/**
* Get the name
* @return name
*/
public String getName(){
...
}

People from the department of redundancy department would be delighted ... the DRY-gang just left the building ...

I do not want to dispute that sometimes comments are absolutely necessary. But I don't think that it is a good solution to rigorously require comments on everything, just to catch the few spots that need them...

... thats like requiring that everybody wears a helmet at work!

Nevertheless in most projects this is the case... as a consequence the quality of the comments is mostly bad and nobody reads them...
But writing them costs many hours and even can give reason for passing or failing a milestone including the the whole traffic on the escalation-ladder ... bummer!

At least there are some tools that can outomate this nonsense (even though this results in an excuse for not getting real!):

JAutodoc for Eclipse

GhostDoc for Visual Studio

How to export your database schema with Hibernate3 and Ant

There is a lot of old information floating around on the net. Currently the correct way to export your database schema with Hibernate3 and Ant is using Hibernate-Tools.

The according Ant-task is org.hibernate.tool.ant.HibernateToolTask (documentation is here). It is contained in hibernate-tools.jar

The resulting section in build.xml should look like this:

	
<!-- Hibernate Tools import -->
<taskdef name="hibernatetool"
		 classname="org.hibernate.tool.ant.HibernateToolTask"
		 classpathref="lib.classpath"/>

<!-- Export the database schema -->
<target name="schemaexport" description="Exports a generated schema to DB and file">

	<hibernatetool destdir="${basedir}">
		<classpath refid="build.classpath"/>
		<!-- Use META-INF/persistence.xml 
			<jpaconfiguration/>-->
		<annotationconfiguration configurationfile="${build.dir}/hibernate.cfg.xml" />
		<hbm2ddl
				drop="true"
				create="true"
				export="true"
				outputfilename="ddl.sql"
				delimiter=";"
				format="true"/>
	</hibernatetool>
</target>

Unfortunately most of the documantation of Hibernate-Tools seems to imply that it is "just" an eclipse-plugin. The truth is, the ant-tasks are completely usable on their own.

The Ant-task org.hibernate.tool.hbm2ddl.SchemaExportTask seems to be depreciated. Even though it is still contained in hibernate3.jar...

See also this page.

No setters, no getters ... return of OO?

Have you also often been wondering what your state-of-the-art enterprise-project has to do with the highly praised object-oriented principles?

Well, you are not alone. I think that's an omnipresent dichotomy in current enterprise development. Object-orientation is generally accepted as the way to go. It get's preached to you at university, you read books about it ... but then reality slaps you you hard in the face:

Welcome in the trenches of enterprise-development where object-orientation usually goes no further than using an object-oriented language!

Domain Driven Design (DDD) promotes the application of true object-orientation to enterprise-systems. But the concrete realization of DDD is often harder than we would think, and requires a lot of design-effort and experience.
Dave Laribee and Keith Braithwaite are now promoting an interesting idea: Promoting object-orientation by not using setters and getters!

The idea is, that by not using setters and getters you are forced to think about classes, responsibilities and collaboration instead of procedures over dumb data structures.

Read the posts for yourself, its an interesting thought (and don't miss the coments):

Super Models, Part 2: Avoid Mutators

TDD, Mocks and Design

The discussion is not new, the topic was already discussed in this article: Why getter and setter methods are evil.

There is much truth in those articles. I wish those ideas would be more widespread down here in the trenches...

Adding a header-comment to all java-files in a repository

I had to add a header comment to all java files in a given repository.
Not knowing any better solution, I wrote a groovy script:

 1 def delClos
 2 delClos = { println "Checking directory: ${it.canonicalPath}";
 3     it.eachDir( delClos );
 4     it.eachFile {
 5         if(it.name =~ ~/.*\.java$/){
 6             def original_text = it.text;
 7             if (!original_text.startsWith('/*')){
 8                 println "Adding header to file: ${it.canonicalPath}";
 9                 def className = it.name.substring(0, it.name.length() - 5);
10                 it.delete()
11                 def new_file = new File (it.canonicalPath)
12                 new_file.createNewFile();
13                 new_file << '/*'                            <<'\n'
14                 new_file << ' * ' << className              <<'\n'
15                 new_file << ' *'                            <<'\n' 
16                 new_file << ' * Version $Revision$, $Date$' <<'\n'
17                 new_file << ' *'                            <<'\n'
18                 new_file << ' * Project:  Mayhem'           <<'\n'
19                 new_file << ' *'                            <<'\n' 
20                 new_file << ' * (c) 2008 by Tyler Durden'   <<'\n'
21                 new_file << ' */'                           <<'\n' 
22                 new_file << original_text;
23             }
24         }               
25     }
26 }
27 delClos( new File("."))

This is certainly not the most elegant, clever, performant ... whatsoever solution, but it did the job. If you have a better solution, please leave a comment.

Alternatives to Hibernate

Update: See my wiki page here for a more recent overview.

I just came across Carbonado, another persistence abstraction for Java. This is another alternative to Hibernate/JPA.

Carbonado implements the ActiveRecord pattern, which pursuits quite another design-paradigm than the DataMapper pattern, which usually is implemented by JPA and Hibernate.

As a reference I try to list the current persistence frameworks for Java. The list is certainly not complete... please leave a comment if you know another framework.

Most familiar are the mainstream JPA providers :

Hibernate

TopLink / TopLink Essentials / EclipseLink

KODO / OpenJPA

JPOX

There are other, less well known JPA-Providers:

Apache Cayenne

Raisin Amber

DataNucleus

CocoBase

Frameworks following another paradigm:

Carbonado

iBatis

Ebean

For the Java-Platform there exist other interesting alternatives:

JRuby with ActiveRecord

Groovy with GORM

Megalomania - trust me, I know the answer!

In a recent project we had a code-review. The following piece of code turned up:

	
public static void configure(File cfgFile) {
		Configuration cfg = new Configuration();
		try {
			File mappingResources = new File("resource-gen/hibernate.cfg.xml");
			cfg.configure(mappingResources); // get configuration of mapping ressources from the generated hibernate.cfg.xml in src-gen
			cfg.configure(cfgFile); // get additional configuration from the passed file
			sessionFactory = cfg.buildSessionFactory();
		} catch (Exception e) {
			int n = 42;
		}
	}

I seem quite confident, that I know the answer to everything ...

Where are the ruby jobs? (Part 2)

Some posts ago I was looking for ruby jobs here in switzerland and the outcome was quite disappointing...

This weekend I was pointed to rubyonrails.ch. There are lists of rails jobs and companies who offer rails development.

But the perspectives are still not motivating ...

Salary vs. Suckage - is there a relation?

Jay Fields recently has some interesting posts about his career and his opinion of the current state in enterprise software development.

The following quote from Be Your Start-Up I found especially thought-provoking:

Two and a half years and a lot of blog posts later I turned down an offer that was $174,000 a year. This wasn't $174,000 a year because the work sucks. It was a good job, but I wasn't ready to leave ThoughtWorks.

This implies that there is a correlation between salary and suckage of work!

If this is true, foot-soldiers like me out here in the trenches of enterprise IT departments have to ask ourselves:

• Am I getting a good salary? Hmm... why might this be?
• Does my work suck? Hmm... am I really paid appropriately?

I blogged about salary before and before... but recently I am getting the impression, that in today's enterprise IT its more and more difficult to rely on your job as a source of satisfaction...