4 Replies Latest reply on Dec 28, 2002 7:29 AM by andygodwin

    JDK1.4 hotswap class redefinition

    jhaynie

      Has anyone looked into this new capability in 1.4 to truly hot swap class definitions at runtime? (vs actually swapping classloaders, etc.)

      Here's some sample code and it works really well. I think there still would be some performance issues until the -server option is working properly - but it may be something to check out:

      http://www.experimentalstuff.com/Technologies/HotSwapTool/hotswaptool.html


      I can imagine a problem at runtime you're trying to fix, you create a new aspect to give you more debugging, drop it in to jboss and it causes the new aspect and associated classes to be "hotswapped" - you find the source of the error with the new debugged code - put in the fix and re-deploy the changed classes w/o ever restarting the server.

      This is powerful. Has anyone looked into this feature of 1.4 yet?

        • 1. Re: JDK1.4 hotswap class redefinition
          marc.fleury

          yeah we looked at it last September when a student from the NYC training went back and tried it.

          One problem is that it requires running in "debug VM" mode but really that is ok ( I mean it will be ok in 2 years). The real problem right now is that the guy that tried it reported "NotImplementedExceptions". So the real problem is that it is advertised but last I know there is no real support. It would be interesting if you could get the latest on that.

          I think it is particularly interesting when we reach the cache layers. Meaning if you code your service to get it's state in the cache layers, then these are centralized and we can hot deploy the service with maintaining of state in the cache. This mean stateful hotdeploy of the server, (today we only do stateless hot deploy of the server's services).

          And then we have recreated...
          Visual Basic.

          man we rock

          • 2. Re: JDK1.4 hotswap class redefinition
            jhaynie

            I didn't do much testing with it but I intend to do some playing around with it. However, I did download it and write some code and hot-swap successfully. Supposely, the whitepaper says the "-Xdebug" isn't a problem - expect in -server mode (which you'd normally want in jboss). However, in -client mode, there is 0 slowdown (supposeably). They claim that the next release of 1.4 will have -server fixed to be the same so that you can run it wire speed.

            I'll play around with it and report back if there's anything useful for us to consider.

            I do like the idea of cacheing state and re-deploying the service logic.

            • 3. Re: JDK1.4 hotswap class redefinition
              marc.fleury

              > normally want in jboss). However, in -client mode,
              > there is 0 slowdown (supposeably). They claim that
              > the next release of 1.4 will have -server fixed to
              > be the same so that you can run it wire speed.

              cool,

              > I'll play around with it and report back if there's
              > anything useful for us to consider.

              definitely

              > I do like the idea of cacheing state and re-deploying
              > the service logic.

              Yeah that would be the feature.

              • 4. Re: JDK1.4 hotswap class redefinition
                andygodwin

                Missed this thread completely ... !!

                I tried this after NY and got the basics working,
                pretty much just like the experimentalstuff tool.
                Trouble is (and this is mentioned on that page)
                the current VM (Sun's VM that is) only supports
                fairly basic changes.

                Interface com.sun.jdi.VirtualMachine is your handle
                on the running VM and through this it's possible
                to load up a class definition, in bytes, to replace
                a class already in the running VM, using:

                redefineClasses(Map classToBytes)

                If you try this, tho, you'll soon start getting
                UnsupportedOperationExceptions thrown at you.

                Check the docs at

                http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jdi/index.html

                In short, VirtualMachine has the following
                capabilities methods:

                canRedefineClasses()
                "Determines if the target VM supports any level of
                class redefinition"

                canAddMethod()
                "Determines if the target VM supports the addition
                of methods when performing class redefinition"

                canUnrestrictedlyRedefineClasses()
                "Determines if the target VM supports unrestricted
                changes when performing class redefinition"

                Sun's VM returns true for the first only. What
                this means is that if you try and redefine a class
                it will fail if any of the following have changed

                the schema (fields)
                the heirarchy (subclasses, interfaces implemented)
                methods added or removed or signatures changed
                class or method modifiers

                where method in the above means methods and
                constructors.

                If all that changes is the internal implementation
                of methods or constructors then it works OK.

                So, yes, it does work ... only in a very limited
                fashion.

                HTH