How many times do you restart your server during development?
Is the lack of Java class reloading a problem?
Ever since I began developing server-side Java applications, I’ve had to constantly restart the server. Whether it is a Java HTTP server, RMI server, EJB application server, or custom server, restarting seems to be a common practice. One obvious reason for restarting any server is to flush out existing resources being utilized by the server and/or the state maintained in the server. That brings up an interesting design and development problem; I’m hoping some of you Java gurus and novices who face the same issue can offer some advice.
Java class loading
With Java technology, “standard” recompiled classes aren’t automatically reloaded, so a new Java application cannot be tried out until the server running it is restarted. (When I say standard classes, I mean non-JSP/servlet classes — perhaps ones used for application data, utility functions, and so on.)
To get around that, I tend to overuse JSPs and servlets in almost all my Web-based application development, especially in smaller projects, since JSPs are compiled into a servlet each time the JSP file changes. In fact, I even stay away from straight servlet coding because the servlet reloading in most Web servers is somewhat flaky. And coding Java, compiling the servlet into a classfile, and placing it in the Web server’s classpath is more complicated than placing a JSP file on the Web server and letting the Web server do the rest.
JSP coding is an extremely convenient mechanism for development, but using just JSPs — and possibly JDBC — isn’t the most effective design or solution for large and/or complex projects.
Balancing good design with rapid development
For most projects, you try to use certain best practices like basic object-oriented design, architect/design patterns, and frameworks. The use of standard APIs and protocols such as EJB, JMS, RMI, and servlets is also crucial to a good Java application development project. While those things are absolutely essential to projects with multiple developers, they also add complexity to projects and make the applications less dynamic (with regard to automatic Java class reloading).
Of course, using a lot of JSPs/servlets is impossible in an n-tier Java application in which you have technologies such as JSPs/servlets, EJB, JDBC, JMS, JavaMail, and core JDK in the mix. So here are some questions I hope you can help answer:
- What is a good workaround to server restarts during the development phase?
- Are there any available class loaders that check a classfile’s time stamp and reload it if necessary?
- Can better architect/design patterns and/or practices also help you get around this development problem?
- Do you even consider server restarts an issue?
- Is class reloading an optional feature that Sun Microsystems should provide in its JVM (perhaps controlled via a command-line option)?
Write to me and let me know your thoughts. Or visit the iSavvix Soapbox forum for this column.
