If you have read my previous post about caching, The (non)sense of caching, and have not been discouraged by it, I invite you to build your own cache. In this post we will build a simple cache implementation that refreshes its data automatically, using Java EE features.
I am still settling down from an awesome week in Sweden, where I went for the JFokus conference and subsequent speaker conference. Both were of epic proportions, and I would like to share my experience of giving a presentation there that I would not soon forget. My presentation on Evolutionary Algorithms titled “Making Darwin Proud: Coding Evolutionary Algorithms in Java” was scheduled for Tuesday, making it a very special session. Not only was it the 10th “birthday” of JFokus, it was also the 1st birthday of my son Olivier. It was a tough decision to speak at JFokus instead of being at home to celebrate my sons very first birthday, but as my wife said “he’s not going to remember you weren’t there on the specific day…we’ll celebrate extensively before you leave for Sweden” (I love my wife). However, I still wanted to do something special for my boy, which led me to come up with the ludicrous idea of starting out the presentation by asking the audience (some 450 developers) if they would sing Happy Birthday with me while I recorded it with my phone. They did, and it was awesome! I would like to use this opportunity to thank them from the bottom of my heart, because they made the day, and gave my wife, Olivier and me so much joy by doing this. The tweet that followed is one of the most retweeted and liked I’ve ever had (as well it should be!): https://twitter.com/BWknopper/status/697107401686675457 After our singing intro, I felt a connection with the audience I haven’t felt before (and I gave this talk a couple of times) which in turn led to one of the most fun and relaxed presentations I ever gave. The abstract of the presentation:
Recently I wanted to use the Tuckey UrlRewriteFilter. It is described as: A Java Web Filter for any compliant web application server, which allows you to rewrite URLs before they get to your code.
Both the JVM and keytool have problems dealing with keystores without a password. If you try to get a listing of the keystore it will think you didn't provide a password and output falsehoods:
A lot of bugs are in some way related to state. So that is what we will be talking about today. We will start off with a quote from Einstein: “Insanity: doing the same thing over and over again and expecting different results. ” Code should be consistent, calling the same function with the same input should return the same result during the whole life cycle of the object. Insanity and bugs will follow if this rule is violated. This sounds logical, but in practise it is quite easy to violate this principle. The main cause of this, is object state. This state is used in a lot of functions, and can thus affect the behaviour of our program at runtime. This principle can be even be seen in the most basic of examples (imagine the impact on a more complicated class...). Given the following class:
Tuesday we had our second ever "Vrolijke Framboos" (Dutch for Happy Raspberry) Java code challenge at JDriven and it was a blast! This year’s challenge was to create a REST service client that would play a number guessing game with the server. After setting up a session you would guess a number and the server would respond with either "lower", "higher" or "bingo". The goal was to guess as many numbers in the two minutes you’d be given. Given the name of the challenge you can probably guess that the target platform would be a Raspberry Pi!
When we construct an typed Array out of an existing List, we use the method
T toArray(T a). When an array with a lower size than the size of the List is passed as argument, this results in a new array being created. Take a look at the implementation of ArrayList here. Using the method with an incorrect sized array is inefficient. Using the
toArray method directly with a correctly sized array is therefore preferable.
I would like to show different ways of using Spring's
@Autowired annotation: Constructor, Method and Field autowiring.
The examples I show are all a form of
byType autowiring mode (
constructor autowiring mode is Analogous to
byType). Take a look at the Spring Reference guide for more information on the Autowiring modes.
As shown in a the post Nifty JUnit : Working with temporary files, it is possible to use
@Rule in a JUnit test, which is a Method level Rule. In this example I would like to show the variation of the
@ClassRule for a Class level Rule.
We have to deal with legacy code, even when we would like to use the best and newest technologies available. Imagine the new code is written with the newest technologies of the Spring Framework and the legacy code is not written in Spring at all. Then using Spring managed Beans in non-managed Spring objects is one of the patterns we have to deal with. The legacy code has non-managed Spring objects, while the code we want to reference to is a Spring managed Bean. How do we solve this problem?
So many men, so many minds. When we are implementing software for different customers we sometimes need to handle various requirements for the same project. For example Customer A needs SAML authentication and customer B needs LDAP authentication. With Spring Profiles (available from Spring 3.1) we are able to provide a way to segregate parts of our implemented application configuration. This blog will help us to make certain code or rather certain Spring beans only available for specific requirements. For example the example used in this blog can be used to activate the required authentication provider for the provider manager when using Spring Security. Profiles can be configured by annotations and/or by xml. Annotations @Component or @Configuration annotated beans can contain the annotation @Profile to only load them in a certain environment.
I get this question quite often and I struggled with it many times before: How do I work with temporary files in my JUnit testcases? I would like to explain two simple ways of working with temporary files in JUnit.