I get this error pretty frequently when using “go to implementation”, “peek at declaration”, etc. As the error suggests, it seems to be a bug in initialization - the only fix I’ve found is to quit & re-open the IDE, but if it works correctly the first time then it works correctly for the remainder of the session.
I was getting this bug in Water and had not yet reported it, and I’m now getting it in Fire as well after moving to a MacBook. I took a screenshot of the error but couldn’t copy the text. I assume the message is in a log somewhere, but I’m not sure where the log file is. I can past the text here if someone can point me to its location.
Well. Java .jar files are zip files archives. To compile, and for code completion, the compiler needs to unzip them to look inside. That’s what fails here for one (or possibly more) of the archives. In order to fix this, it would time important to know which exact files are being used.
FTR, I cant reproduce it with just that. Pasted all these references in, CC & GTD still works fine . Do you have any more specific steps that might help repro this? dopes it fail form you EVERRYwhere or just on specific type/set of code?
it fails from everywhere for me. I can try setting up a test project in the same way I have this project to see if I can repro. I have a lot of code in a shared project, with an Android App and an Android Test project using the shared code. That also means that some of the libs are included in the Test project as well, which I suppose could be important to repro.
try replacing this one in Fire.app/Contents/Resources (Fire needs to be restarted, and you might need to resign it with codesign -s - /path/to/Fire.app. Then open the Activity Window (via the Windows menu and try to trigger the error.
(It’ll prolly work with last weeks Fire; if you get weird errors about Coope rat being supported, you might need to wait for today’s; that means the .dlls didn’t match anymore with the rest.
With the new dll I’ve reopened the project and tested several times and haven’t seen the bug again yet. I can’t really confirm that it’s fixed since it didn’t happen every time before anyway, but it certainly seems to be working better.
Curious. certainly nothing changed that would have fixed this :(. Can I suggest you keep using the new .dll, even after upgrading to 2597 later, in the hope that if the issue shows again, we get the b better info.
Keeping Activity Window open will help, but is not crucial; I changed the exception you’ll see to also include the relevant file name.(Activity Window start working it was opened, you can close it and later reopen, and it will have all logging; but it wont have logging from before it was first opened),
Ha how strange. I had a similar occurrence with a user a couple weeks ago where I sent a build with a lot of extra logging info and suddenly it was “fixed” I’ll be sure to report again if/when I encounter it again.
Yeah. that can happen, but I’d be shocked if that was the case for this one, as it doesn’t sound like something that was/is time-sensitive or subject to races… we’ll see. If you dont see it at all after a few days; please restore the original .dll and see if that does bring it back, though.