More to learn!

Its amazing how 6 months off working can affect you. Traveling thru Asia was excellent, but I didn't really think much, it was more like 24/7 experiencing. Towards the end of the trip I felt like I needed to exercise my brain!

I have been revising so much Java material recently (its all coming back), I need to re-learn so many things! I want to be on top of my game for interviews, but I haven't got anything to practice with, so I'm having to research and make my own dummy projects. Oh well, I'm sure I'll be getting paid for doing this eventually.

I had an interview today where they asked me lots of technical questions to gauge my level - fair enough. Unfortunately I was rusty in a few areas, so I am going to write another essay on the topics I should know more about.

Singletons:

A Singleton is a design pattern designed to guarantee only a single instance of an object. What do you use them for? They are good for objects used in many areas of a system - cross cutting objects. Also used for object factories, facade objects, state objects. Yes I do know what a singleton is.

Whats the technique in Java again? urg... well I can now tell you: nutshell is that you have a private constructor (so it cant be instantiated) and a static variable (to hold the single instance), then a static method which can instantiate (if needed) and return the singleton. In multi threaded objects, you need to be very careful to ensure that 2 objects can't be created due to synchronous access.

While I was reviewing this pattern, I found some interesting Java issues with the compiler optimization of the double locking pattern. This pattern is a nice way to not need to synch on every singleton request, eg:

public Object getSingletonObject() {

if(obj == null) { //lock1 syncronized (this) { if(obj == null) //lock2 obj = new Object(); } }

}

The idea here is that the method only synch's once - on first request. Every other request for the singleton doesn't (need to) synch. Unfortunately it doesnt work (until java 5) as a second call during the synch block by another thread might try the first lock and find non null, half instantiated object. The compiler reordering means that you can't guarantee the behavior without the whole method being synched. Or by ensuring java 5+ environments and marking the singleton field as volatile. This technique compiles and may appear to work in earlier JDKs, but isn't threadsafe.


Spring FactoryBean:

(quoting the FactoryBean’s JavaDoc here)
an ‘Interface to be implemented by objects used within a BeanFactory that are themselves factories. If a bean implements this interface, it is used as a factory, not directly as a bean.’

So a Spring FactoryBean is a special bean, it has implemented the FactoryBean interface. This special interface marks the bean as a factory, to provide generation of objects (or a singleton) and inject them into the application context. So it is a special bean in that its methods are not directly accessible, but it provides access to (other) bean(s) indirectly - it is a factory and its getObject() method passes back whatever the factory dispenses.. It can be a singleton or regular factory.

This forms a vital part of creation and injection of objects into the context. The Spring packages have many default implementations of factories and they all implement this interface.