1) Instance Fields within already instantiated objects of the reloaded classes will be left un initialized. Instance fields will be initialized only when a new class instance is created.

2) Static fields will never get initialized.

3) Sometimes debugger will fail to set a breakpoint.

4) The “this” instance variable will be renamed to “that”, evaluations in debugger will not work.

5) Conditional breakpoints may fail because instance variables are accessed by the debuggers as this.variable, which has to become that.variable.

6) Extra lines in the stack trace.

7) Changed to the class hierarchy will not be reloaded.

Features	Sun JVM HotSwap	JavaRebel
Changing method bodies
Adding/removing methods
Adding/removing constructors
Adding/removing fields
Adding/removing classes
Adding/removing annotations
Changing interfaces
Replacing superclass
Adding/removing implemented interfaces

Although JavaRebel is more tolerant to code changes, its limitations over do its benefits. Reloading classes with instance variable addition/ deletion is of no use because in the already instantiated objects, the instance variables will remain null, static variables will never get reinitialized. Hotswap at least does not do things if it cannot do it right. JavaRebel, will create issues in your application’s execution, on which you will waste your time debugging.

I hope that sun will improve the built in hot swap feature and add support for reloading classes with add/removed methods, constructors, fields , annotations and addition of new classes on a more better way.

---

Add this page to your favorite Social Bookmarking websites

Comments

Search

Jevgeni   |82.131.27.xxx |2008-05-28 14:54:33 Actually JavaRebel does support reloading classes bundled in jars, check out the installation manual.

Rajesh  - You are Correct   |122.167.146.xxx |2008-05-28 21:49:49 Jevgeni, You are right, JavaRebel does support reloading classes bundled in jars. I have removed that point from the article now. Thanks for your comment.

Jevgeni   |194.126.102.xxx |2008-05-29 03:04:47 Also the first two points are just conceptually impossible. It's not a JavaRebel limitation, we just describe it so that people wouldn't expect the impossible

Shams  - Reflection?     |221.120.98.xxx |2008-05-29 22:17:54 Don't have much knowledge about java agents, but isn't it possible to set the instance and static fields of the classes and their instances via reflection. We can cache fields of the current class and instances and then set back the fields via reflection after the class has been reloaded.

Jevgeni   |82.131.27.xxx |2008-05-30 01:58:37 OK, the currently initialized fields do stay initialized (both static and non-static). What was written in the FAQ was that _newly added_ fields are not initialized in the old objects. New static fields at the moment will not get initialized at all.

Vimal  - Trick but not Impossible     |203.197.168.xxx |2008-05-30 03:16:17 Jevgeni, initializing newly added instance and static fields, should be possible but tricky. In you java agent you will be manipulating class byte codes, along with that you can add a special method to all classes, copy the initialization of new variables to that methods, then add a call to this method as the first line in all other methods, with a special check so that that method gets called only once for each object after the class is reloaded.

Jevgeni   |82.131.27.xxx |2008-05-30 03:30:45 You assume that field initialization is something separate in the bytecode. In reality it is just prepended to all of the class constructors and it is impossible to make difference between genuine constructor logic and the field initialization logic. Same goes to the static field initialization logic, it all is put together to method, which unsafe to call again. Although there is some amount of static analysis we could do to extract the part that does the actual initialization it would be inherently unsafe to call it, because it might have side effects that assume the calls in some kind of order and etc.

Jevgeni   |82.131.27.xxx |2008-05-30 03:31:43 Static initializer method name should be <clinit<

Vimal  - This to That Why?     |203.197.168.xxx |2008-05-30 03:18:32 Moreover, I didn't get the reasoning behind renaming the this instance variable to that.

Jevgeni   |82.131.27.xxx |2008-05-30 03:32:33 Bug in Eclipse, it will crash terribly if we don't do that. That one we hope will get fixed eventually.

Matt Passell  - Have you tried it?     |209.6.112.xxx |2008-05-29 09:08:24 Rajesh, did you actually try it out or just read the docs? I've been using JavaRebel for the past few weeks and it's helped me cut down the number of server restarts to almost none. It's not magic, but most forms of refactoring (method addition/removal, for example) are covered. --Matt

Quinton Dolan  - Just like it says on the label.   |203.144.21.xxx |2008-05-30 04:12:53 With JavaRebel you basically get all the benefits, and the same limitations as Ruby's open classes, but using pure java. If you were going to pick on anything I wouldn't bother with the limitations list, they are mostly fundamental limitations of the JVM class model, the only real downside to using it is that you have a slight performance penalty, but the benefits are worth it.

Jeevan  - Similar open source project   |71.5.113.xxx |2008-05-30 14:10:16 Altough not as comprehensive as JavaRebel,(wich resports to byte-code manipulation), there is an open source project that gets basic stuff done. Most of the advanced features like method addition is not supported, but it comes in handy for the most part of itsy bitsy changes and small coding errors... http://classghost.sourceforge.net

Jevgeni   |82.131.27.xxx |2008-05-30 17:16:37 Wow! It does ... nothing. At least nothing more than usual Java HotSwap.

Vimal  - Regarding Class Ghost     |203.197.168.xxx |2008-05-31 06:16:53 Jeevan, I see that class ghost is just providing a GUI for the built-in hot swap feature. Java Rebel does much more than that and does it automatically. Though I agree that rebel has its on different set of limitations, its Useful.

Only registered users can write comments!

Powered by !JoomlaComment 3.22

3.22 Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."