Toplink vs hibernate

I still remember the excitement I felt when I started working on Toplink. It was early 2000. Before that, I was working mainly in visual c++. Visual c++ community never had this type of tool; I even thought that such a tool is impossible. During that time, I attended toplink training, and was amazed to know that it can store/retrieve practically any object model into a database, with out any sql. It was not just I, every body in the training session was like that. It was like a dream come true to all of us. Over the period toplink worked very well for us, major productivity gains were there, you know all the regular ORM benefit stuff…

Though I am a fan of toplink, after looking at Hibernate, looks like Hibernate is a better framework than toplink, and for very good reasons.
Obviously, Hibernate is free (as in free beer?), has better user base, community, articles, resources, books and momentum.
Hibernate API is lot cleaner than Toplink API. Toplink API, naming conventions are unintuitive in many areas (am I picky on this?).
The most problematic feature in toplink is it is practically impossible to get away from its cache. In toplink, cache is a necessary evil, there is no simple way to bypass cache to go to db. Documentation says few options to set on its descriptor, but none of them work well. In Hibernate cache is optional, if we want we can have it, it always goes to database by default.

We are not going to switch to hibernate anyway.

orm tricks ..

Books are in a Library or Library has books or is it both?

Is it silly? but for a developer doing object relational mapping this could be interesting.
Suppose we model this relationship as bidirectional, i.e. Book *<---->1 Library, then, when we load/send a book from database, we load book’s library (since book references library), and all the books in that library (since library refers books).
If we model this relation as a unidirectional--Library has Books (Library 1 -->* Book), then, since book doesn’t refer to library, we don’t have the previous problem of loading and serializing all the books. However, our book does not know which library it came from. If we need to load library, we still end up loading all the books in the library.
Suppose we model this relation as Books are in library, i.e. Book *-->1 Library, then, when we load book we get book’s library, but since library does not have books we don’t end up reading all the books; When we load library we load only library. I choose option Books are in library (Book *-->1 Library), it’s me.
Object relationships and OR Mapping are very interesting, if we don’t model them properly, reading/sending a small object may result in reading a whole load of things that we are not intended to read/send. Technique is, model relationships to the right granularity to match our object reading and writing patterns. In many places, I find turning a container into a marker, as we did above, to be very helpful in getting to right object granularity. Then, what about finding books in a library? If need be, we can always find books in a library by query: get all books whose library is x.
How should we model relation between Book and book pages, Pages are in book or Book has pages or both?

Great lens

If you want a cheap and excellent lens for canon rebel, Canon EF 50mm f/1.8 II is the one to buy.
It is very cheap(<$70.00), fast, and pictures are sharp (see six-packistan). 

Why Thread implements Runnable?

I have this questions for many years, why Thread implemets Runnable?

We implement Runnable, if we want our method (task) to be called from a new thread or a special thread. Then we do some thing like below.

public void doTaskInRunnable() {
Runnable r = new Runnable() {
public void run() {
task();
}
};

// to make it tarket of a new thread.
Thread thread = new Thread(r);
thread.start();
// or to make our task run from a sp thread.
SwingUtilities.invokeLater(r);
}

If we use Thread instead of Runnable above code becomes

public void doTaskInRunnable() {
Thread r = new Thread() {
public void run() {
task();
}
};
// Reason 1 : to make it tarket of a new thread.
Thread thread = new Thread(r);
thread.start();
// or Reason 2 : to make our task run from a sp thread.
SwingUtilities.invokeLater(r);
}

Making a Thread target of another new Thread is plain stupid, why create a new thread and call it from another at all, in the above code at Reason1 we can as well call r.start().
Making a Thread target of a special thread is confusing, why a thread is running in another thread.
Until java 5, if we use Thread in place of Runnable, we have a memory leak. In the code above thread r is never started--it's run is called from another thread but never started, until java 5 ThreadGroup used to keep track of all un-started threads and r is never released.

Using Thread in place of Runnable is ugly, then why Thread implements Runnable? Is it because they have same method named run with same signature?

Spring, just another hype?

A book challenging a platform and developing an open source project to prove its point is unprecedented. That’s how Spring is born, from the ideas of (its manifesto) book "J2EE with out ejb". Spring’s alternative to ejb is an aspect oriented and POJO based inversion of control or dependency injection (IOC/DI) container, which integrates with other enterprise ingredients--orm tools, transaction services, custom protocols etc--and also provides client interfaces to Spring. While the ingredients, at least orm tools, are not new, integrating them together to build a toolset is different. IOC, DI, POJOs and hype make me take a closer look at Spring.

Dependency injection, that too for POJOs (i.e. without no explicit interfaces) is good--less burden on lazy developers, we don’t need to worry about building objects or learning new APIs. However, objects can have many possible lifecycles, can Spring really inject dependencies in all cases?
Spring documents limitations in some cases:

• on lifecycle mismatch it says "There is however a problem when the bean lifecycles are different. Consider a singleton bean A which needs to use a non-singleton (prototype) bean B, perhaps on each method invocation on A." and suggests to forgo POJO ness get it,
• warns on prototype lifecycle by saying "Spring cannot manage the complete lifecycle of a non-singleton/prototype bean".
• There are many other limitations too: sharing a prototype (state-full) object across multiple objects, composing object graph of non-singletons with circular references among others, temporal objects (objects with time to live) etc are not possible in Spring. Spring barely supports non-singleton objects, and justifies can’t support or missing features as "they are not common", "not needed", or "heavy weight".

Non-singletons, state full objects, objects with circular dependencies are not uncommon.
Containers have a smell in them, their lookup services are very plain, e.g. Spring bean-factory looks up objects based on their id. We are used to factories or registries that have meaning full lookups and classifiers, our lookups have methods like get a pricer for a product type and region, or get a data access object for currencies etc. and a lot more magic is possible in our localized factories/lookup utilities.
Whatever elegance gained in dependency injection is lost by lack of rich object composition and vanilla object classifications of spring. Managing singletons is not a big deal, perhaps, dependency injection is just a good idea only.

So can, Spring, "torchbearer of anti ejb", replace ejb? Yes and no.
Transactional ejbesque services follow a pattern of business service depending on an orm tool and together participating in transactions. In these scenarios rarely state-full services are needed, at the maximum business façade may be a state-full service, they don’t have lifecycle mismatch problems. Spring integrates well with almost all persistence solutions, and its declarative transactions work inside and outside a container.
Declarative transactions are part of the ejb story only; remoting or distribution support is another important feature in ejb. Spring's remoting/distribution is through custom protocols (non rmi-iiop) --hessian, burlap,httpinvoker, these protocols have serialization and user/transaction context propagation limitations.
Even with problems in dependency injection and incomplete remoting, spring framework accomplishes what very few contemporary frameworks are able to do--declarative transactions inside or outside container and of course lot of hype.

untitlable image 

Turn turn (Rangula ratnam)

I was playing with shutter speed at a local mall.

turn turn turn 

why python?

I experimented with Python few times. It looked interesting, but turned off by it’s odd indentation, lack of IDEs and my inability to find right area (application) to use. I felt it is a stronger glue scripting language than perl and weeker programming language than java.

Recently, I loaded Linux on my home desktop and wondered what is the language of choice for gnome applications: to my surprise I found it to be Python. Many gnome UI applets and games are developed in Python.

• its simplicity, which is not as barbaric as C/C++ , a seasoned programmer can learn in a week.
• great interoperability with native gtk libraries, unlike java.
• and great glade UI designer, not there in java world.

are making python popular on linux. Perhaps, a good IDE(?) and a database independent db access API like ODBC/JDBC, can turn it into a true enterprise application language.

Check out diveintopython, PyGTK, Guido van Rossum's interview, Bruce Eckel's python zen, and his case for strong testing to offset weak typing.