A DESCRIPTION OF THE REQUEST :
As of JDK1.4.x it is possible to replace running "hot" code, as long as this does'nt affect the class' public signature in general.

  To really ease and speed development, this "hot code replacement" feature should be extended to include the possibility to alter class level and other "signature changing" operations (alter/add/remove methods and instance variables).

This would of course break serialization going out of the runing VM, but within the VM should be able to cope with the changning signature.

I believe, as far as I can remember, that the old  customer  Visual Age for Java tool had a similar capability, where it was possible to alter almost everything without a "reboot" of the VM.


JUSTIFICATION :
Ease Of Development!

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Hot Code Replacement extended to include class-signature changes within the single running VM.
(Incident Review ID: 192049) 
======================================================================
Posted Date : 2005-10-25 16:35:55.0

N/A

A number of years ago we invested in research in this area.
The paper "Towards Flexible and Safe Technology for Runtime
Evolution of Java Language Applications" by Mikhail Dmitriev
provides an overview of this research:

 http://www.experimentalstuff.com/Technologies/HotSwapTool/runtime-evol.pdf


At this time we have no plans to support arbitrary changes
to classes at runtime.

We are however conscious that a number of developers are
seeking the current restrictions to be relaxed in the
development environment. That is, for "fix & continue"
debugging developers are looking for ways to update classes
in the IDE/debugger without needing to restart the
application.  In addition there are tools that do
instrumentation looking to do limited changes. We are not
adverse to making improvements but it is a topic that
requires further research. To that end it would be useful if
developers voting for this RFE could detail their specific
requirements. Are people really looking to do arbitrary
changes and instance conversion? We view type safety and
application consistency as very important. One approach is
to relax the restrictions and allow for some limited changes
- for example, the ability to add methods would address many
scenarios. We aren't making any commitments at this time but
we are looking for feedback.

This forum thread would be an appropriate place to add feedback:
  http://forums.java.sun.com/thread.jspa?threadID=572396&tstart=0

We are interested in detailed information about specific features.
Posted Date : 2005-10-25 16:35:55.0

Extending RedefineClasses and RetransformClasses to allow the addition of methods and to allow some method attribute changes is currently planned for Dolphin.  However, Dolphin feature work has not been finalized. Also, because of the complexity of this work, it may only be supported for use during development.
Posted Date : 2006-03-21 05:12:15.0

I think implementing this enhancement would be the single largest boost to my productivity of all the requests in this database. I could probably save an hour each day.

I absolutely agree with Keith - this _needs_ to be done. Other languages (ie: Ruby) will pass Java by if we're stuck in the stone-age and have to wait for Hibernate, app server, servlets, filters, etc to initialize after each change.

Hot deployment of classes will greatly shorten the development lifecycle.

I vote for this too, it's the single most annoying part of the JVM I have to deal with daily. Without this restriction, regular Java development would be as agile as any scripting language.

I absolutely agree that this needs to be implemented ASAP.

This is really needed to keep up with some of the zero deployment languages/frameworks coming up lately.

they can come with all kinds of new language constructs but nothing would enlight me more than being able to move on. It is so annoying that i could go on for hours about it. hours!

to help the deployment /debug environment for client, scripting languages help a lot and hence pls. strongly consider fitting this in ASAP.

Would this eliminate the need to use classloaders to reload classes at runtime, effectively making my plugin engine (and the likes of Eclipse, NetBeans, etc) no longer need classloaders for individual plugins to be unloaded/reloaded?

support

Buckman - probably not, since this would be a debug-only feature. But still, the idea is the same: Java needs to be more supportive with this stuff. 

I understand that it isn't easy (class schema changes represent some serious challenges), but I believe Sun can work through them. Hell, it doesn't even have to be perfect, just as long as it works fairly well.

I imagine HotSwap could find all instances of the old Foo class, replace them with instances of the new Foo class, and do it's best to copy the state over. Changed fields and new fields could just be null -- it's better than what we have now for sure.

This is definitely worth doing.  I can't tell you how many questions I see along these lines.

This would be awesome.

It would be great to have this implemented soon. The productivity gains would be fantastic.

This is the only addition thats worth suns time now!!!

This feature is so important to compete with other languages. This will improve so much how fast and less boring to develope/debug java apps, mainly enterprise apps, who uses tons of frameworks. Consider this as a plea from the java community. Thanks.

Yes, that would be so cool. I've seen once an eclipse+tomcat plugin+tomcat conf having this behavior (compile and see the change instantly) but I could never reproduce it myself so I still wonder if I've been dreaming or not?

FIxing this would definately improve productivity

java's hot replace is too poor!!

I absolutely agree with Keith 

Saving time for developers! I strongly agree with.

I would appreciate this request considering the flexibility it lends to various tasks. In particuarl , the fact that features can be plugged-in and plugged-out is very attractive.

(None of the comments seem to be concerned with the issues for the implementor. For one, this involves re-linking with using-code, which might fail. I hope this isn't too much of  a headache since class loading already involves linking...).

+1

Agree that it will boost productivity.

I definitely say: +1.

./alex
--
.w( the_mindstorm )p.

this would be the ultimate

Not much for me to 2 than
+1 ASAP !!!

it looks to me that creating new instance fields would be a bit hard. Because then all instances that are now live in mem. Should be suddenly bigger. Because they all should hold a new field value (default to null??)
So if fields are hard to do please focus on methods.
Because when a method changes is the runtime instance of an object affected? Don't know the internals but i don't think so or not that great when adding a field.

As ours systems grow, more I think this insn't simple a good improve, but a must for J2EE development

it's definitly time for the vm to allow 'near-to-zero' turnaround time in development like rubyonrails does...

If this really gave us the ability to simply hit refresh in the browser to get the new code to load and run then it would be a HUGE productivity gain.  

This would be one of the best enhancements in years, especially when building web applications.

I have serious doubts about whether this could be accomplished in an unlimited sense, with a reasonable amount of effort and result in something that works really robustly... but if some portion of this can be done somehow, I'd love the addition.

This would save me an hour each day. I hope that this can be included.

This will greatly improve the experience of developing large-scale distributed application.

A vote from me, I agree with all the others probably the single most productivity increase ever.

ditto

Gets my vote!

From Mikhail 's research paper it looks like a non-trivial task. But the rewards are quite big as well. 

(a) Increase developer productivity

(b) Another strong feature for pushing the JVM in the Server side applications space.  

Reminds me something my computer science lecturer used to say 'we should all study biology instead of maths if we really want to create more realistic systems'.  We have developed technology to hot swap kidneys but not a bunch of bytes!  - yet. 

I vote 'yes' for this!

Yes , I COMPLETELY AGREE, THIS SAVES LARGE AMOUNT OF MY TIME. IT"S VERY, VERY IMPORTANT TO IMPLEMENT. 

I vote yes!!

I would agree this will enhance productivity in the sense that it would help speed debugging/development.  To answer your request for "detailed information about specific features", all I can say is that from my experience and from what all the comments in here are saying, this is really for development time only.  So, if security issues are the reason why SUN is hesitant to implement this, feel free to add additional security checks before enabling such a feature (-XXdisableHotSwapSecurity or whatever).  Something that would allow production systems to secure this feature (or at least allow development systems to disable the security).

-1 pointless; somebody has to say it.
I can't see any justification for this from my experience. Changes in fields are difficult to define (what values => potential broken invariants), changes in methods will generate heisenbugs with anything that caches reflection data (usually quite a reasonable move), and would require changes in multiple classes to be significant anyway.
Since the entire group of interacting objects must be regenerated to get consistent test results this use may be better addressed with hot deployment & class loader techniques.

>-1 pointless; somebody has to say it.

don't agree! How do we know how this will work out if never try it. And we should also have the possibility not to use it so you can still work how you want to. Classloader and hot deploy basically initializes your whole app thats not what we want

>-1 pointless; somebody has to say it.

I do not agree too. Even half-working solution for that problem is better that nothing we have as for now. 

Yes this must be implemented. As much flexibility as possible. At least the ability to: add instance variables, add/remove/modify method signatures.

Adding methods & fields (static and member) would probably be sufficient.

It would allow much greater productivity during debugging

I felt a big loss of productivity when I switched from Smalltalk - which of course was able to do something nowadays called hot code replacement 10 years ago - to Java. Even if IBMs VisualAge for Smalltalk was a temporary relief, the current situation even with HCR is still poor compared what was possible with Smalltalk more than a decade ago.

+1

JiAN

Need to be done!

need to be done!

FULL ACK. that it will boost productivity.

the proposal provided in the Evaluation addresses all of my needs, as far as I can stretch my imagination ;)

it is important too me

The most important feature about hot code replacement would be 1) Allow adding new methods to allow easier refactoring inside a class. 
2) Allow moving methods  up/down to super/subclass (to support ad hoc refactoring)  between class hierarcies
3) Support adding new instance variables 
4) For some reason currently making a refecence to any class (like MyComponent.class) always causes hot code replacement to fail, that kinda sucks ;)
5) Adding / limited changing is more important than removing currently
7) Support method signature changes (return type, parameters) 

This can't be stopped by things like 'it's breaking serialization' - it's a development feature and developers can decide whether they use it or not.
I won't repeat others in this forum - success of any programming language depends on success of developers that use it, therefore this is currently the most important RFE for Java, period.

This is a great feature.  First, I think it should be a JVM arg to enable/disable it since it should not be used in production unless you know what you are doing.  Second, I think this goes a long way in making Java a truely dyamic language.  I think the Hibernate folks and CGLIB folks have shown just how far the language can streatch, lacking true hotswap is a very strange thing to now allow -- even in a dev environment where data consitency is important, but certainly not mission critical.  Finally, allow the enviornment to determine how to recover from data inconsitency problems.  Most of these will be recoverable or manageable by the developer since it was the developer who swapped the code.  Thanks! 

This limitation not only wastes hours of my time, it also causes my code to suffer: in cases where I ask myself "is this block of code getting big enough that it should be its own method?" the prospect of twiddling my thumbs waiting for my app server, Hibernate, etc. to restart makes me say "no, leave it where it is" more often than I otherwise would.

I agree with the earlier commenter who said that even if adding/removing fields is too hard (because existing instances would have to grow/shrink) it would still be a huge improvement to be able to add and remove methods and change the signatures of existing methods.

Please make this happen!

Most of the "voices" speak from a developers point of view.
Consider running a web application which needs to be available 24x7 and in the midle of the day a guick fix is mandatory. It would be excelent to be able to install the patch without shuting down the application.
TM

> Consider running a web application which needs to be
> available 24x7 and in the midle of the day a guick fix is
> mandatory.

Wouldn't you just take down and upgrade one server in your cluster, bring it back, then do the next server, etc? That's how I have always done it.

Surely you are not running an "application which needs to be available 24x7" without clustering? :-)

Those who consider hot replacement "a huge productivity boost": do you use jUnit? Really systematically use it?

Adding methods alone would be a great improvement. Adding other aspects of object would be, too, but I understand this would be harder. (e.g. fields, static fields [esp. constants], etc.)

This feature will save much hours of long 
recompile / restart. 

To implement this feature, you will need to analyze the change. Classes consist from logic and data. 

1. If only methods are changed (added / removed / signature changed), then there will be no impact on existing instances. The only problem is with "Method"s that some reflection caches might support (for example, jakarta common-beanutils), but this is out of scope.

2. If data fields were deleted -- that's OK. 

3. If data were added, this needs some thinking. Case when there are no strong reachable instances is very common (like, if class instance can be garbage-collected), so it's obvious to implement this.

Another case is when part of instances is reachable, and some data are added. There is a danger of violating class contract / invariant if there was one, so maybe a warning needs to be introduced to developers -- if instances have fields with values that are different from defaults. 

If class does not have complex invariant, or can tolerate "sudden change", then conversion procedure needs to be invoked (like copying during garbage collection). There, space for additional fields are added to instances.

at least method and field additon would be great progress.

As Derrida points out in "Plato's Pharmacy" the Greek word "pharmakon " means both "cure" and "poison".  This seems to be what one is going to receive.  What exactly is going to happen when a synchronized block or an object being synchronized on is hot swapped out in ones production system?  For extant objects in ones production system, which finalizers are going to be run?  The Java Language is very clear on how the 'equals' operator is to work e.g. reflexive, symmetric, consistent, and equal objects have the same hash code.  After the hot swap will old and new objects be able to maintain these invariants.  If one adds fields to an object and redefines the hashCode() method or just redefines the hashCode() method, one may orphan the existing objects that have been placed in HashMaps.  Someone pointed out that adding a method should be harmless but if that method overrode a base class method, the base class would now call the overriding method instead.  Since it looks like the JIT might start using escape analysis to remove unneeded synchronization blocks and reorder statements, suddenly hot swapping in a code change could start a whole cascade of changes where the language rules might require some synchronization blocks to be put back, the already executed statements reordered again and since everything is quite different at this point it is probably just best to throw an Error or ThreadDeath.  I am also concerned how this will be compatible with ASM/BCEL/CGLIB/Aspectj/Hibernate/Spring and a lot of technologies that are built on top of them.  For debugging and rapid prototyping this may be fine but this does not seem to be something to consider for a production system.

I'm a pampered WSAD programmer now stuck with Weblogic on Eclipse. The single most important productivity hit I have taken in my opinion is that I cannot see my changes to Java classes right away. I did implement the Weblogic plugin that picks up changes to classes so long as schema changes are not involved, but am obviously limited by not being able to add members and methods. I understand this is not an easy feature to implement because of all the implications on the JVM, but this would certainly be a great feature to have. I whole-heartedly vote for this improvement.

I vote 'yes' also--this would be a huge productivity boost.

If this would come for free (no performance impacts, stability problems) - why not? Well as I write this I am not so sure any more: How do I manage my reflection-based glue-code which analyses existing classes? One could argue that the code I wrote is rather exotic, but right now it is possible and stable _because_ the limitations exists.

If a general feat like class-versioning existed, it would be a different story. If Java should provide a meta-programming like in CLOS - perhaps it will be a feature toi frighten ordinary users just to give pleasure to freaks like me.

This would be great, it's so annoying at the moment. I'm sure hotswap was working much better in IBM visualage, now that all the IDE's plugin to the sun hotswap they are all half broken (including eclipse, and IntelliJ).

Last I checked you cannot change a method

void m() {
  field.setText("hello");
}

to

void m() {
  EventQueue.invokeLater(new Runnable() {
    public void run() {
      field.setText("hello");
    }
  });
}

From the developer's perspective, these have the same signature; the generation of a separate .class file by the compiler is an implementation detail. I cannot think of a good reason for such a transformation to be rejected.

I agree. Having rapid feedback of changes in code is more important than any other feature to me. This is essential to rapid learning and development. Mert Nuhoglu

I don't agree that it is needed.  The risk vs. reward is too high.  The developers twiddling thumbs waiting for huge applications to restart need to investigate into better ways to unit test their apps.

That being said, it would be nice to be able add (not override) new members, but that leads to slippery slope, i.e. can I rename (delete then add) as well?  Arbitrary re-definition, I do not need to be efficient.

Whaterver relaxation in this regard can be given without harming the existing system, should be given. This will enhance productivity.

I think this would boost development especially of web applications tremendously. Currently I'm restarting tomcat 50 times a day which takes about one minute, so I would gain 50 minutes of productivity each day.

Such improvement would be a blessing!

I've expect the feature since I learnt Python!

I think that hot deploy will easy upgrade process for some small servers written in Java without stopping JVM or the server it self - just like J2EE servers support hot deploy for apps. It could be beneficial for IDE/Test tools too to alter the program code without loosing runtime/debug information. Support for continuation will also be a great feature

I could probably save an hour or two each day from one of the following:
1) This enhancement is implemented
2) Switch to Ruby
At the very least, getting dropping Java entirely would get me away from the headaches and annoyance that not having this implemented causes. Unless this is implemented soon, I'll definitely be switching development platforms.

"At this time we have no plans to support arbitrary changes to classes at runtime." i.e. They are saying "Nope, we really don't like the idea, and don't give a crap since it doesn't effect our productivity, and only makes other poor saps that actually use Java look like slow incompetent fools." Time to switch to better technology and learn Ruby, Python, php, etc. So long Java, you're lousy for web development.

I would say that nobody from SUN cares about what we think or need and I'm not sure that they even read this comments. After a whole year  of comments there is no single answer or action from them. Such an implementation could save me couple of hours every day but  20 hours in a room where I'm siting right now. That's such a waste of time.

I even vote for this enhancement. But this should be only restricted only for the DEBUG mode. I hope this enhancement is going to bring revolution(in esimations) in the java development projects.

FYI, there is typo in the URL posted in the evaluation section. The correct URL for the forum thread is http://forum.java.sun.com/thread.jspa?threadID=572396&tstart=0

everybody that wants it now i see that IBM J9 (which is java 5 based) is already supporting method changes/additions

http://www-128.ibm.com/developerworks/java/jdk/eclipse/

(included in this SDK)

Hot deployment of classes will greatly shorten the development lifecycle.

>> Would this eliminate the need to use classloaders to reload classes at runtime?

From:

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


A common solution to make highly important, mission-critical systems run non-stop, is to design them in a special way and/or run them on a specially configured, redundant hardware. In the case of applications written in the Java™ language, custom class loaders are often used to implement dynamic class updating.
However, it is widely realized that custom class loaders are not an ideal solution. One problem with this approach is incompatibility between instances of versions of a class created by different class loaders. That is, you cannot re-use previously created objects with the new class version even if the object format is the same for both classes, and you may need to write additional code to migrate objects to the new class. The most general problem with custom class loaders, however, is that this solution does not support unanticipated class evolution. That is, you have to write your application such that it anticipates which classes may be updated, and has a means of interacting with the user/administrator, retrieving the new class version, installing it, etc. This does not make your application more readable or easier to maintain, and only supports updating of a limited subset of classes.

The HotSwap project addresses the above issues by providing the capability to dynamically update classes at the JVM level. That is, any class can be redefined on-the-fly by attaching a dedicated tool to the running JVM and invoking a special API call that takes an existing class object and the new class version in the form of a byte array corresponding to the .class file.

A natural question that many people ask at this point is: what happens to the active methods of the updated class? The answer is: in our current implementation, all invocations of old methods are allowed to complete, whereas all method calls initiated after class redefinition go to new methods. One may think of other method replacement policies, for example, "wait until there are no active invocations of methods of the class to be redefined" (if such a state is ever achievable). See the discussion of various method replacement policies in our research publications.

It can improve producitity during coding through hot deployment really.

I think this will improve programmer's productivity a lot!

very important !

I don't know why Sun cannot open eye to see real requirement, this enhancement was introduced long long ago, but it did not be implemented up to now.

Yes, It's very important to make our life easier!

In addition, if you feel it hard to support hot swap any kind of modification of class, hot swap the resource first, please .
You know, the Spring , Struts, and Hibernate frameworks are very popular, and All these frameworks employ the XML resources. If these reources can be hot swapped, it's also a wonderful improment !

I agree that this would address the pain of fixing issues. I also feel that providing hotswap functionality for production instances is a terrible idea and most audits would fail you on that.

This simply helps developers be more "agile" when fixing issues in a development scenario. 

I can understand why it's probably lower-priority than other issues, since running production instances of large server apps works fine today and have agreed release processes anyway.

I work in heavy duty financial services with aggressive SLA's, but we still manage to have low downtimes.

How about this for an interim solution: create an agent that intercepts class loads, and replaces it with a class with a whole bunch of extra method and field stubs.  This way when can keep adding methods and fields.  For instance if there a method called "foo()", it'd add "foo_hs_1()", "foo_hs_2()", etc.
When you change a class' method signature, and everything was re-compiled properly, a live class object reroutes the previous method to the newly created method.  Don't know how to solve the argument problem, but it's probably solvable using the byte codes.
Things that are not possible could simply throw runtime exceptions, so you won't have to bring your program down if you cross the line...

Heck, why doesn't SUN, just buy Zeroturnaround! Or may be with Oracle acquiring SUN, they might do it!
++1++ for hot code swap!

-kodeninja

Java developers are at a huge disadvantage when it comes to being able to develop with repaid turn arounds. This will drive people to more developer friendly platforms.

We need this capability yesterday. It will probably be the single most developer productivity booster for the Java platform.

-sud

the JavaRebel guys have already created this, why were they able to do it faster than Sun?