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...
ReplyDeleteMatthew is right, a project in Java even moderately big should not take 30 minutes to compile. If you only use ordinary java classes, and a simple way of building them, you'll do that in seconds. Those projects are relatively rare.
ReplyDeleteIn the J2EE world, with EJB generation, descriptor generation, EJB dependency calculations, and sometimes JDO generation, you will often get 30 minutes for a similar sized project and ant build file written by a normal developer (one that is not very good in ant skills).
Again things are getting better in Java, because they are getting done more and more during the runtime (annotations, EJB stub generation,...).
Perhaps 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