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

Bug 62120

Summary:

Package Explorer shows projects doubled

Product:

[Eclipse Project] JDT

Reporter:

Dirk Baeumer <dirk_baeumer>

Component:

Assignee:

JDT-UI-Inbox <jdt-ui-inbox>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

major

Priority:

CC:

philippe_mulet

Version:

3.0

Target Milestone:

3.0

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
The delta generated by Core	none

Description Dirk Baeumer

2004-05-13 11:59:47 EDT

I20040512_0010

The package explorer shows all projects except the first one double. This is 
caused by a race condition:

- on startup autobuild kicks in which resolves libarary containers
- main thread is populating the package explorer and is getting deltas
  sent out by the autobuild

An additional case happens when the package explorer has filters set. In this
case JFace fetches all children to check if the list is empty after filterung.

Although the package explorer is updating the viewer via async exec the 
runnable can be processed in main since Debug passes a null progress monitor 
to resolve the library container resulting in the fact the Core uses an 
aninamted progress monitor which runs the event loop from time to time. To fix 
the problem several alternatives exists:

- no free use of animated progress monitor
- JDT/Core doesn't sent deltas on reads (it doesn't sent deltas either when
  we populated a CU the first time)
- the package explorer content provided is reentrant aware
- launching doesn't use null to avoid animated progress monitor

Comment 1 Philipe Mulet

2004-05-14 05:37:14 EDT

Remember that the JavaModel is lazily populated, and that certain questions 
will trigger some initializations like for containers. In return to a 
container initialization, it will broadcast the changes discovered in there.
Note that it should be clever enough to not broadcast changes in case 
identical to previous session values.

Comment 2 Erich Gamma

2004-05-14 06:20:01 EDT

The best solution we have found so far is to implement re-entrance awarness in 
Viewer.setInput()

Comment 3 Philipe Mulet

2004-05-14 06:46:00 EDT

I would still want to understand the nature of the delta you are getting. 
Talking with Dirk it looks like a JRE delta, but nothing would have changed. 
Sounds suspicious to me.

Comment 4 Dirk Baeumer

2004-05-14 07:19:12 EDT

Created attachment 10644 [details]
The delta generated by Core

Comment 5 Dirk Baeumer

2004-05-14 07:19:30 EDT

Philippe, I have attached the delta.

Comment 6 Philipe Mulet

2004-05-14 10:44:53 EDT

I think the offending delta is a consequence of bug 61831.
Dirk, could you put more info in your trace so as to better see what is going 
wrong ? In particular, you should enable trace for classpath initializations.

Comment 7 Philipe Mulet

2004-05-14 10:49:54 EDT

Pls attach the enhanced delta to bug 61831

Comment 8 Dirk Baeumer

2004-05-14 11:05:42 EDT

Add trace to bug 61831

Comment 9 Erich Gamma

2004-05-16 19:14:59 EDT

The package explorer is now using a viewer which ignores changes during 
setInput. Dirk pls verify this in your setup.

Comment 10 Dirk Baeumer

2004-05-17 04:22:19 EDT

Verified in my setup and wasn't able to reproduce.

Comment 11 Erich Gamma

2004-05-17 05:09:14 EDT

thanks Dirk - closing

Comment 12 Philipe Mulet

2004-05-17 07:39:14 EDT

Re: comment #9. What if the change is actually relevant ?
If you start drawing the model in some state, which is changing as you go, we 
will update the model in memory, and broadcast a delta. This means that the 
picture you drew may have been changed in between, and you could have rendered 
some of the previous picture and some of the later picture.

I think it should instead try rendering until no more concurrent delta is 
broadcasted; and any delta notification would cancel the ongoing rendering 
(next iteration would try again).

Comment 13 Erich Gamma

2004-05-17 08:19:33 EDT

I agree but this change should be done in JFace in general and not by each 
client. This cannot be addressed in JFace now. Therefore for 3.0 this fix has 
to be good enough - moving to later

Comment 14 Denis Roy

2009-08-30 02:14:54 EDT

As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.