This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 247297 - Old code is running in JVM after "Code updated" is written to "Apply Code Changes" window
Summary: Old code is running in JVM after "Code updated" is written to "Apply Code Cha...
Status: NEW
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 8.1
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Assignee: Martin Entlicher
Depends on: 245453
  Show dependency tree
Reported: 2014-09-19 09:58 UTC by NukemBy
Modified: 2014-12-27 15:15 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description NukemBy 2014-09-19 09:58:12 UTC
If happens regularly in my environment that after I invoke "Apply Code Changes" command (typically via keyboard shortcut) I do receive messages "Code updated" in "Apply Code Changes" window, but nothing changes actually - code keeps running over old (already commented out) lines.

Expected behavior - if "Apply Code Changes" is invoked to a currently executing method stopped on breakpoint, call stack is rewinded to upper/caller method and I re-execute current method once again with new code base. It works this way in 50% of cases - and I have no clue when it works as expected and when it does not.

My environment is:

Application (ApacheKaraf-hosted bundles) is running in 

   java version "1.7.0_67"
   Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
   Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)


  Product Version: NetBeans IDE Dev (Build 201409150001)
  Updates: NetBeans IDE is updated to version NetBeans 8.0 Patch 2
  Java: 1.7.0_67; Java HotSpot(TM) 64-Bit Server VM 24.65-b04
  Runtime: Java(TM) SE Runtime Environment 1.7.0_67-b01
  System: Windows Server 2008 R2 version 6.1 running on amd64; Cp1251; en_US (nb)
Comment 1 Jiri Kovalsky 2014-09-19 11:23:16 UTC
Hello Sergey, what kind of applications is that? Maven or Ant based? JavaSE or JavaEE? I know that in Maven based apps it takes some time until the change is successfully applied (see Debugger console) so maybe you just hit Step Over too early.
Comment 2 NukemBy 2014-09-19 13:44:02 UTC
- Application is an OSGI bundle deployed into Karaf - I think this is close to 'anything' deployed into some Java application server (the simplest case is Tomcat are like). 

- I would say this is JavaEE staff, but I can't see differences in JavaSE and JavaEE in terms of debugging and JVM runtime.

- Bundle is built using MAVEN, but I suspect all MAVEN staff stays away when preparing the compiled java class for hot update and updating class in JVM.

- I'm pretty much sure this is not a timing related issue - I was waiting for quite long after "Code updated" message appeared (~15 seconds) - no success. And, anyway, I expect "Code updated" does mean code already updated ;)

- I feel that updating the class while JVM is not paused (or actually - when the class methods being updated are NOT in stack of any JVM's thread) has higher chance of success. Though I did have cases when code was actually NOT updated in these conditions too. And the main thing here - unlike the case with JVM stopped on breakpoint and consecutive visual effect of 'stack rewind' in this case here I may rely only on the message "Code updated" which is false positive in some percentage of case and was actually debugging old code while expecting new behaviour.

- I have impression that first "Apply Code Changes" after fresh attach to the Java process always fails.
Comment 3 NukemBy 2014-12-24 08:42:39 UTC
Still reproducible in latest dev builds :(, currently using

Product Version: NetBeans IDE Dev (Build 201412220001)
Java: 1.7.0_71; Java HotSpot(TM) 64-Bit Server VM 24.71-b01

With this bug my time is wasted twice - first one while trying to unsuccessfully reload classes, second time - while restarting the whole app.
Comment 5 Martin Entlicher 2014-12-27 15:15:58 UTC
Yes, this might be fixed by issue #245453. Thanks.