Description:
Steps to reproduce:

1) Create a new project
2) Insert a statement in the Page1 page bean constructor and add a breakpoint to it.
3) Deploy in debug mode
4) After the program stalls at the breakpoint, insert another statement after
the breakpoint and select Run/Apply Code Changes.
5) Output reports 'build failed' and application seems to have shut down.

Description (Entry 2):
NOTE to Marco: Temporarily removing the waiver due to the fact that Quality
Council more information as to when this happens and what the customer impact
is.  Please provide this information as add the WAV keyword back to the bug.

Description (Entry 3):
This is approved for waiver as long as the option is greyed or removed.  Mark
Dey will follow up on this.

Evaluation:
Looks like a regression from insync.

Evaluation (Entry 2):
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
Compiling 1 source file to C:\Documents and Settings\Po-Ting Wu\My
Documents\Creator\Projects\WebApplication34\build\web\WEB-INF\classes
compile-single:
Classes to be reloaded:
 webapplication34.Page1
C:\Documents and Settings\Po-Ting Wu\My
Documents\Creator\Projects\WebApplication34\nbproject\build-impl.xml:484: The
following error occurred while executing this line:
C:\Documents and Settings\Po-Ting Wu\My
Documents\Creator\Projects\WebApplication34\nbproject\build-impl.xml:186:
com.sun.jdi.InternalException: Unexpected JDWP Error: 32
BUILD FAILED (total time: 0 seconds)

Evaluation (Entry 3):
I don't know with which JVM the original bug was filed. But I  tried to
reproduce it with 1.5.0_04-b05 andd get interesting results:

* On an empty page I can fix & continue and eveything seems to workk as it
should. But it's not very useful.

* On a page with a StaticText I run into problems recompiling after my update. I
don't
believe anything (of the fix&continue) has hit the AppServer yet.

The Output for the StaticText case:
---------------------------------------------------------------------
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
Compiling 1 source file to
/export/home/marcow/Creator/Projects/debug2/build/web/WEB-INF/classes
compile-single:
Classes to be reloaded:
 debug2.Page1
/export/home/marcow/Creator/Projects/debug2/nbproject/build-impl.xml:484: The
following error occurred while executing this line:
/export/home/marcow/Creator/Projects/debug2/nbproject/build-impl.xml:186:
java.lang.UnsupportedOperationException: schema change not implemented
BUILD FAILED (total time: 0 seconds)
-------------------------------------------------------------------------

The `schema change not implemented' seems to come out of the JDK's tools.jar.

Eric, do you have any idea on that?

Evaluation (Entry 4):
Ok, I looked at it again. And the fix&continue seems to work with the new JVM.

But only for very minor fixes. For bigger changes (like adding an automatic
variable to a method the com.sun.tools.jdi.VirtualMachineImpl will throw the
execeptions which I reported previously. That looks like a JVM implementation.

I'll mark this bug as fixed. (but the usefulness is limited!)

Evaluation (Entry 5):
It looks like the problem on XP still exists:-( So there is a difference
possibly caused by the debug-transport mechanism:-( On Linux/Unix we use
tcp/port based transport, on Windows we use shared_memory transport.

But I can't do anything here:-( I filed a bug for the JVM, but I don't know what
we will find out. All this code is either NB unchanged or JVM.

Evaluation (Entry 6):
We will remove this feature from the debugger tutorial.

Evaluation (Entry 7):
I think we found the problem in `our use of Java beans' and the JVM's handling
of it. The JVM uses native methods to do the reflection calls, but then it can't
handle the popFrame on those native methods.

The JVM has opened CR 6333572 on that.

---------------------------------------------------------------------
Sundar says:

Reflective calls (Constructor.newInstance
and Method.invoke) go through native mechanism upto a threashold
number of calls. If the same Constructor/Method is reflectively called
more than the threshold number of times, then reflection speed-up
classes are generated and loaded. These speed-up classes will then
make direct calls (invokespecial/invokevirtual). The default value of
this threshold is 15. There is an undocumented System property by
which this can be changed. There is also another undocumented system
property to completely switch off this thresholding (known as
"inflation") process. The inflation process is done to avoid startup
penalty on applications that use heavy reflection code. 

The interger valued system property
"sun.reflection.inflationThreshold" can be set to change the default
of 15. (but no, setting it to '0' does not work-- with inflation,
native access is used atleast once). But, the boolean system property
"sun.reflection.noInflation" controls whether native access is used at
all. Default of this is false. If set to true, first reflective call
will generate speed-up bytecode. If you don't want to have native
reflective access at all (and accept the startup cost-- which I guess
is fine in development environments), you can set this property. That
may workaround the popframe issue.  

May be, should we consider doing this by default depending on the JVM
TI capabilities?
-------------------------------------------------------------------------

I tried to add that property in our wrapper around the PEMain class when it's
running as `debugging enabled' but that does not seem to work as expected:-( 

So we can only waive that for now:-( [Maybe we should even remove/disable the
action completely?]

Evaluation (Entry 8):
Bug 6335653 has been filed to remove the feature for Thresher.

Workaround:
-