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

Bug 354268

Summary:	Thread "Compiler Processing Task" is still affected by bug 322928
Product:	[Tools] Objectteams	Reporter:	Stephan Herrmann <stephan.herrmann>
Component:	OTEquinox	Assignee:	Stephan Herrmann <stephan.herrmann>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	stephan.herrmann
Version:	2.0
Target Milestone:	2.8.2
Hardware:	Other
OS:	Linux
Whiteboard:

Description Stephan Herrmann

2011-08-09 11:41:50 EDT

Bug 322928 mentions that under OT/Equinox threads that are explicitely
created/started given a plain Runnable still have a problem.

This effects only OT/Equinox settings because in plain application mode
the OTRE weaves into all run() methods, whereas OT/Equinox doesn't look
into all classes.

In real life the thread "Compiler Processing Task" is a victim of the
current incompleteness of our solution. This thread is started by
org.eclipse.jdt.internal.compiler.ProcessTaskManager and if 
deactivate() + activate() is called for a team, activation is not
restored for that particular thread.

Bug 322928 also mentions that this situation is rare within the Eclipse SDK.
But here we have a relevant witness. Not sure if a general solution is
feasible or if we should add special case behavior for this thread.

Comment 1 Stephan Herrmann

2018-06-05 16:19:39 EDT

Bulk move to 2.8

Comment 2 Stephan Herrmann

2020-03-06 16:59:23 EST

bulk move to 2.8.1

Comment 3 Stephan Herrmann

2023-07-11 17:22:23 EDT

The original mechanism as of bug 322928 was dropped during the migration bug 406518, and later re-implemented in bug 413857 (which actually links here).

Later bug 493556 introduced the option to restrict thread weaving to one of { Never, Base, Always }

Given that bug 413857 did include handling of Runnable implementations, I'm assuming this issue to be fixed.

Additionally, team org.eclipse.objectteams.otdt.internal.compiler.adaptor.CompilationThreadWatcher (from the initial commit) seems to address this same issue of extending activation to the newly created thread.

I'm reluctant, however, to remove the extendActivation() trick.