Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348221

Summary: JEM needs to handle a flush better (redux)
Product: [WebTools] WTP Java EE Tools Reporter: Carl Anderson <ccc>
Component: jst.jemAssignee: Carl Anderson <ccc>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: major    
Priority: P3 Flags: cbridgha: review+
Version: 1.5.5   
Target Milestone: 3.0.5 P   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 343559    
Bug Blocks: 348396    
Attachments:
Description Flags
Protect JavaClass and MethodImpl after a flush occurs none

Description Carl Anderson CLA 2011-06-03 10:49:13 EDT 
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.
Comment 1 Carl Anderson CLA 2011-06-03 10:52:08 EDT 
Created attachment 197307 [details]
Protect JavaClass and MethodImpl after a flush occurs
Comment 2 Chuck Bridgham CLA 2011-06-03 11:33:57 EDT 
approved
Comment 3 Carl Anderson CLA 2011-06-03 16:15:05 EDT 
Committed to R3_0_5_patches