Java Reference
In-Depth Information
equivalent to Struts or JSF. There are many reasons why this
could be true: organizational inertia, "not invented here"
syndrome, lack of perceived benefit in changing working
code, or possibly even a slight sense of hubris in thinking that
you could do things "better" than the open-source developers
did in a particular framework.
However, the time is long-past when any of these reasons is
worth using as an excuse not to adopt a standard framework.
Struts and JSF are not only well accepted in the Java
community, but fully supported within the vendors like
Oracle and IBM. Likewise, in the rich client arena, the
Eclipse RCP (Rich Client Platform) has also gained wide
acceptance for building standalone rich clients. While not a
part of the Java EE standard, these frameworks are now a part
of the Java EE community, and should be accepted as such.
Develop as per customer specifications
Know the specifications by heart and deviate from them only
after
careful
consideration.
Just
because
you
can
do
something doesn't mean you should.
It is very easy to cause yourself grief by trying to play around
at the edges of what Java EE anables you to do. We find
developers dig themselves into a hole by trying something
that they think will work "a little better" than what Java EE
allows, only to find that it causes serious problems in
performance, or in migration (from vendor to vendor, or more
commonly from version to version) later.
There are several places in which not taking the most
straightforward approach can definitely cause problems. A
