As I'm typing the code, does eclipse look up instantly in the class file in order to retrieve the class members for the intellisense or is there a file seperately created that eclipse refers to?
I think you are asking about how Eclipse JDT content assist works. When you press ., a content assist invocation occurs. This triggers a reconcile operation in JDT. A reconcile is kind of like a mini-compile. The current file is parsed and resolved, but no byte code is created (that's what a reconcile is). The results of the reconcile are what is used to populate content assist.
This is only scratching the surface of what is going on. In actuality, things are quite complex with caches, diet parses, and bindings used and created as needed.
Related
So I made a package, lets call it dev.example.project for example purposes. all my other packages extended off of that one, with names like dev.example.project.handler or dev.example.project.assets. But I decided to go back and change the dev.example.project package's name to something else, like dev.betterexample.project.
I thought it would be a simple matter of renaming all the other packages and import statements so no errors would happen, but right after i changed the name, all the packages in my project turned white and became inaccessible. I changed the name back to what it originally was, but when i opened Eclipse again, some packages and files were simply not there.
I spent a lot of time on this project, someone help?
Depending how exactly you did that renaming, various things could have gone wrong.
Remember: you can always go in and work outside of eclipse. Close it, open a file explorer and create directories that use the names you want to use. Then move files manually to their target directories. If you want to, open them in another text editor and fix the package lines. When you now open eclipse, do a refresh and full rebuild. Things should be fine then.
That is probably not the most elegant solution, but it always works. And more importantly, you are in full control of everything that happens!
And for the record: the real answer to avoid catastrophic loss of code is to use a source code management system such as git. And to then push your changes constantly out to that "backup" facility.
I tried to copy a source package from one pc to another. I did this by copying and pasting the source code. I see this was the wrong approach because the copy did not copy something. I have resolved these issues in the programs that did not have forms. However in the one program which uses a form I get the following message:
"The form seems to be corrupted. The GUI builder is not able to find the sections with the generated code. The special comments that denote the start and the end of these sections were removed or modified. The form will only be opened in read mode"
The result is that I cannot make modifications to the forms. I cannot go back to the original pc to do the whole process correctly, since it has crashed. How can I regenerate the lost special comments that denote the start and the end of the generated code? I compared the generated code from the original source to the generated code which I copied. I cannot see any difference.
I also researched the link http://wiki.netbeans.org/FormGuardedBlockError but did not obtain any useful information.
In eclipse I often will get this error:
For example, I tried to use the shortcut to change a method signature: Alt + Shift + C but it gives me that error.
Is this because I may be using a different project? Thank You Very Much
Refactoring operations, like many other java-specific operations, rely on the ability of the tooling to correctly parse the code in question. Generally, that means that:
The code has to be valid enough (syntax and grammar) for the selected element to the correctly parsed.
The java source file in question needs to be within a java project's source folder.
The build path must be correct and error free so that referenced classes and packages can be correctly identified.
This message is telling you that one or more of those conditions are not met.
This can occur while debugging. When Eclipse stops on a breakpoint it will open a new window in the editor, with the execution stopped on the breakpoint. Some user operations in this debug pane can result in the error you describe. For example, suppose you select an object variable and press F3 to open the class declaration for that object. You will get the error message you describe above.
In this case, select the window which has the live edit version of the file you are debugging, then select the object of interest then hit F3. The class declaration will open in a new window.
Your mileage may vary.
I've come across quite an odd problem with eclipse.
I was working on a project and I right clicked on a method call declared in another class and used Eclipse's handy find declaration in project (saves me quite a bit of scrolling) to run a search for that specific method declaration. Right as it should my search pane pops up with a link to the method declaration. So I click the link, the other file the method is declared in is opened automatically, and poof the Java file I had searched from disappears from my editor tabs.
So I say to myself, "damn this old version of eclipse (Indigo) has some bugs...now I've got to go reopen my file and get back to my spot...GREAT!". But when I open the file, it is treated like a plain text file. All the text is the same color, and the outline won't work!!!
So I solved the problem whilst I was typing the above up and decided to post the answer since it isn't a nice clean solution..and I doubt one exists.
Okay so file wasn't being recognized by eclipse..
So I open the file and do a Save As, and save it under another name in the same package.
Then, I went to my test code and right clicked on a method call that was declared in the file that eclipse had buggered up, and went to search for declaration in project.
Sure enough two results popped up, one in the newly saved as file, and one in the old one.
I clicked on the old one, and still plain text...no difference.
But then I clicked on the new one, and my highlighting was back!
So then I just deleted the old file and refactored.
I think somehow eclipse made the file disappear without properly closing it...just my guess, glad I resolved this nice and quickly, hopefully anyone who has the same issue can be helped by this.
This happened to me a couple of minutes ago. Trying to close/open the projet, restarting eclipse did not work for me.
The steps I used were:
Pick another Java file (same package) right next to the bogus one (make sure syntax highlighting works on this one)
Choose 'Save As' and override the bogus one.
Verify that the bogus one now has proper syntax highlighting
Use git checkout -- to retrieve you original file
Et voilà !
I'd like to add a custom warning message (i.e. add an entry to the Warnings section of the Problems tab) for .java files in Eclipse.
While I've found information (here and elsewhere) on creating plugins and using markers, I haven't yet found anything which talks about extending the "problem-finding" process. Most of the articles I've found don't discuss when to create markers, only how, and those that do assume that I'm interested in attaching them to a custom build step or custom editor, neither of which seems appropriate for what I'm trying to do.
How can I create a warning which functions like those available via Window > Preferences > Java > Compiler > Errors/Warnings?
I think that a builder might be appropriate for what you want to do. There's a template in the new plugin wizard that creates everything you need for a builder (ex. business logic). Since the builder runs every time the file is modified, you can clear the old warning (code generated for you) and add a new warning (code generated for you) if applicable. This also applies when the file is first created.
You could even look through the code and find hard-coded strings and flag them with warnings if you want.
As for the comments marking translation keys in the code today, those are there to guide NLS tools (you probably already knew that). The idea was to write the code first and then go back later and translate. If a change is made to the code later, the tools can run again and only act on new strings added by the delta.