Community
Participate
Working Groups
The same fixes that were rolled into 3.0.5 P need to be rolled into 3.2.5, 3.3.1, and 3.4. +++ This bug was initially created as a clone of Bug #348221 +++ Continued work on bug 343558 yielded one other set of fixes - the iteration at the beginning of JavaClassImpl.collectMethodsExtended() needs to be moved to a copy of the array to avoid a ConcurrentModificationException, and MethodImpl.getReturnType() needs to have the same sort of guard as was added for its parent. +++ This bug was initially created as a clone of Bug #343559 +++ We need to get this fix into WTP 3.0.5 P, too. +++ This bug was initially created as a clone of Bug #343558 +++ Currently, if JEM is gathering (or has gathered) the Methods from a (JEM) JavaClass, and a flush() occurs, the Methods are removed from their parents and are invalid, resulting in NPEs and other errors without any warning. There are things we can do, such as replacing the parent JavaClass with a JavaClassRef, that will at least keep the current Methods useful, while still allowing the flush to proceed.
Created attachment 197448 [details] Protect JavaClass and MethodImpl after a flush occurs
approved
This was committed to R3_2_maintenance on June 13 for WTP 3.2.5
Committed to R3_3_maintenance and HEAD for WTP 3.3.2 and WTP 3.4.0 M3