What's Your Complete Tool Stack for Java Web Development and Why?

Question

My Team recently embarked on our first real Java web app. Prior to this, our corporation was primarily a COBOL shop with some VB and C thrown in. Recently, new blood's been injected, including me and a few others who by education are primarily experienced with Java but none of us have really done this full blown and for real at this point. I've read books like Continuous Integration, The Art of Agile Development, Java Power Tools, Refactoring, etc. and I listen to podcasts like the JavaPosse and have come away with it convinced that TDD and CI and automated code inspection and SCM etc. are very important to any truly successful and maintainable software project. The problem is, of course, that all of this is white-tower knowledge.

What I'm looking for is specifically the tool stacks that other experienced java teams are using, from the browsers testing through the IDE down to CI Server (or lack thereof) and automated inspection tools. We're pretty sold on distributed SCM although we're still not set on choosing Git or Mercurial right now (I'm pro Git but others are a little leery of it's IDE support). I think we're all sold on findbugs. Ant's the build tool we're planning on at the moment. We're thinking about Hudson for a CI server. I use Emacs but the other devs dig Eclipse for JEE (and I think there's rumors of RAD to come, although I wouldn't touch it with a 10 foot pole). Obvious lacks are in the automated complexity checking, code convention tools, architecture policy tools, and other such things that I'm probably not even thinking of.

We're basically pushing for Spring/Struts2 w/ Hibernate and a DB2 backend, if that's germane.

Also, a basic description of your environment would be interesting. Are you using Dev Sandbox/Integration Server/Production Server? Do you have a different DB on dev boxes for performance than you do on Integration and Production? Things like that.

To be clear, I'm hoping for blog like responses to this (though of course every answer will be appreciated). Unless you absolutely have to, please don't just list a bunch of tools in a single comma-separated line without explaining yourself. I'm really interested in hearing how everything gets integrated and used.

Thanks in advance!

Caveat: I'm aware of this question. Specifically, while that question could possibly have answered what I'm asking here, most of the answers were not really explained. That's what I'm trying to avoid in the answers to this questions. Thanks!

Answer 1

Why on earth would you use Struts2 for a new project? At least move to something modern like Stripes.

To answer your question, we've had fantastic success using SVN paired with a suite of Atlassian tools: Jira for issue tracking, Bamboo for our build server and Fisheye to keep an eye on things. Having RSS feeds for all of the above really lets developers, managers and anybody else keep a pulse of the day to day operations of your project.

Answer 2

We've used a toolset consisting of IntelliJ, CVS, Ant, Hudson, JIRA and some code inspection stuff like findbugs and PMD. This will work pretty well, because there is a lot of documentation available.

And yes, we have multiple environments: dev, integration, test, staging and production. Main points for me:

• good integration of the IDE with the source repository will really help developers and prevent stupid glitches when checking in code.
• think about what is environment specific in your build. Keep all environment settings in a properties file and let Ant (or another build tool) do the configuration for that specific environment.
• allow for some personal preferences. Using different IDEs in a single team should not be a problem at all.

Answer 3

We use Eclipse as our IDE. It's simplest and cross platform (Linux, Windows and OS X). Some customers of ours have bought into the IBM vision and it still plays nicely with RAD. We have had projects where some developers are using RAD and some are using Eclipse, if you're careful you can pull it off with just some minor version compatibility things.

For version control we still use CVS and occasionally subversion since these are best supported by the IDEs. Although I'm sure that you understand a DVCS like git or mercurial probably your most junior resources do not and it may just end up confusing the heck out of them. The last thing you want is a bunch of confusion in this area. For more on this topic I would listen to stackoverflow podcast #36 with Eric Sink.

For build tools ant should be sufficient for all you need...maven is great for managing multiple project dependencies but that's probably overkill for you unless you are working with many projects or on an open source project or something.

It's difficult to make a recommendation on web application frameworks. Usually we like to keep things simple if possible. Using a framework gets you a whole bunch of functionality for free but will also lock you into doing things a certain way. So halfway through your project you may find you want to do XYZ thing but the framework you have chosen makes that extremely difficult. So I guess my advice is to understand what the framework you have chosen is good at and what it is not good at.

If I'm making a pretty simple web application (15 screens or less, no advanced functionality or screens) I have been known to write little custom frameworks using the Command pattern with jsps.

If you're going to use Hibernate I would use Spring also since you get a lot of extremely useful stuff (transactions, pooling, etc.) automatically with Spring. You just have to adjust to the fact that everything needs to be done inside the Spring container (this took me a while the first time around).

For environments it varies from customer to customer, but they usually have the standard system test, uat and production environments. Our workstations end up being the development/sandbox environments.

Hope that helps.

Answer 4

I do a lot of rapid prototyping, proof of concepts, and stuff like that - projects that most likely won't see the light of day, but that will be used to prove out algorithms, designs, etc. So our environment tends to be lighter and quicker than the production side of the house - also more hacky and less enterprisey. A lack of written in stone features and requirements means that we don't have rigid designs to code to, so we've just gotten used to the idea that our codebase may be pretty messy. We also use the language and tools that makes sense for the project that we're currently working on, so our environment can change quite a bit from project to project. That's led to our development environment being pretty small.

We're using git to manage source code, and while we've had some problems getting used to it (we were CVS up until a few months ago), it's working well, especially for the remote developers (like me).

Our code environment is simply JSF+Facelets, nothing fancy at all. It's fast enough for us to develop in, and simple enough for the co-ops we hire to pick up quickly. Our database is currently Derby, and we're using JPOX to connect to it, although for our larger projects, we tend to use hibernate and MySQL.

Build environment is Maven2, which allows us to plug in all the cool reporting stuff when we xdo code reviews, and comment it out for regular development. For some of our other, non related projects (bulding LaTeX docs, etc) we're using ant.

On larger projects we used continuum for continuous builds, but our current project is small enough (and our time constraints are tight enough) that we haven't set it up.

We were using Bugzilla for bugs, but again, haven't set it up for our current project.

For actual development, I think everyone else on the team is using Eclipse, but I'm just using VIM and a shell - I can't stand IDE's. Plus it helps that I don't have to know more editor commands when I'm ssh'd in somewhere. Nothing that we've done is dependent on an IDE, so we don't have standards on what people should use for development. I spent a few hours one day writing a little Java GUI that does a directory listing in tree format, and filters out things like CVS folders, and that's the most IDE'ish I get.

We do keep separate environments for testing and "production" - each dev has their own environment for their own work, then we have a shared server for our internal use, and a "production" server for demos to management and customers.

Most of our projects use some form of this structure, and it's worked out quite well for us.

Answer 5

Eclipse, of course, as the IDE. SubVersion for source control. Runtime: tomcat/oracle on (I think) SUN boxes. We have two webapps, one is springMVC over hibernate with velocity templates, the other is struts over hibernate, with plan JSPs and a lot of java code.

Oh - and there's another project, also with two webapps. One uses oracle's XDK and XSLT for presentation, the other uses "Turbine", which I am unfamiliar with and have to learn.

We have a small shop, so just DEV and PROD. There are three webservers - DEV, PROD and PUBLIC. The PUBLIC one points at the prod database (of course), and does not have the "editor" components of the system.

Answer 6

I can not resist and have to mention one thing: DB2 sucks! When you are free to choose the database for your project, take some time. At first I thought it is because I don't know that beast and the tools that come with it, but after some month I can surly say, it is a pain in the a**. Simple tasks like creating a backup and restore it, at some of my colleagues workplace, is quiet hard. I my humble opinion, MySQL, Microsoft SQL Server (if you are a windows guy or in a windows company) or Oracle are far better. The question is, how much data do you expect? How many transactions? And how much you want to do right in the database (like triggers and stuff)? Maybe that is the wrong thread, but like I said, I could not resist... sorry.

For all the rest, you seem to be very good prepared. All the tools you mentioned are good choices in my opinion and especially findbugs and hudson are must haves! Finbugs is not only great for experienced programmers and errors made in haste, it's even better for beginners to learn stuff (since the COBOL guys are really Java beginners).

Beside all that tool stuff, you have give all the COBOL programmers good training. Train them OO and Java, otherwise you will get COBOL programs written in Java and nothing object orientated at all. And don't forget that building a webapp requires much more then just Java. They have to learn how http and the www works, what HTML, CSS and JavaScript is and that there different browsers that behave differently and so on. All that is harder then it sounds, when you have done the last 20 years on a IBM Mainframe without a GUI or a mouse.