Does an IDE identify all compile errors before running? - java

I have been wondering about something lately.It is about the errors which an IDE like netbeans show us while we type the code(Let's assume java).I want to know whether an IDE is capable of identifying all the compile time errors while we type? It means if we run the code with an IDE, are we supposed to get only the run time errors?

If the IDE supports it, it will tell you all the errors in the code, before you even click "Compile". This applies to all IDEs, if I'm not mistaken, some will also give you any errors that the compiler itself returns.
It really all depends on your IDE, settings, and sometimes compiler.
Hope this helps. :)

It means if we run the code with an IDE, are we supposed to get only the run time errors?
It depends on the IDE. For example, in Eclipse, if there are any compile-time errors when you try to run the code, it will warn you about this, but still allow you to continue if you want to. At that point, any code which successfully compiled will execute as normal - but any methods or classes which couldn't be compiled will have the failure represented as an exception thrown by the generated code. Exactly where the exception is thrown depends on the kind of compilation failure.
In general, most of the time you should be running code which compiles without any errors. While the ability of Eclipse to "fake it" is occasionally handy, it would be a bad idea to get into the habit of using it instead of fixing up errors as you go, in my view.
EDIT: If the question is "Will I always know if there are any compile-time errors" then yes, assuming you don't blindly dismiss the warning that Eclipse gives you. I don't know of any IDE which will silently let you run code with compile-time errors in. (You should also look at the Errors view, or whatever your IDE happens to provide, of course.)

It is based on what IDE you are referring to and its settings.
No. EditPlus doesn't show any compile time errors.
Eclipse/Netbeans, based on settings output will be different.

It's quite simple:
If your IDE is capable it will look at what you have written and see if it matches the spec BUT...
Certain times what you write wil be unable to be checked i.e. explicit casting of an object to a Type where you pass in the wrong type i.e. typecastexception.
Somethings CAN be known by a compiler i.e.
int a = "abc"; // obviously wrong because "abc" is a string and not an int(eger) and COMPILE time
Somethings CANNOT be known (EDIT: if you pass a true into findTheRunTimeError you WILL get a RUNTIME error)
int a;
public someFunction(object passedIn, bool findTheRuntimeError)
{
if(!findTheRuntimeError)
{
return;
}
a = (string)passedIn;// obviously wrong cast because passedIn is cast to a string which is not an int(eger) and RUNTIME
}
There is now way for the compiler to know what is going to be passed and cast so therefore it will always be a runtime error.

As you type, your IDE compiles your code after you finished a word or something like that. That way it is able to show you coding mistakes like non-existant variables or other compile time errors.
Your IDE uses your configured Java compiler to do that. When you try to compile incorrect code using javac on the command line it also gives you information on your mistakes. The IDE does the same, parses the information it gets from javac and highlights them in your code.

Related

Meaning of Error Squiggles in VSCode Java

My java code has these error squiggles. What do they mean and how do I disable them?
Mouse Over Drop Down 1
Mouse Over Drop Down 2
What do these mean? What does the software suggest me to do?
PS: I'm a complete newb
Hints, no error. For proposing code changes, and SonarLint: code style warnings.
Here it suggests (wrongly so) to replace System.out by a shorter final PrintWriter, say out, so you need only to use out.println(...). That is not normally done.
But a similar rule states that one should use a Logger instead.
For the main: new Hello().execute(); and then in a separate non-static method (execute) do the code you wrote in main.
SonarLint: code style checker, named after the C lint tool to find "lint" in the code, dubious code pieces, like unitialized variables, dangerous lossy conversions and such.
Writing to System.out (the console) is not good style in a web server or a GUI desktop application, hence the advice is to use a Logger for logging interesting information, possibly to the console, but also possibly to a log file.
You should especially as a beginner not disable the linting extension.
Ignore the squiggles, only from time to time look at them.
One can also disable specific SonarLint rules one finds dumb.
I disabled the extension "Language Support for Java(TM) by Red Hat" . This was the extension that did the code linting. Now the squiggles are gone.

Annotation processor-generated Errors/warnings not showing in Eclipse editor or Problems view

I have written a customer annotation processor to generate various source files, wrapped in an Eclipse plugin. As part of this process it also logs various errors and warnings using the usual call ProcessingEnvironment#getMessager().printMesssage(Kind, String, Element).
I have been testing the processor by debugging the plugin in Eclipse. In the launched sub-instance of Eclipse the processor all works as expected - source files are generated, picked up and interpreted by the compiler as desired. Any compiler (i.e. non-custom) errors in the generated and non-generated appear in the editor, Problems view etc. as expected.
However I am seeing a lot of inconsistencies in terms of how custom errors and warnings appear. The behaviour I see is as follows:
If no Element is specified all messages appear in the Error Log under type Info, regardless of the Kind specified when logging the error.
If a message is of Kind NOTE it always appears in the Error Log under type Info, regardless of whether or not an Element is specified.
Otherwise, if an Element is specified errors and warnings intermittently appear in the Problems view and in the editor; sometimes they don't appear anywhere. They never appear in the Error Log, whether the Kind is ERROR or WARNING
As per the emphasis above, the real issue is item 3 - that under certain situations I simply cannot get errors to appear in the editor despite being logged on valid elements. In fact, I have managed to reliably make errors appear and not appear by simply changing the name of a particular generated source file.
Of course the issue is not the filename itself, but it is certainly the case that generating the class with a name that matches references already in code causes errors to get hidden, whilst generating it with a different name (or not at all) causes errors to show (as well as all the regular compiler errors caused by a missing class). The strangest thing is that there is nothing fundamentally different about this generated class compared to any of the others (of which there are many), although it is unique in its structure and how it is referenced. It also reasonably long (around 400 methods), but artificially shortening it did not make any difference. Other generated classes also have existing references in the code and don't suppress errors.
Unfortunately I have also not yet had the time to test if this issue occurs when the Eclipse plugin is deployed (i.e. running in a 'real' instance of Eclipse), or indeed if the issue occurs when calling javac explicitly or invoking a Maven build.
Without posting the full code of the plugin I don't expect anyone to be able to help directly, but I am very open to any suggestions or advice if anybody has experience issues with annotation processor-generated errors. It seems to me like a bug in Eclipse, but I have not been able to find any reference to it online. I also cannot find any errors in the .metadata/.log files of either the underlying Eclipse instance or the launched sub-instance of Eclipse. Finally I have ensured that there are no Exceptions suppressed or reported in the annotation processor code.
Eclipse version details:
Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600
Any help appreciated and many thanks in advance :)
If a problem/error has to be shown in the Eclipse Problems view, you need to create a Marker on the particular resource (file/folder/project). Please see the following links on how to create the Markers in an Eclipse Plugin:
https://wiki.eclipse.org/FAQ_How_do_I_create_problem_markers_for_my_compiler%3F
https://www.eclipse.org/articles/Article-Mark%20My%20Words/mark-my-words.html
In terms of how the custom errors/warnings appear, the Problems view (or the generic MarkersView) is completely flexible to show/hide certain elements. Have a look at the "Configure Contents..." menu in the Problems view to get more idea.

J-- Compiler Source Code Attachment

I'm reading a book right now, Its called: "Introduction to Compiler Construction in a Java World". So from their website you can download the source code of the compiler that one must use. -> http://www.cs.umb.edu/j--/download.html My problem is that I would like to follow the process of the compiler through debugging. But it doesnt work, because you have to attach the source code, which I tried, but it doesnt seem to work. I attached class files, java files, the jar, nothing works. So does someone know how to fix that problem?
Edit1: In eclipse
Edit2: Maybe this helps to understand my Problem better-> http://postimg.org/image/9pd2gyle7/
I wanna see what happens in the compiler process. But I cant see the main class, even though I have the main source code :S
When you say, you did attach sources, make sure to define a source attachment in a way that Eclipse understands. If that's what you tried, more information would be necessary to tell why it didn't work.

Strange Java compilation issue involving cyclic inheritance

So this will be a long story so I thank you in advance for reading. Let me start by saying that I've been working with java for more than 15 years and I've been working on this specific project for over 5 years and I'm stumped.
I compile the project on 3 different computers. I was working on the project in eclipse juno on Computer A and everything was fine so I checked in the code. Then I checked out the code on Computer B and tried a javac clean build and got a bunch of errors, starting with "cyclic inheritance involving..." and then a bunch of errors such as "cannot find symbol" and there were many of these then it had a couple of these "no suitable method found for" until finally it just wigged out and never even gave me an error total.
So, I've never seen anything like this, and as I said the code was fine earlier in the day on a different computer, so I just fired up eclipse, told it to do a clean build, and everything was fine. Go back to the terminal and do a javac and it compiled fine. Whew, I said, it must have just been a glitch.
Then on Computer C, which does a nightly build, it gave the same errors as Computer B (note that Computer B is a mac and Computer C is rhel, but both were running jdk1.7u15). So now I realize it isn't a glitch, but what to do?
I go and look at the code and I'm certain there is no cyclic inheritance and what it says it can't find the symbol for is sitting right where it is supposed to be. I investigate a bit and find out that eclipse uses an internal compiler so this would explain the disparity between compilations, but it doesn't explain why they are giving wildly different results on the same code base.
Out of ideas, and hoping there is something weird with the update 15, I update Computer B to jdk1.7u51 but unfortunately it is giving the same errors.
I realize without seeing the compiler output (which is really not much more interesting than I described), or more importantly, not seeing the actual code there isn't much you can help with. But assuming I'm telling the truth, that there is no cyclic inheritance, there are no missing symbols, and eclipse compiles the code fine when javac rejects it, does anyone have a suggestion of what I could try now?
My next thought is to update eclipse, but assuming it still compiles fine there, what to do next?
Thanks again for reading!

Infinite loop at compile time?

Is it possible to enter an infinite loop at compile time?
My program seems to enter an infinite loop when I attempt to compile it. I have a class with a class constructor that calls the method gameRun(). gameRun() calls itself at the end of its execution, but should have the appropriate checks to be able to break from it during run time... However when I attempt to compile the class, I actually seem to get an infinite loop then.
My understanding of compilation is that it does not actually execute the code... Which would mean it would be impossible to enter an infinite loop unless there is actually a serious bug in the compiler's source. Is this correct?
I am writing in Java, and am using BlueJ (a beginner's IDE which I am growing out of) as my IDE.
Thanks in advance.
.....................................
Thanks to you all for so many helpful responses. Just thought I'd post an update, as this seems to have perked some interest, and I am curious about it myself.
I have not done a whole lot with BlueJ or this error since I posted the original error, becuase I had taken the source files from the project, and was able to successfully compile and run them with eclipse. This suggests to me that it is a BlueJ (or related) problem. I have continued to work on this project with eclipse without any more problems of this nature. I will follow up with more detail on the problem when I am able to use the machine with the original project on it again. (Nothing should have been changed since)
.....................................
As an afterthought... Is there any way I can link this question to an account I have created and registered since this was posted? I can't find a way to do that, and it would make keeping track of this more convenient...
Some languages do allow the compiler to enter an infinite loop. Java isn't one of those languages. :-)
You're right, the compiler doesn't execute the code, and would only enter an infinite loop due to a bug. I'm confident that the javac compiler from Sun doesn't have such a bug.
I don't know what compiler BlueJ is using "under the covers", but I have seen a problem when Ant runs javac that makes it take a really long time to compile. Simply stated, there are some cases where Ant will direct the compiler to load every class under a given directory. If that directory contains hundreds of third-party libraries, it can take a while… or even run out of memory.
Does your compilation hang (loop) if you just use javac ?
I've never seen a compilation hang indefinitely whilst compiling Java and I'm wondering if BlueJ is having a problem instead.
It would be theoretically possible to do if, for example, to compile a file, the compiler first had to have finished compiling that file. (Ahhh... Recursion).
But I'd imagine checking for that kind of madness would be the first thing a real-world compiler would handle.
But I wouldn't think it would happen on a method/function, unless (postulating) the compiler was trying to resolve tail-recursion to an simpler implementation, and failing. But, again I can't imagine that would be an issue with a modern Java compiler, even if it exists at all. Certainly I'd imagine that the compiler would eventually give up and post an error rather than infinite looping.
It's far more likely to be the IDE than the compiler. At a guess, the IDE might be trying to trace a warning/error to its source in the code in order to highlight it and getting trapped. Does BlueJ have text-highlighting on compiler errors/warnings? You could try turning it off.
Although, as many others have already suggested, the first real test is to compile from the command line using
javac *.java
Or whatever files your code uses.
EDIT: Sorry I never got back to you. For future reference, to compile from the command line (I'm assuming Windows as your OS):
Open the command line by going to the start menu and select Run...
Type cmd into the Run dialogue, and click OK.
This should bring up a cmd.exe console.
From here, use the "cd" command to change directory to the directory containing your java files.
(cd "My Documents\Java\Monster Battle\core")
Once you're in the right directory, type "javac *.java". This will run the compiler without needing to deal with the IDE. It should pause while compiling, and when it's done, you get the command prompt back.
If you type "javac *.java -verbose" you get full output, in case you get your infinite loop.
If that works fine, it's an IDE bug. Send them a bug report. If it doesn't, congratulations! You've found something really interesting, that will probably tie up some poor Sun developer for a month.
If BlueJ does use its own compiler, you may have found a bug in it, or in BlueJ's build tools that surround it.
You might take a BinaryChop approach to this one: break your program into pieces, compile them individually, and see if the compiler-hanging behavior can be isolated to a small, specific testcase. At the end of the day, you'll either have an excellent bug report to show the BlueJ people, or you'll find that your program actually does compile (yet you'll be scratching your head).
AFAIK, Standard Java cannot be compiled infinitely.
Are you sure that the problem is at compilation rather than at some other feature that BlueJ provides? Many Eclipse-based IDEs perform multiple actions during a rebuild, and that compilation is just one of them. It is possible that something else does.
What exactly do you see? An unending Eclipse task?
Try to make the source code you are compiling as small as possible and still exhibit the behaviour you describe. The process of doing so, may help you identify what the problem is.

Categories