At the end of march 2012 I was attending a Spring 3 Core Training in Cracow which was organised by the SpringSource. Because I am more of a pure Java EE world type and mainly develop in this area, I wanted to improve my knowledge about Spring. Sure, I’ve used Spring, worked with it but never felt really comfortable with it. I was missing the big picture and so that’s why I decided to go to this training.
I must admit – I’m neither very experienced in the field of user interfaces nor really familiarised with all that JavaScript, jQuery stuff. I was always thinking of myself more as a service layer guy.
Nevertheless, I wanted to improve my knowledge, so I decided to learn more about something called DWR (Direct Web Remoting). I’ve heard about it few years ago but never actually passed the “yeah, I’ve heard about it” stage.
This will be very basic introduction, so I’m afraid that for those of you who know what DWR is and used it, this article won’t introduce nothing new.
Sometimes you need to audit or profile your Java application. The easiest but most intrusive way to do this is to do a bunch of System.out.printlns (which is obviously bad) or to use loggers. After adding a lot of logging statements, your application becomes cluttered with unnecessary boilerplate code.
Profiling, instrumentation or method measuring are great examples of cross-cutting concerns that might be nicely solved using AOP (Aspect Oriented Programming.) Basically, it allows you to invoke a certain action upon some defined conditions without the need for changing the instrumented code. The process of applying the aspects to your code is called weaving.
There are three types of weaving (not every AOP implementation must support all of them):
.class file),As a side note, you can create your own simple runtime weaving AOP tool by using Java Agents that are invoked before any other written source code method (in the matter of fact, agent methods are invoked even before the static void main(String[] args) method of your Java class.)
I see a lot of people saying that:
“there is only one instance of servlet per application”.
Surely it gives you some information and knowing this will save you from a lot of strange, unexpected errors. However, the above statement is not very accurate and precise. It’s useful to know what is the actual contract between the web container and developer.
Moreover, a lot of questions arise because of the multi-threading issues, so let me sum this up backing my words with Servlet 3.0 Maintenance Release specification:
Assuming we’re working in a non-distributed environment, there is only one servlet instance per definition:
2.2 Number of Instances
For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration.
So, it’s not allowed for the container to pool servlet instances. There is a strict requirement that there is only one instance per definition. This per definition part is also important because if you define two servlets with different names but referring to the same class, you’ll end with different instances of this servlet:
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>com.myservlet.MyServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>servlet2</servlet-namesss>
<servlet-class>com.myservlet.MyServlet</servlet-class>
</servlet>
However, the number of servlet instances can also be affected by implementing deprecated SingleThreadModel. This interface is supposed to ensure that only one Thread can access the Servlet at a given time. Therefore, it might do so by serializing requests or by pooling multiple servlet instances:
2.2 Number of Instances
However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
Finally, if you mark your web application as a distributed application (<distributable /> sub-element of the <web-app> in web.xml) and you will implement depreciated SingleThreadModel than you can end with a pool of servlet instances per definition in each of the JVM of your distributed environment:
2.2 Number of Instances
However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each JVM of the container.
As you can see the answer “there is only one servlet instance” is not very precise. It gives you an important information regarding multi-threading, but it’s not 100% complete and precise.
After one of the Ubuntu 11.10 updates I was affected by some really weird colors in the embedded flash player. Basically, every movie looked similar to the one below (notice the dominance of the bluish color):
The solution is to disable hardware acceleration in Flash Player settings (RMB -> Settings) just as shown here:
After unchecking this option and refreshing the page all videos were back to normal:
I’m not sure if I even want to know why one update could mess up so bad with the Flash Player. In fact, I’m pretty sure that the Flash Player is one of the best way to crash your Ubuntu box. In fact on my Dell Vostro 3555 it randomly restarts the X Window Server… sigh.
Nevertheless, the world has been saved one more time.
When you write your unit tests you must use some kind of assertions. I think that most of you will agree with me on that the asserts that comes with the JUnit aren’t the easiest and most readable ones.
So, some time ago I started to use a Hamcrest matcher library. It was a great progress, as I was able to move away from JUnit’s unintuitive: assertEquals(11.0, actual). I mean, if you try to read it out loud it doesn’t seem very logical:
“assert equals 11 is actual“,
“assert equals 11 as actual“?.
Moreover, the expected value is the first argument and the actual one is the latter which also makes it harder to understand.
And here comes the *Hamcrest* matcher which brings a fluent API consisting of a lot of useful methods. So, right now you can write: assertThat(actual, is(11.0)). This is much more readable as it stands for:
“Assert that actual is 11.0″.
No magic here, everything is understandable and you don’t have to think which parameter is the expected and which is the actual one.
FEST Fluent Assertions brings very similar features to the table but it takes quite different approach.
In Hamcrest you usually use the one-line per one assert approach. It means that if you want to check if myVal is in range between 4 and 6, you would need to write two assertions (sure, you can always write your own matcher that will do it in one line, but that’s not the point in this case):
assertThat(myVal, is(greaterThan(4));
assertThat(myVal, is(lessThan(6));
FEST Fluent Assertions uses the chain method invocation to do the same thing, so in FEST-like approach you’d rather write:
assertThat(myVal).isGreaterThan(4).isLessThan(6);
You can still read it very naturally and it saved some writing.
There are some more differences between Hamcrest and FEST Fluent Assertions. Some of them are more important, like differences in writing your own matchers and/or conditions.
Others are less important, like the number of static imports: lots in Hamcrest, only one in FEST Fluent Assertions. However, this Hamcrest‘s disadvantage, can be easily solved using type import static or using the Eclipse support as described in my previous post
There is no, obvious choice between Hamcrest and FEST Fluent Assertions. Both of them give you a very nice and elastic fluent assertions mechanism and which one you choose depends on team, your programming habits or some particular requirements. Either it will be Hamcrest or FEST Fluent Assertions, it will definitely be better than the assertions that come out-of-the-box with JUnit.
I think that the most important fact here is that you really should use easy to read matchers library. It makes not only the code more obvious for your team, easier to maintain (it’s worth emphasizing that your test code is also a part of your project – it needs to be maintained!) but in some situations it even allows you to show some test cases to the business people with the domain knowledge you need. It allows to reduce domain understanding problems.
Moving even further, if you plan to use Scala (or any other JVM language which allows you to omit spaces or parentheses in method invocations), your code can be much more like a DSL (Domain Specific Language): assertThat actual isEqualTo 11.0. It’s really worth trying it out.
You can read about differences between Hamcrest and FEST Fluent Assertions in more details on Sam Lewis’ blog.
If you’re using Eclipse and working with a class with a lot of static members, you might be affected by the problem of lack of content assist and automatic import for such members. Let’s say you’re using a Hamcrest matchers; you need a is(), notNullValue(), hasEntry() and so on (there are plenty of those). You don’t want to type Matchers.hasEntry() every time you use it in your code. Hey, that’s not why the fluent API was invented in the first place!
So, instead you do a static import which is available since Java 5:
import static org.hamcrest.Matchers.*;
Ok, you needed to type it by yourself, but still, now you can use just hasEntry() and everything works smoothly! But then, after some time, you do the Organize import magic (ctrl + shift + o) which automatically replaces your wildcard import static with concrete import static members, so you end up with:
import static org.hamcrest.Matchers.hasEntry;
Later on, if you want to use another matcher, e.g. notNullValue() you need once again type the import statement by yourself. That’s ugly, time waste manufacture which we should get rid off!
Luckily, there is an Eclipse setting which allows you to add some specific static members or whole types into the regular content assist (ctrl + space) without writing any import statement by yourself.
To set this, just go to: Window -> Preferences and then under Java -> Editor -> Content Assist -> Favorites add a Type (all static members within the given type will be added) or Member (just the particular static will be added):
From now on, all defined members and types will be available when you hit the ctrl + space. Organize imports will never again be your enemy! ;-)
If you’re interested in getting some basic information about Git, surely you already know about the Git Community Book – it’s undoubtedly a source of great knowledge. However, if you prefer the visual presentation and want to listen about the Git, I will highly recommend Scott Chacon’s “Introduction to Git”. It is great, compact and fast-paced talk about the basics of Git.
So, either you know nothing about Git or you already know something and just want to summarize your knowledge – I would highly recommend you to spend this 1,5 h on watching this video.
By the way, in this video Scott showed pretty nice feature of aliasing. Despite that sometimes it might be confusing for others what magic is your alias doing, it can be very helpful in some cases (e.g. to save you some time typing long commands):
git config --global alias.lol "log --oneline --graph --decorate"
This command creates a lol alias for git, so invoking git lol will invoke the above log ... command.
The Git learning curve is steep, but after working with it for just a few days – I already like it :-)
I’m currently under the process of moving all my workplace repositories from SVN to Git (configured to work with Gerrit). As a side not, I already found it to be a great tool for code review, line-precise commenting of the artifacts and for reviewing new employees code before pushing the changes to the repository.
But, back to my point. Recently I’ve stumbled upon a problem with commiting an empty directory in Git. If the directory consists of some files and you stage those files, the directory will be commited automatically. However, if the directory is empty, you cannot commit it.
It’s very reasonable way of thinking, but it also creates a few problems e.g. with Eclipse which requires you to use some Maven defined directories (src/test, src/java, etc.). More precisely, if you don’t have e.g. src/test/resources directory, it will throw an ugly project-wide error at your face.
The solution, can be found on StackOverflow, so basically all you need to do is provide a .gitignore file which forbids content other than the .gitignore file itself. However, in my case I ended up with putting a README file which describes why it’s there and that it should be removed as first real resource will be uploaded.
I found it more informative for other team members than an empty .gitignore file.
Sometimes you might be struggling with such error shown, e.g. in Eclipse:
The method …… must override a superclass method.
If this error is shown in the line when you have your interface method implementation with @Override annotation, it most probably means that you’re using JDK 5 instead of JDK 6.
In Java 5, the @Override annotation might be applied only to the methods overriding superclass ones. Since Java 6 you can use the @Override annotation also with the methods that implements the interface ones.
Therefore, if you see such error, either change the JDK to JDK 6 (i.e. check your Eclipse workspace or project preferences) or, if you need to be compatible with JDK 5, remove the @Override annotations from interface implementation methods.
Simple thing but it might make you swear ;-)
