Community
Participate
Working Groups
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 197307 [details] Protect JavaClass and MethodImpl after a flush occurs
approved
Committed to R3_0_5_patches