JUnit in your pocket

There are almost 2 weeks from the last post, but it seems that this end of year will be a very busy one, so I will have little time to write. I hope I’ll be back more active on the next year.
Now, getting away from this type of excuses and back to the topic.
Thanks to JavaRanch I had the opportunity to read the last Kent Beck’s book on JUnit: JUnit – Pocket Guide.
As the name states, it is indeed a pocket guide: 77 pages, from which almost 20 are about JUnit usage inside IDEs (if the editor would cut these full of images pages too and reduce a little bit the format, the book would enter your pocket without any problems [smile/]). Otherwise, the book contains a little of everything: history, reasoning behind creating and using JUnit, a short presentation of the framework architecture and implementation, reduced JUnit API comments and very few examples. Some short comments on possible extensions and that’s all. I think everything inside is in pocket suited format.
Concluding, I would say that JUnit – Pocket Guide is an (very) entry level reading for those wanting to have the first contact with JUnit. More infos are to be found on the JUnit site and other books.
Next reading: JUnit Recipes a book recommended everywhere and with great reviews.
Update: in the pocket review above I’ve forgot to pass the idea I loved the most:

[…]However, if I’m working by myself, I find it helpful to leave the last test broken at the end of the day. When I arrive in the morning, I know just what to do to get started: fix that test. That’s usually enough to get me started on my day

Advertisement

QDox, xjavadoc and the alike… maybe one more

Some time ago I was investigating the possibility to have a light in-memory model of java sources. My research has gone mainly to QDox and xjavadoc, passing also through commons attributes.
Unfortunately, after following the mailing list for a long time, I am unable to say that the support for JDK 1.5 will be available soon (or at least at a specific moment in the future – even if the developers are already taking into account this).
So, I get back a little bit and evaluated the problem some other way:

• how are they implementing these features?
• why are they implementing this way?
• which way should i go for?

Answering these will help me find (hopefully) the good way.

How are they implementing these features?

• QDox: has its own model that is able to keep information about 5 elements: java types, java classes, java fields, java methods and tags. So in order to support JDK 1.5 features, they will need (in big lines) to improve the java type to support generics and add a model class for annotations. Another interesting point of QDox is that it is using its custom java source lexer/parser written in flex and yacc (i guess). They will need also to enhance this too.
• xjavadoc: has its own model too. In big lines it supports the same elements as QDox does (which in fact represent their real working target). In the same direction, xjavadoc uses its own parser based on JavaCC. So, I would say that xjavadoc has to do the same enhancements as QDox.

Why are they implementing this way?

While the model used in both cases is very clear and I think that with the enhancement I was talking they will be stable for a long time, I am not very sure why both solutions have chosen to use custom parsers. I know that javadoc tool is memory expensive while working with large object graphs, I guess if it is used to parse only bunches of sources and than solve references in memory it would possibly be a viable solution. Here I would like to have some insights of the guys involved in QDox and xjavadoc

Which way should i go for?

I would say that imo QDox seems more alive than xjavadoc (even if the xdoclet guys are working hard). One solution would be to get involved into QDox dev and make/contribute with the enhancements. (But I don’t know if I have a place there as they are already many and I am not sure they are in need for my help). Another solution would be to reinvent half a wheel and go for a solution based only on javadoc parser. While I see some benefits in doing this (assuring the compatibility with the latest JDK available and independence for any custom parsers, and possible to offer access at the code level, without really parsing it), I think I must find out firstly the answer to the above question.

Update: there was an anonymous poster suggesting the solution with javadoc. I think if I choose this solution I must thank him [blink/].

Eclipse trick: Custom getter-setter [UPDATED]

The trick I have found for custom getters/setters in Eclipse seemed very nice.
I would like to add more on this: the prefix and suffix accepts a comma separated list of strings that will be ignored by the generator. Wow … very very neat.

… the best ORM in the world (on Gavin’s interview)

I just finished reading the Gavin King‘s interview published on Javafree.com.br. I am using Hibernate for quite a while and I must say I am very happy with it. I have even taken a look (not so deep) to the upcomming Hibernate3, but I still found myself unable to say:

The Hibernate3 core (currently in alpha) is the most powerful ORM engine in the world – and it will take a little while for others to catch up.

, when I know that

Um, traditionally, no, we did not pay that much attention – I was much more comfortable being guided by request from users, than by “what the other guys got”.

Even if Gavin and Hibernate have always had their fanatics(*) [smile/], I am wondering if

However, more recently, we have done some feature-by-feature competitive evaluations of the two leading commercial ORM solutions, just to make sure we didn’t miss anything.

was done the same way the Microsoft vs IBM solution comparison was done. I haven’t seen the results published anywhere and I am wondering which are those 2 leading solutions that have been compaired. I have seen the same statements coming from the TopLink team so I will not jump to a conclusion so quickly and I will wait to read at least the comparison results.
On the same direction I have found out that the guys/companies developing non-RDBMS solutions would have to leave their business:

How do you see alternatives to relational databases, like XML and OO databases, or Prevayler?
We don’t see them 😉

I will give credit to the [blink/] in the end of the sentence and hope that not every other solution will stop their existance and just jump into the RDBMS field immediately.
When SUN has announced the initiative to create a common spec out of JDO and EJB3 I was wondering which will be the future of JDO. Gavin’s opinion is

We don’t see any future for JDO.

, but I am thinking that this future will be the same for Hibernate 2 users as for JDO users. Gavin’s feelings about JDO have been expressed also on some other occasions. What is Craig Russell’s opinion on this?
Finally, I find myself asking if Gavin expressed his true feelings on these or rather it was a somehow furious interview?

Disclaimer: do not consider the bad meaning of fanatic word.

Eclipse trick: Custom getter-setter

I don’t want to challenge R.J. but I feel this trick is quite interesting.
During the last weeks I have found quite annoying to use the conventions of the projects I am contributing to, because they impose the usage of m_ and s_ notations and for a long time I have considered that this is a killer for the getter/setter generation in Eclipse.
But no, it is not: you can configure Eclipse to consider some prefixes and suffixes and these will be removed from the generated getters and setters.
Step by step:
– Window -> Preferences -> Java -> Code Style
– Variable type: Fields and add the m_ prefix
– Variable type: Static fields and add the s_ prefix (if you really use getters/setters for static fields [blink/].
Congrats again to the guys developing Eclipse!

AspectWerkz enters a new level

AspectWerkz guys (Alex Vasseur and Jonas Boner) have announced the 1.0 final version. I want to congratulate for the long way they have gone and wish them to keep up the good work!
Congrats!
You can read about the current features and release notes while you download it.

Old… but good

Here is an old link to a nice (good) list of Java – to – Relational solutions. Enjoy.

Concluding on project documentation

After a few time spent on this subject and a few posts on this, I think I have reached the conclusion moment. Shortly, my goals were:

• to find a documentation format easy for writting and enough configurable as regards the generated output
• to allow different output formats
• light/easy/few tools required

I have taken into account the following formats:

• html
• docbook
• xdoc
• wiki

Some thoughts on each of them (thoughts that finally pushed me to the current solution):

• html way too related to output presentation
• xdoc quite powerfull and not very very linked to presentation. It misses a few things: imbricated section levels, meta support.
• docbook very powerfull, but way too complex (from both points of view: writting and configuration of output)
• wiki interesting, but the output is too limitted and requires a heavy solution (servlet container, except you are using the Wiki Plugin for Eclipse)

Conclusion:

An enhanced xdoc format (overpassing the missing features presented above) and a couple of XSLs to transform it either to a final document or to put it in the format of one of the other above mentioned formats.

Somebody could argue that I have tried to reinvent the wheel, but this is not the truth. I have added to the xdoc format just a few more things:

• level attribute for section element
• indefinite section recursion
• meta child element of properties element … and that’s all

I have already written 2 XSLs that transform it to HTML and Wiki and both are under 100 lines (even if I am not an expert of XSL). I will write another one that will transform my custom xdoc to Forrest xdoc and/or Maven xdoc and so I can use this format to generate a full site. Having only XML and XSL files I can work with aproximatively whatever editor in the world (for the moment I prefer using JEdit) and I can trigger the transformation process with a 10 lines Ant build script.
In the next days I will start posting the custom xdoc DTD and an example, than the Wiki XSL (this is very intersting indeed) and the lite HTML transformer.
If you are interested or you have other suggestions for me just drop me a line.

All those NPEs

This weekend I have passed some time checking the code generated by dtoGen™. I have been trying to remove any possibility that a NPE would occur in the generated tool class. (for those not knowing about dtoGen I would recommend a quick read of the intro). I have had to check against NPEs for any instance forced convertor (something like model.getValue().intValue()). I have had to check against NPEs for collections, arrays, maps manipulation… and at a moment I got angry on these NPEs. Why should I check it and not the compiler? (hmmm wait a minute is this possible? would it be fesable? would it be really good?). I sat down for a moment and thought of this. How easy would life be without NPEs! But no, this is not true. The compiler should create check points for any instance variable access or for any instance method call. The code will grow over and over. This is not the last issue. What would it happen when a possible NPE occur? Just signal you? Ignore that piece of code? Wow… after object oriented programming we would begin the fuzzy programming era. I would go home and say: I wrote down today a program. There are many chances it will run. But also many chances it will go a path I don’t even imagine it can.
So, bye bye swearing NPEs. They are a good evil!