Nothing is transparent...
From the beginning of Java, or even distributed programming, there is a dream to be "transparent".
I heard it already 1995/96, in the time as RMI was introduced. At the same time Jim Waldo wrote a whitepaper about this fallacy.
Meanwhile the concept of "transparency" is extended to persistence, transactions and security. Vendors still try to hide the "complex", technical stuff from the developer.
The problem here: aspects like distribution, transactions or persistence cannot be hidden... The "transperency" can only streamline the development, but cannot make the developer's background knowledge superfluos. "Real World" projects have more problems with deadlocks, chattiness, performance or clustering, than with implementation of some additional interfaces like javax.ejb.SessionBean or javax.ejb.EntityBean. They were often generated with tools like xdoclet...
From my point of view technologies like : JEE5 or Spring make experience programmers more productive. But an unexperienced developer still has to understand the concepts. Otherwise a complex project will fail after some iterations -> it's too much magic.
JEE5 ist wonderful, but harder to (deep) understand. The problem of "leaky abstractions" still remains...
Good point. If you abstract to much you will not learn what is happening under the covers. This is why, in grade school, we learn to do math on paper before we are given calculators.
This is why I am not a big fan of IDE's that do all of the plumming for you (like JEE development on Netbeans). Its hard to debug (and write quality code) when you do not understand exactly what is happening.
Posted by Brian E on July 20, 2006 at 10:26 PM CEST #
My feeling here: because of the fact, that many "enterprise" developers do not understand the basics, they are jumping from technology to technology and try to find the ultimate framework :-)
Posted by Adam Bien on July 21, 2006 at 11:51 AM CEST #