10 Replies Latest reply: Nov 12, 2009 1:39 PM by jschellSomeoneStoleMyAlias RSS

    javax.servlet.ServletException: Bad version number in .class file

    843810
      Ok, the most obvious answer to this question is compiling the java source in a higher version than the target JVM/environment. There are many examples of this problem and it's fix online (ensuring that the source is compiled at the same or lower version than the target JVM).

      The problem*
      I'm including a java class in a JSP page. This seems to generate a javax.servlet.ServletException: Bad version number in .class file exception. Here's the code:

      JSP Page:
      <jsp:useBean id="userAgentDetect" class="za.co.mycompany.theproject.utils.browser.UserAgentDetect" scope="page">
          <jsp:setProperty name="userAgentDetect" property="userAgent" value="${header['user-agent']}}"/>
          .
          .
          .
          
      </jsp:useBean>
      The Java Class
      package za.co.mycompany.theproject.utils.browser;
      
      public class UserAgentDetect
      {
       //Classified methods in here :)
      
      }
      What I would like to know is that is there anything else that can generate this error? It has twice cropped in a project that I'm working. The first time I was able to fix this [http://forums.sun.com/thread.jspa?forumID=7&threadID=5403695] by deleting a .jar file that seemed to contain code compiled on a higher version (1.6) than the JVM (1.5). This time around that .jar file is not there. And as luck would have it, it's my section of the project that's generating this exception. Add to that, the code is working on my local development environment, the test and production environments as well. But a colleague who's recently checked out the code is getting the exception in question.

      Environment(s)*
      The local development environment is a Linux image running Apache Tomcat 5.5.27 in VMWare Player with JVM version 1.5.0_16-b02. We use NetBeans in Windows to develop and deploy our code to the image. I'd appreciate any clues as to why this exception is occurring. Even though the code's running in production, I don't want this exception to appear suddenly and I have no answers.
        • 1. Re: javax.servlet.ServletException: Bad version number in .class file
          EJP
          Your colleague is somehow using the JDK 1.6 compiler and doesn't have -target 1.5 set.
          • 2. Re: javax.servlet.ServletException: Bad version number in .class file
            843810
            Sorry for the late response, for some reason I didn't get a notification that this thread was updated.

            There are other Java class files that are built into the project all being built using JDK 1.5.

            If this were the case then all our other Java files would fail with the same exception but it's happening with just one class. The other strange thing is that I'm able to build and package the same class and not get that error, but I have seen it before as well in another class. Again same scenario, using JDK 1.5, but getting version number error.

            I'm inclined to think that this error is more a symptom of something else. What that something is, I haven't a clue.
            • 3. Re: javax.servlet.ServletException: Bad version number in .class file
              EJP
              it's happening with just one class.
              It's happening with the first class the servlet container encounters with the wrong version number. That will stop it stone dead and prevent it from finding the others. The servlet container will always load the classes in the same order so it's always the same class.
              • 4. Re: javax.servlet.ServletException: Bad version number in .class file
                843810
                Thanks for following this up.

                It might fail on the first file with the wrong version, but what I've found is that the other Java classes being called/instantiated from jsp pages seem to work fine and don't throw that exception. The exception, to me, would imply that during the .war file creation these would somehow have been compiled with the right version of the JDK, 1.5, then somehow mysteriously this one file would have been compiled with version 1.6.

                When I first came across this exception, I found a link that showed how you can use hexdump in Linux/Unix to check the version of the compiled class file on the server. I ran this with java and jsp pages both in the Tomcat's deploy directory and in the work directory (where you can find the compiled jsp pages). It was there that I was able to confirm that the compiled classes were not compiled in a higher version the JDK that was running on that server (well, at least to the best of my knowledge). The other thing to consider as well is that we normally build our .war files on the target machine. So the compiled classes should be of the same version of the JDK installed there, which is again version 1.5. On our local machines where we build using NetBeans and deploy to a Centos image running on our local machine the process is similar. Again, the version of the JDK is 1.5 and can be set through the project properties. We don't change this setting at any point.

                What I found strange is that in both cases where this exception is thrown, it was a new java class that's been added to our package. When trying to get to the jsp page where this class is instantiated then the exception is thrown. Other pages working in the same fashion don't throw that exception.

                I hope this clarifies the dilemma I'm facing.
                • 5. Re: javax.servlet.ServletException: Bad version number in .class file
                  EJP
                  When the problem happens, the version number in the affected class file must be wrong. So you have to establish how that happened.

                  Are you pre-compiling JSPs or letting them be compiled on the fly by the container?
                  • 6. Re: javax.servlet.ServletException: Bad version number in .class file
                    843810
                    The exception is being thrown by a class being instantiated in the JSP page not the JSP page itself.

                    But to answer your question, the JSPs are not pre-compiled. The container does that in my case. I'm actually inclined to think there might be something fishy with the IDE (NetBeans). The java classes are compiled and are packed into a JAR (placed in the WEB-INF/lib directory) which is in turn packaged into a WAR file. That gets deployed to a Tomcat server.

                    I'm not sure what other information I can give you, but thanks again for keeping tabs on this thread.
                    • 7. Re: javax.servlet.ServletException: Bad version number in .class file
                      843810
                      I think I've found the answer. It turns out that adding the "target='1.5'" to the javac ant/build task, prevents the exception. I've asked all the other team members to update their build.xml files accordingly and so far the exception seems to have disappeared.

                      I'm keeping my fingers crossed, but I think this is the solution.

                      Thanks for you patience, tips and persistence.
                      • 8. Re: javax.servlet.ServletException: Bad version number in .class file
                        EJP
                        That's what I suggested [a month ago|http://forums.sun.com/thread.jspa?messageID=10837780#10837780].
                        • 9. Re: javax.servlet.ServletException: Bad version number in .class file
                          jwenting
                          It is of course no guarantee. While it will prevent the class version errors, it does not prevent people from using classes and methods/members that aren't available in 1.5, possibly leading to runtime errors.
                          Best solution is always to compile against the same JDK version that will be used at runtime, in this case a 1.5.
                          • 10. Re: javax.servlet.ServletException: Bad version number in .class file
                            jschellSomeoneStoleMyAlias
                            jwenting wrote:
                            It is of course no guarantee. While it will prevent the class version errors, it does not prevent people from using classes and methods/members that aren't available in 1.5, possibly leading to runtime errors.
                            Best solution is always to compile against the same JDK version that will be used at runtime, in this case a 1.5.
                            Could be a bug in the newer compiler which only shows up when run in the older VM too.