Java Reference
In-Depth Information
This anti‐pattern has been expressed by many developers with many different names, such as
Baklava Code. However, the name
lasagna
may have been i rst given by Adam Bien,
5
who is heavily
against unnecessary use of interfaces.
Mr. Colombus
Almost all experienced Java EE developers want to invent or implement their own perfect solution.
Most of the time these are only attempts to abstract and provide a better interface to a common
library, such as logging or testing, where it may even go to extremes and rewrite an important
functionality that has been supported by the open source community for years, such as an Object
Relational Mapping (ORM) layer.
Although inventing something new may look appealing, reinventing something is just a waste of
time. If you are going to write a new logging or an ORM framework, you should really have a good
reason to do it. If you don't, you are rewriting a well‐supported mature product, and most likely
you'll end up maintaining it and providing all the support, tests, and future development alone.
Always make sure you have done enough literature searches on open source projects before starting
to write a framework from scratch.
Friends with Benei ts
One huge problem of J2EE was vendor locking. By the time J2EE 1.4 was released, most vendor
servers only worked with the same vendor's tools and IDEs. This looked like a mutually benei cial
relationship at i rst because the vendor provided professional support for its own tools, and open
source tools and servers were left to the community to support. However, in the long term, many
J2EE developers observed how open source tools and servers provided standard behavior and com-
patibility to Java specii cations when vendors failed to do so.
There is nothing wrong with buying professional support and services and using tools, servers, and
IDEs from vendors as long as the project is not locked to that vendor. Vendor locking may introduce
problems that are impossible to solve without new releases and patches from the vendor, whereas
building applications always make it possible to change to other vendors.
Bleeding Edge
Passionate developers love to use bleeding‐edge technologies. For example, WebSockets were
introduced many years ago, but they still suffer compatibility issues with old versions of browsers.
No one can argue against the joy of learning something new and implementing a bleeding‐edge
technology in a project. However, it may become cumbersome to support such projects if you are
targeting the mainstream.
A good approach to deciding which framework or technology to use is to see how it i ts with your target
user base. If you are building a banking application for clients who may still be using Internet Explorer 6,
using WebSockets is the best choice (although most WebSockets frameworks provide fallback scenarios).
You always need to make sure an outsource library or framework is well supported, mature, and i ts
your project before moving on.
