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...
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.