When to use log.isDebugEnabled?

One of the first coding-related question my partner asked me when I joined my current project: do you use log.isDebugEnabled()? This is a recurring question, and my answer is generally the same: “No.” Still, there is some nuance in this no. I will try to get to the point today and forget my usual digressions.

Continue reading When to use log.isDebugEnabled?

Better comparison of Java implementations

This post is history. Read the latest version.

 

I already posted a class to enable the comparison of Java method implementations. However, this was a draft method rather than a true solution.

Today, I come back with a(n almost) valid solution. You can get it on my Github repository: labs-java, implementation-comparer branch.

Basically, it will be able to compare several implementations of any class within its context, rather than the previous solution which forced you to rewrite the methods within the comparer.

Let us imagine you have a Foo class with a bar(String arg), but you suspect this method can be written in a better and more efficient way, but you want to ensure both methods return the same results and make sure which methods is the most efficient.

You will have to write the variants for your method, and suffix them with an incremental index (bar1(String arg), bar2(String arg), …). Then, you will call the implementation comparer with some arguments you wish to test:

This will output something like this:

The time checks are performed only if the info log level is above INFO, and the result comparison displays the details only on debug level, but the compare method returns true if all methods return the same result, and false otherwise.

This comparer can be really useful when you are refactoring or even included in unit testing if you find a use for it.

For more details, you can have a look at the class itself. It is really not that complicated and I made it an obligation to have documented code nonetheless.

As a reminder, you can also have a look at my my previous draft version, which came with more explanations. The main principle remains the same, only with more freedom.

And if you need help, you can always ask below, as I will not go further into details right now.

For the logging of tables, I used Alcibiade’s asciiart library.

All this just in preparation of my next post… And yet, I am quite satisfied with myself and feels this will come in handy next time I refactor…

Comparing multiple directories (Java)

Several tools enable the recursive comparison of directories, but most of them allow for the comparison of only two directories (like my favorite, WinMerge). KDiff3 goes as far as comparing three files or directories.

As for me, I needed to compare up to five directories. As a consequence, I implemented my own algorithm. Read for more information.
Continue reading Comparing multiple directories (Java)

Localization in Java

Localization, or internationalization, is important in most languages. What good is an application if it is restricted to your own country because you speak a far from widespread language? And as most languages, Java offers a mechanism to implement it quite easily. I will review here the basics, using Daily Tasks as an example.
Continue reading Localization in Java

Daily task manager

Have you ever had tasks you had to perform each morning on getting at your desk? I do. Since I reboot every day, I first used a text file I added to the All programs > Startup menu of my Windows, but it was not satisfactory, as the text file gets lost behind all my other windows anyway (IDEs, e-mails, … You get the idea.).

So, I finally took the time to program the task manager I wanted: something compact, which will not close until I have not checked all tasks, and which remains on top of other windows. Here is what I did.

Continue reading Daily task manager

My new favorite log4j conversion pattern

log4j is a powerful logging utility for the Java programmers. Until now, I let other developers configure it. However, I was not satisfied with the configuration in my current project and took a deeper look.

The log4j pattern

Our logs were cumbersome, always displaying the full package, which is not always interesting. Dates varied from a log to another. So I looked for a standard conversion pattern I could use whenever I have to log something with log4j, and after some diving in the documentation, here is what I came up with:

An example of output

Some explanation

  • %d{ISO8601} – displays the date and time in the ISO format (see earlier post about this norm).
  • %-5p – the log level (such as DEBUG, INFO, WARN, …), formatted to occupy five columns (I like when things keep in line).
  • %t – the name of the thread logging this line.
  • %c{1} – the name of the class calling the logger (the {1} argument is there to restrict the number of packages displayed; {2} would display one package level before the class name, {3} would display two package levels, … and %c without the brackets would display the full package and class names).
  • %M – the method.
  • %L – the line number.
  • %m – the message to log.
  • %n – begin a new line.

There you are.

Compare implementations of a method in Java

This post is history. Read the latest version.

 

Often at work, I look at the code from the legacy of my project and wonder: was this coded this way for a purpose? Is it optimization? And doubt is upon me. My way seems better, but what if it is not? Well, let us just have a quick comparison!

In this article, I will give you the comparison class I created for myself. Quite simple, focused on time (not the best indicator, maybe, but a clue nonetheless). You just have to supply two methods, configure how you want to run it, and run it. Interested?
Continue reading Compare implementations of a method in Java

How to implode iterables in Java

The PHP implode function can be quite useful, but no equivalent exist in Java that I know of. Luckily, you can quite easily implement your own.

Implode arrays

This is actually pretty straightforward. Here is what you need to do:

Yeah, I declared this array so that it can contain just any kind of objects. No problem when passing StringBuilder.append(Object), since it will use String.valueOf(Object), returning either the null string if object is null, or the .toString() of the instance.

But arrays in PHP behave more like lists, so why not extend this method to Java Lists?

Implode lists

Using an Iterator is great. It avoids using the .size() to count the elements of the list, and does not require an explicit loop with the .get(int).

Plus, since Iterator applies to all collections, you can extend the method…

Implode collections

Alright, now it works for lists and sets. Just remember the order of elements is not garanteed if you use this method with a set.

[2013/01/16: made methods null safe]

Removing entries from a Map in Java

Today, I ran through some code iterating over a Java map to remove outdated values. I found the way it was done utterly disgusting. Yet, thinking it through, I would probably have done it the same way a couple of years ago.

As a consequence, I thought it would be a good idea to share the solution I now use.
Continue reading Removing entries from a Map in Java

Unit-testing a REST-client Spring bean

I guess a bit of context is required here: I had to implement a Spring bean which should be able to call a distant REST service, with high availability constraints. One of them was that even if distant service was down, the bean should return a result and not an Exception.

Of course, I wanted to ensure my bean behaved the right way, no matter what future evolutions would bring. Unit-testing then. Since it is a Spring bean, using Spring test. But then an awful question: how do I simulate a call to a distant servlet in a Sprint test context?

The REST-client bean

Something very basic, using Apache’s httpclient to retrieve a stream. See the example:

Here the Maven dependency for httpclient:

And finally the bean initialization in the Spring application context:

From the real thing to the unit-tests

Of course, since the URL is set in the Spring context, it easy to map to another one in the test context. Yet, I must have something listening to the test URL.

Something inside my test context, since I do not want to depend onto another server. Using Spring remoting? Start an embedded Jetty? Those seemed possible, but uselessly complicated.

For the first time, I asked for Stackoverflow’s help, and it came to me with the hints I needed to google out the pieces I was missing.

Unit-testing using a light embedded application server

I was recommended to use javax.xml.ws.Endpoint with a JAX-RS annotated-class. The second part was what I aimed at from the beginning, using Jersey. However, Endpointquickly proved designed for use with SOAP services, not REST.

I kept searching for something similar and found an example of how to use Jersey classes with a Grizzly embedded server. It is acutally dead simple.

Write a fake REST service

There are a-many tutorials about Jersey, I will let you find the one fit for you if need be.

Here is my fake service, yet. As I wanted to test the behaviour of my bean with several HTTP error status codes (401 if my request is incorrect, 404 if the distant service is down, 500 if I break it down, …), I decided that the passed parameter would be parsed to cause this status code if beginning with 10, 20, 30, 40 or 50. If it is any use to you, you are welcome to copy it (though it is quite basic, but quite enough for my unit-tests).

Publish to a server

How difficult can it be to write a server? Very little, actually, if you know which server to call. I chose Grizzly. See below.

As for publication to the server, the highlighted line does most of the work.

 Start the server in the Spring context

Basically, all you have to do is to is set the bean with a URL and call the start() method. Translated for your context, it looks like the following:

 Almost done!

Now, when your Spring test context starts, a Grizzly server is started and listens on http://127.0.0.1:8088

Plus, a webservice is deployed onto it. The Path annotation tells us it will be made available at http://127.0.0.1:8088/hello

OK, so we just have to initialize our to-be-tested REST-client bean with the correct URL for the service:

You’re good to go and test all the cases you want to!

Which dependencies should I use?

Right, I almost forgot I myself had some troubles figuring out which dependencies to use…

You might want to declare some repositories too:

 And what about SOAP?

Well, for SOAP, you can apply quite alike-looking practices, using javax.xml.ws.Endpoint instead of a Grizzly server, and the J2EE JAX-WS annotations instead of Jersey.