Community
Participate
Working Groups
Using the test program below, 1. Turn off autobuild. 2. Build the program in the original state 3. Place a breakpoint where indicated. 4. Debug to the breakpoint. 5. Change the string in method a() from "A" to "a" 6. Save. 7. Change the string in method b() from "B" to "b" 8. Save. 9. Build. 10. We only drop to method b() and a dialog appears stating that method a() is obsolete. If you swap steps 5 and 7 (change method b() before a()), we get the correct results. Having debugged this a bit, the problem relates to our story for retrieving the correct compilation unit delta for "smart" drop to frame. We end up comparing the final version of the source with the version after step 6. Comparing the deltas, it looks like a() hasn't changed, so we don't pop it. This is wrong. public class Hello { public static void main(String[] args) { new Hello().a(); } private void a() { b(); System.out.println("A"); } private void b() { c(); System.out.println("B"); } private void c() { System.out.println("C"); // BREAKPOINT HERE } }
It looks like a PRE and POST_BUILD event are still fired when autobuild is *off*, but no build occurrs - the builder fires the PRE_BUILD event, checks if it should run (deosn't), and then fires the POST_BUILD. DJ is checking into this, it may not be the correct behavior
This is specified behaviour (IResourceChangeEvent javadoc): * If autobuilding is not enabled, these events still occur at times when * autobuild would have occurred. Also, note that POST_BUILD events include a delta for all changes since the last POST_BUILD event. This includes projects that may not have been built. For example, if you change two projects but only build one, you will see both projects in the POST_BUILD delta. JavaHotCodeReplaceManager seems to be assuming that the delta only includes changes made by builders.
We have entered an enhancement request against core, see bug 77312. Can you add details there on your requirements?
I have just released some changes to resource change events that should allow you to address this. IResourceChangeEvent.getSource() will now return the project in case of single project builds, and the workspace in case of workspace builds. This will allow you to correctly update your table of last build times. IResourceChangeEvent.getBuildKind() will return the "build kind" that was used for that build (incremental, full, clean, auto). Again, this will allow you to correctly update your state. You will know that if the trigger is "auto" and auto-build is turned off, that it didn't in fact build anything. You can add feedback and further comments in bug 77312.
Fixed in JavaHotCodeReplaceManager. Instead of using a visitor to figure out which projects changed, I just use the two new methods to: 1. Only update the build state for a real build (no autobuilds with autobuilding off). 2. Get the built project (or all projects) from the resource change event. I also discovered that the HCR manager was removing itself as a resource change listener whenever all launches terminated. This makes sense for trying to perform HCR, but it's actually a problem related to our build timestamps. To be accurate, we need to keep updating when builds occur while there's nothing running. Otherwise, we end up thinking that everything has changed since the last build that occurred with a target running - which can be way too far in the past. Please verify, DW.
Verified. I did add an additional check for event.getBuildKind() == 0, so we ingore POST_BUILD notifications that are not applicable to a build kind. I couldn't make it happen, but it seems fair to check as 0 is part of the spec.
Just FYI, getBuildKind() only returns 0 for resource change events that are unrelated to builds, such as the PRE_CLOSE, PRE_DELETE, and POST_CHANGE event types. If you are only listening for build events, it shouldn't happen. Never hurts to put the safety check in though.
