@pcjuzer

Recently I looked through some JUnit 3.8 - JUnit 4 stuffs. Here are two useful readings in the subject: First is at IBM , other is on DevX . JUnit 4.X is basically direct improvement of JUnit 3.X with exploiting new features of JDK5. Current version is 4.4 and it can be downloaded from www.junit.org . What have been changed? It needs (surprisingly) at least Java 5. Package has been changed from junit.framework to org.junit . Using @Test annotations instead of naming conventions. Methods must be public with void return type and they shouldn't have parameters. If we don't comply with these we would expect the following runtime exceptions: java.lang.Exception: Method xxx should have no parameters java.lang.Exception: Method xxx should be void Using static import: import static org.junit.Assert.assertEquals; We can write instead of Assert.assertEquals(...); a sorter assertEquals(...); . (Of course we can use static import with JUnit 3.8 if we have Java 5.) Extending TestCase

Let's have a look round in the world of logging. There is a glorious article in the Wikipedia about fundamental concepts of logging. Two (or rather three) competitors are log4j, java logging API == java.util.logging == JUL == JSR47 and Java Commons Logging == JCL. The latter is not a real logging framework, just an adapter which quests for the available framework in runtime and uses it. It can be helpful when we don't want to wrap some modul to log4j, JUL or anything, however, it has disadvantages regarding efficiency and functionality. See this article about it: Think again before adopting the commons-logging API Here is an opinion about differences between log4j and JUL . I've read it a long time ago and deeply agree with it with the supplement, that because of the continuous inconveniences I hate Java Logging API. (The author of the former article, Ceki Gülcü is the founder of log4j. He has a blog where he writes engaging things. For an example, mentions presentation

This post is the translation of the writing (Hungarian) from my other blog with the identical title. In the recent months I had the pleasure to get acquainted with Wicket and JSF which are both servlet-based web technology frameworks with identical position and purpose. A Wicket presentation was also organized by Hungarian Javafórum guys at the summer, but unfortunately, I couldn't attend on it. JSF is part of the J2EE standard, Wicket is a Sourceforge-project which has joined to the Apache Foundation some months ago. Wicket means the implementation itself, while JSF is just a specification with a reference implementation and some real implementations. I met Tomahawk among real implementations, which is also related to Apache. Wicket uses HTML markup with wicket tags which are replaced to real HTML components in rendering time on the server-side. (Similar to Dojo with the difference, that Dojo replaces components on the client side.) JSF is taglib-based. We used Facelets w

I have been writing a blog about Java programming and software technology since 2005. Originally, main purpose of these postings was to ingrain my own thoughts and experiences for myself, but recently I realized that 5 to 10 readers visit these pages per day. Some of these hits come from static links and the more from Google search result pages. Unfortunately, that blog is in Hungarian which is my mother language, so, as I guess, some people finally don't get what they are looking for. So, I start another one in English to be able to share thoughts with more people, and not least, to improve my English composition skills. :)