Hi Steve,
Could you please either change your displayed name to "Steve Comnenus" (or S Comnenus) or start signing your posts as Manuel? My poor little brain cant handle the names being different.
I have no idea who I am talking to. You can change your displayed name
here.
could you elaborate on your thoughts regarding sockets and threads?
Hmmm, I am not quite sure of what you are asking, but I will try to answer based on what I think the question is. If I am answering the wrong question, please just ask it again (hopefully slightly differently).
The reason I mentioned Sockets in my response above is that it is very rare for an SCJD candidate to start their own threads if they are building an RMI solution. If you search this forum for some discussions between Phil Maquet, Max Habibi and myself you might find one example where we felt that we could justify a daemon thread in an RMI solution using WeakHashMaps - but that was a case where we deliberately worked through a theoretical exercise to see where we would end up. None of us were interested in it from a practical point of view.
As for the choice between RMI and Sockets - it really is a design choice. They each have their good points, and each have their bad points. You will see that we do not favour either one over the other in the book, and indeed the project we developed works equally well with either network protocol.
Threads versus Runnable in the context of "real-world" versus "textbook" issue is not quite as clear-cut as many other similar issues. The standard textbook statement about subclassing often mentions the "is a" argument - is your class a specific subset of the super-class? In that context, you could easily argue for using the Runnable interface in preference to Thread - your class is not likely to be a thread, rather it is Runnable (or it runs in a thread). But creating new threads is probably the most common case where I see people extending a class where the new class does not fit the "is a" rule. Quite simply, for most use cases, coders find the theoretical distinction is too minor, while the improvement in coding clarity makes it worthwhile to break the rule.
Regards, Andrew