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?