-
1. Re: JDK1.4 hotswap class redefinition
marc.fleury Dec 7, 2002 1:30 PM (in response to jhaynie)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 Dec 8, 2002 10:13 PM (in response to 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 Dec 10, 2002 6:52 PM (in response to jhaynie)> 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 Dec 28, 2002 7:29 AM (in response to jhaynie)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