The wonderful world of open source and Java...

This is I think the first blog entry in English, something we will be doing from time to time, after popular demand. Skipping various very googoomuckish topics (like the upcoming new logos), I will proceed to something ridiculously off topic

Having recently switched from working with .net, to working in a j2ee web application (mind it's not the first time I did it), I am... ehm... impressed. In a not very positive way. I'll explain with some "advice"...
Mind that we have a set of wonderful developers, and that I could make a funny list for .net too so this is not intended to start a flame war!

1) Choose free. It doesn't matter that the software might cost less than 10% of the annual cost of the developers' salaries. Choose free anytime you can. This means that you might choose a mediocre free IDE in favour of a very good free IDE, because the first promised to have UML support for free 2 months earlier. It doesn't matter that this UML support was so lacking that it was bordering to uselessness.

2)The test framework is your God. The God is always right. If you cannot make a unitary test for a 6 line method in less than 100 lines it's always a problem of the method. It doesn't matter that the framework 1) cannot test anything that has to do with the database, 2) cannot test anything that has to do with another public call of the class that contains the tested method, 3) needs at least 5 lines per test even if the original function is 1 line long.

3) The solution to the above problem is to add another layer to the application. This is what java means by n-tier. If you think about it, n-tier means nothing. Even if n is a natural, a 0-tier application is meaningless, and an 1-tier is an n-tier :P. Normal people use 2-4 tier. Java community by n means n->infinity. It's a number that has to start as big as possible, and whenever in doubt, it has to increase.

4) The perfect way to achieve this ->infinity is to add layers of classes that do something like this for every function of the layer below:
class Something
{...
insertSomething(Something something)
{ somethingLayerBelow.insertSomething(something); }
...
}
As you can guess, you can add an infinite number of layers like this .

5) Do unitary tests for the above layers(because you cannot really do tests for the complicated ones). Then be confident that the unitary tests showed you really that the application is bug-less.

6)Notice the notation? It could have been written like this:
class Something
{...
insert(Something value)
{ somethingLayerBelow.insert(value); }
...
}
Don't do it. It makes copy paste easier and takes less characters. Keyboards are made for a reason: type.

7) Having to change 12 files (written in java, various types of xml, sql and a couple of web notations) to add a simple page to edit a data table is a feature, not a bug. This has to be done manually. There is an evil variation of this, where it has to be done by a wizard that doesn't really work, and then you have to do complicated things in another 6 files. It is called the Oracle version.

8) WAR is good. .War files help you upload all these files together to a server. It was such a good idea that everybody copied it. It works even better when you have no ftp access on the server. Thus, every time you fix a broken link, you have to redeploy the whole application, recopy a gazillion of data and possibly even rebuild the database and pass 2 days fixing the differences. WAR creates jobs.

9) It is not paradoxical to be adamant about performing unit tests for 20 specific classes in a project that uses 60 more classes and around 400 untested scripts and xml files that can break after every refactoring.

10) Of course, apart from your gazillions of files, there are tons of packages to manage. To avoid dll (ehm jar) nightmare, assign the task to someone else, who's not even paid for this job, and start using his/her repository before every jar there gets a description and all its prerequisites are in the repository. If you do it after, you miss the excitement of having a production application that suddenly doesn't build because someone in the repository added an impossible prerequisite in the description of the jar you used. Or one of the other 787 jars in the dependency trees.