Too Many Choices?
Thinking about beginning a new JEE project is as unsettling as it is exciting. On the one hand, you’re going to get your hands dirty with some new and challenging business problem to solve, you can use the latest and greatest JVM and of course let’s not forget the choice of many excellent application/persistence/web frameworks. On the other hand, you have … the choice of many excellent application/persistence/web frameworks!
I think we can all agree that choice is good, but is the sheer number of non-trivial frameworks really unifying the java community, or are we breeding segments of the population who know only a subset of what’s out there?
When you’re an ASP guy, you pretty much have you work cut out for you. Same goes for the new kid on the block Ruby [on Rails]. But Java, in its maturity, has brought so many innovations to market that one could make an entire project out of evaluating frameworks for use in any given project!
The days of Struts & JDBC are pretty much over, kids. Do you use Spring at the web tier? How ’bout JSF or Tapestry or WebWork? Do you decorate with SiteMesh, or assemble with Tiles? Maybe you are into JSP includes or writing a lot of custom tags. Do you manage your middle tier with Spring, or opt for the latest appserver’s EJB3 implementation? It might seem like everyone is using Hibernate for persistence, but it aint the only kid on the block. TopLink Essentials is bundled with GlassFish and other EE5 offerings will be supporting JPA as well. This is just the tip of the iceberg.
How do you decide?
on August 9th, 2006 at 8:02 am
Making decisions about what api/framework/server/jdk is something that a lot of people get wrong time and time again. There are so many factors, such as, support, documentation, maturity, user/developer ability, scalability/performance, etc and inevitably one of these gets overlooked or made out to be more important than it really is.
So, I tend to stick to a core stack of the things that do a good job of covering all of the above most of the time which make the simply things quick, but has the power/functionality to scale up to deal with Enterprise level applications. Spring is a great example of this IMO. Once you’ve got your basic stack covered, e.g. (Spring/Hibernate/Tomcat/JDK 1.5) which you/your team/company are familar with and which you know does the job well most of the time, you can then free up time to consider the specifics of project that might really benefit from the adoption of something new/different.
And I think it’s important not change everything project to project, just because it’s the latest and greatest.
If your previous stack was jsp/struts/ejb/websphere and you decide the next project your team is going to do will be velocity/spring/hibernate/tomcat then any productivity gains are probably going to be eaten up by the ramp up time and naive usage first time out. I’ve seen this time and again, where good, experienced developers cut themselves on the bleeding edge in this way trying to take on too much in one project, myself included.
on August 16th, 2006 at 9:12 am
And with new versions always on the horizon, not only do you have to contend with which technology, but which version!
Struts 2.0 vs. Struts 1.9.
Spring 2.0?
on August 18th, 2006 at 12:46 pm
I come from a “re-invent the wheel” sentimentality. But fortunately, I’ve seen the error of my ways. There are too many wheels out there, each with their own iteration on the spinning hubcap.
Which wheel the best for you?
The one that requires the least amount of tire protectant application, or allows the easiest maintenance and customizability.
And therein lies the ultimate dilemma.
By the way, Appfuse.