[ https://issues.jboss.org/browse/JBIDE-18506?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-18506: --------------------------------------- {quote} by running initialization async, isn't there a chance that the screen resolution isn't initialized when it's requested (see #getScreenResolution(), line 107). Shouldn't we blocking wait for the screen resolution to be available? {quote} I don't think it can happen, because we first ask a user if he agrees JBT to receive usage statistics. The screen resolution will be called before that. Anyway, locking JBT/JBDS is a worse issue than an entry with invalid screen resolution in the statistics. {quote} Snjezana Peco could you please describe exact steps which may cause that lock? And could you also attach a stack trace in case we won't able to reproduce it? I agree with Andre Dietisheim, we cannot just replace syncExec by asyncExec. But we have to understand why syncExec locks Eclipse here {quote} I think we must never use syncExec in the plugin's start method. I have installed Eclipse Luna 4.4.1 SDK and updated JBT 4.2.0.CR1b on Linux, installed several SDKs (Sapphire, EMF, EGit, m2e, WTP...). The JBT freezes every time when starting in a new workspace. I have noticed this behaviour before, but using Luna 4.4.1 the issue is reproducible. -- This message was sent by Atlassian JIRA (v6.3.1#6329)