It is worth to look at old design

Recently I had a chance to look in to BeanContextAPI. It deals with lifecycle of a component. Most of us were not realize that the component has a complex lifecycle. The BeanContext API has a concept of a Service Provider and that Services can be added and removed dynamically with appropriate notification sent to the JavaBean. In essence it covers the concept of dynamic services as opposed to static ones.

In computer science we continue to reinvent things. What i feel is Our inherent weakness is to dismiss old inventions, and therefore throwing out the good design with the bad design. There are just too many cases of good ideas that have been thrown out simply because they are old and not new. The most classic example is the Relational model. We often try to look for another option and then we may come back the classic databases.

Unless untill there is a strong reason to go for new technologies, do not go for it. We should think twice before we go.

So as a word of wisdom. It's always wise to investigate old designs. You leverage the amount of time spent thinking about the subject (yes, they could think back then) and you approach their work from a new perspective. So, if we look at the BeanContext and the JavaBeans API's we realize that there's a lot of useful things in here. It's just up to us to evolve it into the new ways of thinking.

parleys!

For past few months, I spent most of my lunch time with my new favourite site. Though most of the presentations are spring based, favourite lunch timepass

Their home page claims
----------------------------------------------------------------------------------------------
Parleys.com is a new BeJUG initiative where the different recorded talks from JavaPolis, BeJUG, SpringOne, JaZoon, JavaZone and EclipseCon (and hopefully others in the future) get published on a regular basis.

The Parleys.com site wants to become the premier Java e-learning site where you can listen and subscribe to many Java related podcasts or view the flash talks, hopefully all resulting in improving your Java skills.
---------------------------------------------------------------------------------------------

10 types of people??!!

Today i came across an article in Tech republic on different types of people that we face in the field. I could see many of them in me in various times. I strongly believe that we cannot put people into catagories. we can commonly call them as diversed people.

Java IAQ

We might find lots of Java FAQs in the internet. But the new Java IAQ(Java Infrequently Answered Questions) may get your attention.

Check this out
http://www.norvig.com/java-iaq.html

I found one question very interesting and I do agree the Peter Norvig's vision. Here the piece

------------------------------------------------------------------------------------------------

Q: Can I get good advice from books on Java?

There are a lot of Java books out there, falling into three classes:

Bad. Most Java books are written by people who couldn't get a job as a Java programmer (since programming almost always pays more than book writing; I know because I've done both). These books are full of errors, bad advice, and bad programs. These books are dangerous to the beginner, but are easily recognized and rejected by a programmer with even a little experience in another language.

Excellent. There are a small number of excellent Java books. I like the official specification and the books by Arnold and Gosling, Marty Hall, and Peter van der Linden. For reference I like the Java in a Nutshell series and the online references at Sun (I copy the javadoc APIs and the language specification and its amendments to my local disk and bookmark them in my browser so I'll always have fast access.)

Iffy. In between these two extremes is a collection of sloppy writing by people who should know better, but either haven't taken the time to really understand how Java works, or are just rushing to get something published fast. One such example of half-truths is Edward Yourdon's Java and the new Internet programming paradigm from Rise and Resurrection of the American Programmer [footnote on Yourdon]. Here's what Yourdon says about how different Java is:

• "Functions have been eliminated" It's true that there is no "function" keyword in Java. Java calls them methods (and Perl calls them subroutines, and Scheme calls them procedures, but you wouldn't say these languages have eliminated functions). One could reasonably say that there are no global functions in Java. But I think it would be more precise to say that there are functions with global extent; its just that they must be defined within a class, and are called "static method C.f" instead of "function f".
• "Automatic coercions of data types have been eliminated" It's true that there are limits in the coercions that are made, but they are far from eliminated. You can still say (1.0 + 2) and 2 will be automatically coerced to a double. Or you can say ("one" + 2) and 2 will be coerced to a string.
• "Pointers and pointer arithmetic have been eliminated" It's true that explicit pointer arithmetic has been eliminated (and good riddance). But pointers remain; in fact, every reference to an object is a pointer. (That's why we have NullPointerException.) It is impossible to be a competent Java programmer without understanding this. Every Java programmer needs to know that when you do:

      int[] a = {0, 1, 2};
     int[] b = a;
     b[0] = 99;
  

  then a[0] is 99 because a and b are pointers (or references) to the same object.
• "Because structures are gone, and arrays and strings are represented as objects, the need for pointers has largely disappeared." This is also misleading. First of all, structures aren't gone, they're just renamed "classes". What is gone is programmer control over whether structure/class instances are allocated on the heap or on the stack. In Java all objects are allocated on the heap. That is why there is no need for syntactic markers (such as *) for pointers--if it references an object in Java, it's a pointer. Yourdan is correct in saying that having pointers to the middle of a string or array is considered good idiomatic usage in C and assembly language (and by some people in C++), but it is neither supported nor missed in other languages.
• Yourdon also includes a number of minor typos, like saying that arrays have a length() method (instead of a length field) and that modifiable strings are represented by StringClass (instead of StringBuffer). These are annoying, but not as harmful as the more basic half-truths.

----------------------------------------------------------------------------------------------