Java is supposed to be much better to build big projects, because of static type checking, and all the rigour around the language. But how many of you have seen medium sized projects taking more than 30 minutes to build.
At work, they have a standard J2EE project, with only about 50 EJBs, hundreds of JDO classes, and standard classes. Between the JDO generation, EJB generation, EJB dependencies calculations, and packaging, it takes 20 minutes. And the project is not doing that much. One can optimize to avoid dependencies calculations and it would then take about 12 minutes. But still.
With Python, Ruby or your favorite interpreted language, this would be at most a few seconds to test a new version. Now I am a fan of Java and don't enjoy that much programming in interpreted languages, especially since modern IDE like Eclipse do so much for you.
To sum up, Java is supposed to be the right language for large scale projects, and yet it is on large scale projects that compilation is an issue. Ok, this will enforces a better separation of concerns, and will probably be beneficial in the end. But I am not sure that most people do a good separation of concerns in projects they manage.
I think it is no accident if the next step in Java development involves much more runtime compilation. It somehow started with JSPs, and then with the various XML config files combined to java reflection. It is now made even more popular with annotations, see EJB 3.0.
I am wondering a bit if one day compiled languages will be only a curiosity for most enterprise projects.
The trade off is that to get the same level of confidence in the code, the time you save by not compiling has to be spent in running unit tests instead, and my experience has been that running any remotely comprehensive set of unit tests will usually take a lot longer than compilation.
ReplyDeleteI find the best way to look at a compiler is as a very simple (basically only catches type errors), very lightweight (doesn't need to run the code) and very thorough (always "tests" 100% of the code) unit testing framwork.
Some argue that duck typing eliminates the need to worry about typing errors but the lack of theoretical underpinnings for duck typing makes me a tad cautious. In comparison the "standard" type model (at least as implemented in languages like Z and Eiffel - Java's type system is half-assed in comparison) has a very solid theoretical foundation.
taking more than 30 minutes to build - Hmmm. We've got a project with ~500 java files, and it builds very quickly, unless you're rebuilding from scratch. Maybe I don't understand; it just compiles the changed files...
ReplyDeletePerhaps you are rebuilding too much, i.e., rebuilding things that do not need to be rebuilt. Ignoring that possibility,...
ReplyDeleteWhat you describe seems to be a fault with EJB, rather than with Java in general, and though I'm not very familiar with EJB, it seems that the problem has been fixed with EJB 3.0.
EJB is not appropriate for most of its users; it is intended for massive scalability that most users simply do not need.
Blaming Java in general for this is rather like blaming C for poor operating systems - reactionary and unreasonable.
Ricky, I concede it will mostly happen with J2EE project. EJB 3.0 is getting better because more stuff is generated at runtime, which is a similar path as interpretation.
ReplyDeleteHowever 30 minutes is quite common, see http://www.martyandrews.net/blog/2006/06/ant_build_speed_with_ivy.html