Community
Participate
Working Groups
Created attachment 179297 [details] Project to reproduce the problem Steps to reproduce: 1) Install the Android Eclipse Tooling from http://developer.android.com/sdk/index.html (I am using Android API version 8) 2) import the attached Project 3) open com.example.android.skeletonapp.SkeletonActivity and go to line 57 4) insert . --> wait ~4 sec 5) start typing set '-->' wait between 10 and 30 sec. The next time it seems to be faster but it still takes up to 5 sec. I think this issue is major or even critical as it makes Eclipse hardly usable in such scenarios.
Bernd, please answer the following questions: - which build id? - on top what exactly did you install it? - do you see the problem when installing on top of 3.6.1 from here: http://download.eclipse.org/eclipse/downloads/drops/M20100909-0800/index.php - does Android install its own content assist proposal kind(s) (Java > Editor > Content Assist > Advanced)? If so, does the problem go away if you restore the defaults?
(In reply to comment #1) Hi Dani, > Bernd, please answer the following questions: > - which build id? Eclipse: - Version: 3.6.0 - Build id: I20100608-0911 > - on top what exactly did you install it? Classic Eclipse Distro http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.6-201006080911/eclipse-SDK-3.6-win32-x86_64.zip Later I installed WTP, EGit and the Android Tooling. I'll attach the configuration for you. > - do you see the problem when installing on top of 3.6.1 from here: > http://download.eclipse.org/eclipse/downloads/drops/M20100909-0800/index.php I have not tried yet, but I'll do and let you know. > - does Android install its own content assist proposal kind(s) (Java > Editor > > Content Assist > Advanced)? If so, does the problem go away if you restore the > defaults? No, there are just the normal entries
Created attachment 179311 [details] Configuration
I tried 3.6.1 now as well, same issue.
I tried to reproduce using your project but couldn't. Please note that Android Development Tools is only supported for 3.5 or lower. You can check that http://developer.android.com/sdk/eclipse-adt.html says "Caution: There are known issues with the ADT plugin running with Eclipse 3.6. Please stay on 3.5 until further notice". So can you please use 3.5 instead? It doesn't seem like an eclipse related issue since you're only facing this on completion of Android proposals.
(In reply to comment #5) > I tried to reproduce using your project but couldn't. Please note that Android > Development Tools is only supported for 3.5 or lower. > You can check that http://developer.android.com/sdk/eclipse-adt.html says > "Caution: There are known issues with the ADT plugin running with Eclipse 3.6. > Please stay on 3.5 until further notice". > > So can you please use 3.5 instead? It doesn't seem like an eclipse related > issue since you're only facing this on completion of Android proposals. I have just downloaded Helios 3.6.0 Java EE build. Cleanly. First time. Few times on different computers. The assist issue has been reproduced. I had not such problem with 3.5. It is definitely 3.6.0 issue.
(In reply to comment #6) >[..] > I have just downloaded Helios 3.6.0 Java EE build. > Cleanly. First time. Few times on different computers. > The assist issue has been reproduced. > I had not such problem with 3.5. > It is definitely 3.6.0 issue. Since you dont have the issue with 3.5, it only makes it more probable that its an issue with ADT and not eclipse. Can you please stick to 3.5 for android development?
(In reply to comment #7) > (In reply to comment #6) > >[..] > > I have just downloaded Helios 3.6.0 Java EE build. > > Cleanly. First time. Few times on different computers. > > The assist issue has been reproduced. > > I had not such problem with 3.5. > > It is definitely 3.6.0 issue. > > Since you dont have the issue with 3.5, it only makes it more probable that its > an issue with ADT and not eclipse. Can you please stick to 3.5 for android > development? I dont use any ADT. I just wrote it because I dont like when such ordinary thing like assist working so slow.
(In reply to comment #8) [..] > I dont use any ADT. I just wrote it because I dont like when such ordinary > thing like assist working so slow. I think you said you installed Android Tooling. Didn't you mean that you installed Android Development Tools(ADT) plugin?
(In reply to comment #9) > (In reply to comment #8) > > I dont use any ADT. I just wrote it because I dont like when such ordinary > > thing like assist working so slow. > > I think you said you installed Android Tooling. Didn't you mean that you > installed Android Development Tools(ADT) plugin? That was Bernd, the original reporter. John doesn't seem to have implied he installed ADT from comment 6. If the Java EE build is the installation in question, it may be related to bug 317979.
Hi, I just checked again with 3.5 and I have the same issue there as well. Some days ago I talked to Jochen (CC) and he indicated that he can see the problem as well. Bernd
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > I dont use any ADT. I just wrote it because I dont like when such ordinary > > > thing like assist working so slow. > > > > I think you said you installed Android Tooling. Didn't you mean that you > > installed Android Development Tools(ADT) plugin? > > That was Bernd, the original reporter. John doesn't seem to have implied he > installed ADT from comment 6. Oops, i didn't notice. Bernd, I'm still unable to reproduce with your project. Can you please attach a thread-dump so that we can investigate?
(In reply to comment #0) > Created an attachment (id=179297) [details] > Project to reproduce the problem > > Steps to reproduce: > [...] > > I think this issue is major or even critical as it makes Eclipse hardly usable > in such scenarios. I have excatly the same problem, Eclipse 3.6.0 and Android Eclipse Tooling (version 0.97 and latest 0.99 - both the same problem). Makes Android/Eclipse development paniful ...
(In reply to comment #13) >[..] > I have excatly the same problem, Eclipse 3.6.0 and Android Eclipse Tooling > (version 0.97 and latest 0.99 - both the same problem). Makes Android/Eclipse > development paniful ... Do you also have this problem on Android proposals, or usual java proposals as well? Side note: I want to reiterate that ADT is not compatible with Helios.
(In reply to comment #14) > (In reply to comment #13) > >[..] > > I have excatly the same problem, Eclipse 3.6.0 and Android Eclipse Tooling > > (version 0.97 and latest 0.99 - both the same problem). Makes Android/Eclipse > > development paniful ... > > Do you also have this problem on Android proposals, or usual java proposals as > well? > Side note: I want to reiterate that ADT is not compatible with Helios. Looks, like this is a common problem, ADT with Helios: http://www.listware.net/201007/android-developers/30746-android-developers-eclipse-helios-36-code-assist-very-slow.html
After setting up a new workspace on 3.5 with ADT it is working again. So it seems to be indeed an 3.6 issue (which seems to remain if you use an 3.6 workspace in 3.5...). What would you need in order to verify that it is an ADT and not a JDT issue?
Cross-posting the respective issue in the ADT bug tracker: http://code.google.com/p/android/issues/detail?id=10855
Thanks a lot Bernd and Greenender for confirming that this issue is specific with Android and Helios. What amazes me is that despite the explicit specification on the Android website about incompatibility of ADT with Helios, people are still trying to use the latter! Why not just use 3.5 and code hassle-free ;) Bernd, thanks for posting the issue on the android site. Can you provide a stackdump using instructions given on http://wiki.eclipse.org/How_to_report_a_deadlock. This should confirm whether the ADT plugin is coming into picture or not. Thanks
(In reply to comment #18) > Thanks a lot Bernd and Greenender for confirming that this issue is specific > with Android and Helios. What amazes me is that despite the explicit > specification on the Android website about incompatibility of ADT with Helios, > people are still trying to use the latter! Why not just use 3.5 and code > hassle-free ;) Well :-) To be quite frank, I did not read this until you pointed me to this section. I guess it is a classical situation for RTFM (or replace manual with installation instructions in that case...) :-) > > Bernd, thanks for posting the issue on the android site. Can you provide a > stackdump using instructions given on > http://wiki.eclipse.org/How_to_report_a_deadlock. This should confirm whether > the ADT plugin is coming into picture or not. Thanks I am currently on a trip. Once I am back, I'll attach it here.
(In reply to comment #19) > [..] > I am currently on a trip. Once I am back, I'll attach it here. Any news on this?
I just tried to reproduce this but somehow it is gone for now. I'll now run visualJVM in parallel to Eclipse and as soon as I can reproduce the problem I'll attach the dump Bernd
(In reply to comment #21) > I just tried to reproduce this but somehow it is gone for now. I'll now run > visualJVM in parallel to Eclipse and as soon as I can reproduce the problem > I'll attach the dump > > Bernd Did you see this again?
Funny :-) I was just about to send an update... I got informed this morning about this isses in the Android bug tracker: http://code.google.com/p/android/issues/detail?id=7850&q=adt&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars#c7 The issue reports a frozen Eclipse due to a wrong source location in the classpath container. Actually for debugging reasons I manually installed the android sources around the same time I was switching from Eclipse 3.6 back to 3.5. Now after working again with 3.6 the issue did not occur anymore. After renaming the expected source location again I can reproduce the problem again (See thread dump attached) HTH Bernd
Created attachment 181089 [details] dump
Created attachment 181091 [details] dump the new dump was taken faster after hitting ctrl+space
(In reply to comment #23) Thanks a lot Bernd for confirming this. So seems like this issue has been fixed by the Android dev team and shouldn't be a problem. Jay, can you please check if we can be more robust in such a case when the source location is incorrectly specified?
There must be more to it: bug 329288 reports a similar issue but the user isn't using Android Tooling. It looks like in both cases the time is wasted while fetching the parameter names.
As I replied in another similar Eclipse bug thread: I had this problem and I tried the workaround suggested at this page, comment #8: http://code.google.com/p/android/issues/detail?id=7850#c8 and it definitely worked for me. Before doing that I had all the mentioned problems, specifically when accessing code complete for Android View objects (complete freeze for ca. 15s, code completion window on top of *every* other window). To a lesser extent there were also problems when accessing Activity objects. My dev enviroment: Windows 7 64bit Eclipse IDE for Java Developers Version: Helios Service Release 1 Build id: 20100917-0705 java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing) Android Development Toolkit Version: 8.0.1.v201012062107-82219 I typically run Android SDK Platform 2.2_r1 Revision 2 API 8
Eclipse 3.6 SR1 "basic" for Java, Windows 7/64, Android ADT 8.0.1 There is an issue separate from the "sources" described above. Android now includes a JavaDoc package. If this is installed, code assist still freezes from time to time. Typically, this happens when code assisting a reference of a View subclass. Uninstalling the Android JavaDoc package resolves the issue, but JavaDoc in code assist is obviously lost. Same Android JavaDoc package works without a single hiccup with Eclipse 3.5 SR2 (same computer). See here for an explanation by someone more knowledgable in Eclipse than I am: http://groups.google.com/group/android-developers/browse_thread/thread/125fbab9f4f717b1/ The JavaDoc Android package is installed by Android SDK Manager, it's called "Documentation for Android SDK, API9, revision 1". I can submit it here as an attachment if needed.
Update on this issue with Android tools installed: Apparently this is a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288. I just tested a patched org.eclipse.jdt.code from here: http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba which is the fix for 329288 backported into 3.6. The fix worked, content assist is fast again, and includes JavaDoc. Is there any way to release this fix with 3.6 SR2? Seems like a pretty important issue, not limited to Android development, and the fix is pretty simple.
(In reply to comment #30) > Update on this issue with Android tools installed: > > Apparently this is a duplicate of > https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288. Yes, your'e right. We fixed this for 3.7, but didnt really backport to 3.6.x. Lets take this discussion into bug 329288.
> > Apparently this is a duplicate of > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288. > > Yes, your'e right. We fixed this for 3.7, but didnt really backport to 3.6.x. > Lets take this discussion into bug 329288. Ayush, looks like this can be closed, right?
(In reply to comment #32) > > > Apparently this is a duplicate of > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288. > > > > Yes, your'e right. We fixed this for 3.7, but didnt really backport to 3.6.x. > > Lets take this discussion into bug 329288. > Ayush, looks like this can be closed, right? Yes, according to comment 23, this was a bug in Android and not Eclipse. So closing as NOT_ECLIPSE
(In reply to comment #33) > (In reply to comment #32) > > > > Apparently this is a duplicate of > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288. > > > > > > Yes, your'e right. We fixed this for 3.7, but didnt really backport to 3.6.x. > > > Lets take this discussion into bug 329288. > > Ayush, looks like this can be closed, right? > > Yes, according to comment 23, this was a bug in Android and not Eclipse. So > closing as NOT_ECLIPSE Comment 23 is another issue entirely. This one is, or rather was, an Eclipse bug, please refer to https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288 - it was fixed and released with 3.6 SR2.
(In reply to comment #34) > Comment 23 is another issue entirely. Comment 23 is a follow up by the reporter of this bug and corresponds to the same issue reported in comment 0. Comment 28 and 29 talked about the other issue which is fixed in bug 329288. > This one is, or rather was, an Eclipse bug, please refer to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288 - it was fixed and > released with 3.6 SR2. The issue in 329288 corresponds to a problem in fetching javadoc. There's no such problem in this case as reported in comment 0. Wrong source location in the classpath container of Android was the problem in this case, and this has been resolved by the Android dev team.
Verified for 3.7M6.
