I was just emailing back and forth with Duncan about this issue. I'll
repeat here what I said there.

Take a look, for example, at the help topic "working productively in
teams." If this principle should be articulated anywhere, it should be
articulated there. But there's no mention of it--it's all about who
designs the EOs, who designs the VOs, and who designs the pages. (Not that
I don't think that's a useful division. But if you're not going to train
your whole team in Java, it's *certainly* not the most important
division.) Instead, I think a lot of teams have the following experience:

1) They go for ADF without having real Java knowledge *anywhere* on their
team, because they have the impression it's a 100%-declarative framework
(except maybe for a bit of scripting-style Java, which is trivial to learn
if you're familiar with *any* procedural language).
2) They try to build a real enterprise application.
3) They freak out.

Now, as a consultant, that process isn't all that bad for me, because Step
4 is usually, "They hire a consultant to pull them out of the fire." But
for the community generally, I think it would be better if people went
*in* to ADF knowing what they do and don't need. They don't need a team
full of Java experts, or even of solid Java programmers. But they are
going to need someone (or, if they're a big team producing a lot of big
apps, several someones--probably even more than that if they're a *huge*
team like Oracle Apps) to solve their Java problems for them. And if they
don't want to hire or train someone like this, they can at least move Step
4 earlier in the process.