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

Bug 34919

Summary:	Setting classpath container initializer should be batched
Product:	[Eclipse Project] JDT	Reporter:	Martin Aeschlimann <martinae>
Component:	Debug	Assignee:	Darin Swanson <Darin_Swanson>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.1
Target Milestone:	3.0 M4
Hardware:	PC
OS:	Windows 2000
Whiteboard:
Bug Depends on:
Bug Blocks:	34776

Description Martin Aeschlimann

2003-03-13 10:53:22 EST

RC2

When the JRE is switched in the preference page, the preference page changes a 
preference value. The launching plugin listens to the change and as reaction 
loops over all projects to call the initializer of the project's JRE container

LaunchingPlugin$VMChanges.process() line: 212

Each call results in a JavaElement delta. This should be batched to minimize 
deltas. Best would be if this even is collapsed with the possible 'build'.

See also bug 34719. We also have a bug in the type hierarchy which together 
with the deltas here can result in a OutOfMemoryException

Comment 1 Darin Wright

2003-03-13 17:28:33 EST

Marking as RC3 candidate. Needs secondary approval from Erich.

Comment 2 Erich Gamma

2003-03-13 17:31:28 EST

approve

Comment 3 Darin Wright

2003-03-14 10:47:15 EST

NOTE: cannot collapse with the "build" as the build is performed from the UI 
(pref page), and the property change is handled in the core plug-in.

Comment 4 Darin Wright

2003-03-14 11:13:57 EST

The processing of property changes is now performed in a single workspace 
runnable. Added a busy cursor when OK is pressed on the VM pref page (since the 
proeprty change handling cannot display a progress montior).

Changes in LaunchingPlugin, and VMPreferencePage.

Comment 5 Darin Wright

2003-03-14 11:14:24 EST

Fixed. Please verify, Darin (S).

Comment 6 Darin Swanson

2003-03-17 17:23:28 EST

Verified code.

Comment 7 Martin Aeschlimann

2003-03-20 11:42:32 EST

Not fixed: JavaCore.run should be used instead of Workspace.run
The problem is still here and is also the cause for heavy flickering of the 
class file editor when changing or modifying the JRE (bug 34776)

Comment 8 Martin Aeschlimann

2003-03-20 12:43:04 EST

Another problem is that that in
JREContainerInitializer.requestClasspathContainerUpdate(IPath, IJavaProject, 
IClasspathContainer) line: 149
both
  standin.convertToRealVM();
  JavaRuntime.saveVMConfiguration();
lead to a call of 'process' creating a runnable that updates all classpath 
initializer of all projects

Comment 9 Darin Wright

2003-03-21 16:35:09 EST

Removing milestone.

Comment 10 Darin Wright

2003-09-12 13:53:24 EDT

Martin, I have updated the code to use JavaCore.run. However, I cannot 
reproduce the double call to #process() as indicated in comment #8. Is this 
still a problem (when using the latest JDT launching plug-in)?

Comment 11 Martin Aeschlimann

2003-09-15 09:55:22 EDT

Seems to be fixed. Couldn't reproduce either.

Comment 12 Darin Wright

2003-09-15 10:01:18 EDT

Fixed. The only change is to use JavaCore.run instead of Workspace.run.

Comment 13 Darin Wright

2003-09-15 10:02:45 EDT

..fixing...

Comment 14 Darin Wright

2003-09-15 10:03:01 EDT

Marking as verified, since Martin has verified the behavior.