Java Class (Class loader) hell


EJB programming & troubleshooting: Java Class (Class loader) hell

  1. Java Class (Class loader) hell (1 messages)

    For years, Microsoft has been barked , ridiculed
    and probably damned for its dll hell problem. We
    those Java developers, however, did not laugh for
    long. We face the very similar problem now.

    Some examples are the incompatibility of different
    implementation of the same packages (the org.omg.*,
    CORBA, xml parsers, etc.). When they are used in
    different frameworks, problems arise when different
    class loaders try to either load the same classes with
    different versions or the different implementation of
    the same class. These problems are very tricky and
    intricate. Any one that has some experience with J2EE
    may have suffered because most of the J2EE vendors
    implemented their specific class loaders to deal with
    J2EE applications in the same application servers.

    This problem is not J2EE specific. One might
    experience this in a very simple job. Not quite a long
    ago, a post
    ( )
    in this group talked about the author抯 frustration on
    using ANT api.

    Well, I can tell you two stories from my own

    Story I.

    I wrote a J2EE application. I used struts. Every
    thing worked fine until I used some packages from the
    third party. I got an exception:

    javax.servlet.jsp.JspException: Cannot find message
    resources under key org.apache.struts.action.MESSAGE

    which halt my application. If you search on the web,
    you can see a lot of the same questions. There are
    many different answers. You抣l become very confused
    after you read a few of them. I tried explore the
    problem. I removed the jars from the third party one
    by one and run the app about each time, in total about
    ten times (do you like this process?!). It seemed I
    still cannot finger out the problem. After I thought
    for a quite long time, I looked at the web.xml I used.
     I suddenly got the idea that my problem came from the
    two servlet I used: one is the struts action servlet
    and the other one is from the third party. I let them
    be preloaded. Looked at the order, I put both of them
    as order 1 (a mistake), and the one from the third
    party was before the strut servlet. I immediately
    changed the third party to not be preloaded. The
    problem went away. It certainly a classloader
    problem. Well, I only felt a little bit lucky this
    time because I still didn抰 know what classes caused
    the problem.

    Story II.

    I used Jdeveloper to play (because no one wanted to
    hire me, even I said I could work for free) J2EE
    applications. Each time when I add new packages to
    play, I have the feeling I may break my toys.
    There are several times, I have to blow up my
    Jdeveloper and install a new one since I can see my
    libraries is the classpath, how ever the application
    cannot find them. Sometimes reorder the libs may help.
    But one must know that reordering libs may not mean
    the classloaders load the class in the libs order .
    That抯 the hell, is it?
  2. Java Class (Class loader) hell[ Go to top ]

    I don't see any "class loader" connection in these two stories except for the fact that you have attributed the problem to class loaders, when you should have put the blame on yourself and your environment, where it belongs.

    Both stories tell me you're working in an unmanaged development environment. Why would one have two versions of an XML parser and, more importantly, put *both* on the class path? Dumb, isn't it?

    Your understanding of Microsoft's DLL Hell is not correct either. The problem is that Windows applications may "upgrade" system DLLs (overwriting them) during the installation and this sometimes tends to break previously installed software which depends on some aspect of the original version of the "upgraded" DLL. We can't possibly "face the very similar problem now": the "problem" in the stories is based on the availability of multiple versions of the same package at the same time, which is clearly not the case with Microsoft's DLL Hell.