Thank you all for your answers, they are very helpful.  Unfortunately
the developers I am working with have come from the schools in India
where they teach you the syntax but you don't know how to really apply
it.  They've worked a few months or a little longer at other projects
but are not really medium to high level J2EE programmers.  I narrowly
averted our initial Production rollout from being a disaster when I
found in some code they weren't handling JDBC connection resources
properly (or at all), and then had to do a rapid scan of a few hundred
long DAOs, list everywhere it wasn't handling connections properly, get
it out to the team leads and then with management behind me, forced the
changes to be fixed over a week.  I then verified every single one of
them.  Up to that point they had been having max cursor errors
constantly during load testing but hadn't told me until I found that
out.  There hasn't been one since.

I have been doing this type of development for over six years now, and
have a list of around 20 best practices that I do my code reviews on.
I used to have closer to 30, but I updated it a couple of months ago
for JDK 1.4.2.  The goal is to start out with me doing a few initial
code reviews, then have the team leaders start doing them as well, and
get to the point where the developers are doing them for each other.  I
have also installed Hammurapi, customized the inspector list and
modified existing inspectors and am running those automated code
reviews once a week.  The violations are starting to get fixed more
now.

But they aren't experienced and do not make sophisticated decisions.
In fact, if it is not written out in a functional spec, they will not
even go ask the question.  They will just make an assumption (usually
wrong) and it isn't caught until the QA cycle where it becomes a defect
and then the spec gets updated.  I'm trying to get some of them to just
go ask the question, but it is hard.

I never bothered with getters and setters that didn't have logic either
in my previous projects.  I knew a heavily OO guy whose code was pure
OO.  I remember him having lines like this:
getSomeFactory().getSomeClass().getSomeMethod().getSomeField()
.getSomeOtherField().getSomeList().getSomeField().getYetAnotherField().setSomething()

And sometimes he'd have fifty or sixty lines like that in a row.  No
one could ever follow
the logic.  And every method was just a pure getter, no logic at all.

Also, I am quite familiar with the various patterns, I have Design
Patterns and have used quite a few of them, and have also passed the
various Sun J2EE certifications, including the J2EE Architect
certification.

The number of objects may not be a problem, but part of Java is the
idea of re-use.  When I see the exact same 10 fields over and over in
dozens of objects, that looks to me like there should have been a
single class with those 10 fields, and all of the others should have
inherited from that class.  And considering that back in January there
were only around 30-40 classes (from the current project architect) and
that now we have 240 more just 9 months later looks to me like out of
control object creation, especially when so many are so similar in
various ways.