Spring MVC request parameter conversion with minimal configuration

I’ve been playing around with Spring Web MVC a bit and was looking for something similar to Jersey’s Parameter Classes that would provide conversion to custom types. I liked how with Jersey, you could encapsulate the conversion logic in a single class and have that reused across multiple methods with minimal configuration.

Here’s how I achieved a similar result in Spring Web MVC. (Note: the following examples were done with Spring 3.2.1)


Java: final, finally and finalize

One of the most popular Java interview “screener” questions is often, “What is the difference between final, finally and finalize?” In fact, it occurs so much that one should probably have the answer memorized. But knowing when to use these features is better than just knowing what they mean.


Java, Weak References and WeakHashMap

Most any Java Developer will be familiar with the concepts of references, as in pass-by-reference vs. pass-by-value. (Pointers, now that’s another thing…)

When calling methods, primitive data types are passed by value, while objects and arrays are passed by reference. This means when you call a method with an object as a parameter, you are merely providing that method a way to access/manipulate the same object via a reference; no copy is made. Contrast that with primitives: When calling a method that requires them, a copy of that value is put on the call stack before invoking the method.

In that way, references are somewhat like pointers, though they obviously cannot be manipulated by pointer arithmetic. But what about weak references? What are they, and how do they contrast with strong references?


Google App Engine for Java: First thoughts


When Google launched App Engine about one year ago, many were excited about their expected move into the cloud computing space, but at the same time, dismayed that it only supported Python, a language seemingly favoured at the Mountain View-headquartered company.

However, Google was adamant that they would begin supporting new languages and began taking requests on their issue tracker for what language to support next. So, it was no surprise that support for Java was announced last week as part of an “Early Look” at the feature.


Handling mutable fields in Java

In Java, a mutable object is one whose state can be altered after it has been instantiated. An immutable object is one whose state is fixed after instantiation; that is, the data represented by the object cannot be changed in that object. Perhaps the most well-known immutable type is the built in String class; while there are methods on the String class that seemingly alter its state (such as toUpperCase() and trim()), in actuality these methods return a new String object if changes had to be made. In this article I’ll discuss how mutability will affect how you expose private fields in objects.

Pop Quiz

Consider the following code fragment. We create a MapContainer object, and then get the contained map, which is guaranteed to have a certain value associated with the key “today”. We then alter the value associated with this key, using our local reference to returned map. We then query the MapContainer object and get the contained map again. What is the value associated with the key “today” in this map?

final MapContainer mapContainer = new MapContainer();
final Map<String, String> map = mapContainer.getKeyValuePairs();

final String today = map.get("today");
assert null != today;
System.out.println(today);  // Returns the current date-time.

// Change the value using our local reference.
map.put("today", "tomorrow");

final Map<String, String> mapAgain = mapContainer.getKeyValuePairs();
System.out.println(mapAgain.get("today")); // What is output?

Don’t waste too much time on this problem, as it’s a trick question. The answer actually depends on the implementation of MapContainer. Depending on how it’s implemented, the second output could be unchanged from the first or be changed to the new value of “tomorrow”.


Extracting X509 Extensions from a CSR using the Bouncy Castle APIs

The Bouncy Castle Cryptography Java APIs are an excellent set of APIs that act as a provider for JCE and JCA. Additionally, they take care of the mundane and tedious (some would say overly complicated) details involved in reading and creating the data structures associated with the X.500 and PKCS standards. (The APIs are also available in C#, for .NET developers out there)

One thing they handle well is the concept of certificate extensions. X.509 v3 certificates introduced the concept of these extensions, which are basically additional (potentially optional) fields containing information not contained in the older original X.509 specifications. Each extension is specified by an OID (Object Identifier); a good list of these extensions is available.

While it’s easy to read these extensions from an existing X.509 v3 certificate using the Bouncy Castle APIs it is a bit more involved to read these extensions from a Certificate Signing Request, or CSR; this is the data structure that is sent to a CA to request a certificate. The CA then reads the data from this and creates a signed certificate issued to the requester. In this guide I’ll present a brief way to extract X.509 extensions request from a CSR so that they may be included in the resulting issued certificate.