We Keep Coding

How can I prevent Intellij IDEA to reparse my code at each keystroke?

I write Java code in the IntelliJ IDEA IDE and it seems to me that each time I hit a key it reparses (evaluates) my whole sources.
To be clear, when I want to write this:
public class MyApp {
public static void main(String arg[])
{
System.out.println("hello");
}
}
and I am at this point ([CARET/CURSOR] = position of current):
public class MyApp {
public static void main(String arg[])
{
System.out.prin[CARET/CURSOR]
}
}
IDEA alraedy tells me already the helpful message:
Cannot resolve symbol 'prin'.';' expected
I have tried very hard to get IDEA not to do this (as obviously while I still type the source line,I do not want this unfinished work to be compiled/evaluate)
How can I get IDEA to not do this? Not only do those idioticly pointless message disturb, they are also making typing a pain, as the responsiveness is nil, while the CPU searches the unfinished code.
Addition/Update
This picture below illustrates the problem, i.e. that the inspection is rerun at each keystroke:
In the mean time I have used an open source Java profiler https://visualvm.github.io/, available form my distro's package manager. Which has (as suggested in the comments) helped in finding out, that the delay and slowness incurred to inspection, is not the parsing in the first place, but rather the yet imperfect wayland linux display server support of IntelliJ, which recurring to an indirection via Xwayland, has slowed down the delay between "finger hits key" to "glyph is added to source" to unbearable limits.

The Inspection feature of the IntelliJ IDEA IDE, can be adjusted at different places within the IDE. The comment by #MonteChristo with turning on File -> Power Save Mode has indeed already led into the right direction, to prevent IntelliJ IDEA from parsing the code at each keystroke.
There is however another setting which can be found as illustrated here:
where then it is possible to swiftly reduce or inhibit inspection alltogether, using this settings menu.
As visible the connection to power save mode which is maybe the quickest workaround persists.
Also please note that even though inspection gets disabled, results from previous inspection runs (i.e. red underlines, red text) will remain.
It seems to me that according to my test only the setting power save mode was really able to completely disable the parsing at each keystroke, while all other settings kept the code parsed at each keystroke.

Why is my GWT app not loading sometimes?

I have a problem with my GWT/libgdx app (GWT ver: 2.6.0, Gdx ver: 1.9.2) and I cannot find any recent solution, or something that match my issue, on the Internet. Short story is, sometimes, "randomly" (or inexplicably, to be honest), my app choose not to load on the first try (or second, third...), and then after one (or two, three) refresh, it works (... and sometimes it doesn't, at all). Sometimes it loads immediatly, too.
This behviour happens on various browser (firefox, chrome, chrome for mobile... Surprisingly enough IE is not the most problematic browser here), on various machines (and OS). So, on my Linux/firefox, I often have no problems (not always). But on my colleague Windows10/Chrome, we have to refresh the page two or three times, and on his phone (Android/Chrome) it never displays. I don't exactly know the versions.
On Firefox, I thought I had a hint first, because the blablabla.cache.html file seemed not to be loaded (in the sources page of the inspector) when the page refused to load (which would explains why, even if it would be totally not normal that this part would randomly be there or not!). But then, the .cache.html was here, and not my app...
All that I know for sure is that onModuleLoad() is never called when my app is not displayed. Neither is this part (from gdx):
public PreloaderCallback getPreloaderCallback() {
return new PreloaderCallback() {
#Override
public void error(String file) {
alert("error");
}
#Override
public void update(PreloaderState state) {
if (state.hasEnded()) {
alert("loaded");
}
}
};
}
So I know that, with these weird and little pieces of information, it will be impossible to know what is wrong. But did anyone get such a curious and untrusty behaviour with a GWT and / or gdx app?
EDIT : I noticed two possible explanations for my problem. Now it is mostly solved but I'd like to help anyone who could have the same trouble in the future.
The first one is in the html file. It was impossible for you to know because I did not think it was a possible cause for my issue. I was using React and GWT to display my app, and both React and GWT were rendered in a unique div.
When React is rendered first, the GWT part is added in the div, so everything works well. Yet, when GWT is rendered first, the React part replace it in the div. Most of the time React was faster and I did not see any problem. The solution was easy: I added another div specifically for React.
The second issue was on iOS10. Gdx uses an old version of SoundManager2 that needs a patch to work on iOS10, and even stops the application loading. I had to use more recent sources of SM2.

Why does Eclipse content assist fail to generate a method stub from a partial method name?

Previously, I've been able to create a method stub in Eclipse (Java) by typing the method name and pressing CTRL - SPACE. This would then give me the option of automatically generating a void method stub.
Unfortunately, recently I've been unable to do this for any method name longer than two characters. Once the word is longer than 2 chars, the option is no longer there.
I've looked at the templates in the options, and found the private_method and public_method templates, which are similar, but not quite right. The void method stub is nowhere in there. Also, the icon next to the void method stub is different to the templates, which leads me to believe that it is indeed something other than templates.
Can anyone point me in the right direction of why this isn't working for anything longer than two characters?
Here's an image of the code suggestion I'm looking for (the selected one):
EDIT: For clarification, I've added two more images showing the problem, and a further description:
In the case where there are two characters and I press CTRL - SPACE, I get the autocomplete option for creating the method stub (which is what I want). However, when pressing CTRL - SPACE with more than two characters before the cursor, there is no such suggestion. See the second image below and you'll see what I mean.

It's related to Code Recommenders, which is now enabled by default in Eclipse (as of the Mars release, I think). To me it looks like a bug, either behavioral or, if it's working as intended, it's a usability and/or UI bug, because it's difficult to understand the new behavior.
One workaround is to disable Code Recommenders for code completion; see this screen shot for where to do so in the Preferences.
If you want to keep Code Recommenders enabled (it does seem to provide some valuable functionality), is to tweak a particular setting so that the method template is included for more characters. I'm not exactly sure how or why it's related to what you're seeing, but it does seem to work. I'm also not sure of the performance impact of adjusting this too much, as indicated by the UI instructions.
Increasing the "Maximum prefix length" for the sub-words completion seems to allow larger numbers of characters to trigger the method template suggestion. Again, I'm not sure why but I strongly suspect it's a bug in Code Recommenders.
I suggest asking about it on their forum and/or entering a bug about this: https://www.eclipse.org/recommenders/community/

form the image I can tell that you are trying to write your code within the class block and not within a method block...
Example
class a {
// you are trying to write your code here
}

This issue has been fixed with Eclipse Code Recommenders 2.2.5.
You can download it from the Recommenders stable update site stable update site.

HP Fortify -- annotating method parameters

I'm trying to eliminate false-positives from an HP Fortify scan of a Java application.
This method causes a "Privacy Violation" issue (the PrintWriter is a servlet response)
private void writeOutput(String passwordRules, PrintWriter out) {
...
out.print(passwordRules);
...
}
This is because Fortify follows naming conventions, to decide that passwordRules contains private data. But my passwordRules is not private data -- it contains stuff like "Minimum 8 characters".
I can make the error go away by changing the name of the variable. However in principle I don't want to compromise the readability of my code, for the benefit of a source code analyser.
I expected this to fix it:
private void writeOutput(#FortifyNotPassword String passwordRules, PrintWriter out) ...
However it seems the annotation isn't written for that context:
The annotation #FortifyNotPassword is disallowed for this location.
I tried:
private void writeOutput(String passwordRules, PrintWriter out) {
...
#FortifyNotPassword String rules = passwordRules;
out.print(rules);
...
}
... but this doesn't remove the false-positive. (And it compromises my principle of not making code less readable).
I've also tried the above with #FortifyNotPrivate, with the same results.
So what's the right way to do this?

Fortify offers you two ways to deal with this situation: 1) suppress the issue, or 2) hide the issue. Which you select depends on what you believe will work best for you.
Suppressed issues. You can mark an issue as suppressed if you are sure that the specific vulnerability is not, and never will be, a concern. You might also want to suppress warnings for specific types of issues that might not be high priority or of immediate concern. For example, you can suppress issues that are fixed, or issues that - in your case - you do not plan to fix. Suppressed issues are not included in the group totals shown in the issues panel. This approach may be best when you want to eliminate awareness of the issue altogether.
Hidden issues. You can hide a group of issues temporarily to avoid distraction as you focus elsewhere. For example, you could hide all issues except those assigned to you. The individuals assigned to address the issues you have hidden in your view can still access them. The group totals displayed in the issues panel include hidden issues. If you find an issue in a folder list that you want to hide or direct to another folder, you can create a new filter using the filter wizard. The filter wizard displays all the attributes with matching conditions for the filter. P 29 of the document HP_Fortify_Audit_Workbench_User_Guide_4.30; this documentation is with your Fortify program files. This alternative might be preferable if you want others to be aware of the issues, even as you ignore it.
Removed issues. This alternative is not particularly relevant to your situation, but I present it for the sake of completeness. As multiple scans are run on a project over time, issues are often remediated or become obsolete. As it merges scan results, Static Code Analyzer marks issues that were uncovered in a previous scan, but are no longer evident in the most recent SCA analysis results as Removed. Removed issues are not included in the group totals shown in the issues panel. As you do not intend to "remediate" this issue, it will not become a "removed issue."
To show or hide suppressed, hidden, and removed issues, use the Option menu. Visibility filters show or hide issues.

slow (JavaFX) code even after reseting the repository

I just faced a strange behavior and I can't even say if it is a JavaFX specific problem, Eclipse problem or even where to start fixing first.
But first things first: I'm writing a JavaFX application (Eclipse Kepler/ Java 1.7), containing some extended ListViews. The program takes about 1sec to load.
The extended ListViews look something like that:
public class NewList<T extends Obj> extends ListView<T>{
public NewList(){
// addEventHandler(KeyEvent.KEY_RELEASED, new EventHandler<KeyEvent>(){
//
// #Override
// public void handle(KeyEvent arg0) {
// if(arg0.getText().equals(KeyCode.DELETE)){
// getItems().remove(getSelectionModel().getSelectedItem());
// }
// }
// });
}
}
There are also some MouseEvents (like drag and drop) inside the same constructor, and they are working as expected.
Now I want to add an EventHandler to my extended ListView (see commend in the code above).
The code takes now about 8sec to start aka 8 times longer as normal. To my surprise 90% of the loading time the program is inside the .show() method of my primaryStage (there is just one). After the loading time, the GUI is extreme slow and the cpu usage is on 100%.
Maybe the Handler is implemented wrongly and is doing some strange stuff during the whole time.
I can't find any solution or even comparable problem on the internet....but now the real problem just begun:
When I delete the Handler and run the program again, it will stay slow! So the program is in the same state as before - just still broken! That makes me crazy, because I can't see any logical explanation for that behavior.
What I have already tried:
delete the bin folder inside the repository and build the code again (+reboot)
reset the repository via git
throw half of the code away and started again. At any point it worked again, unfortunately I was not able to reproduce the effect. Then I implemented the Handler again and the problems started from the beginning...
edit: it looks like there goes something wrong during the building process/updating the binarys. I deleted 99% of the code (>5k LOC), then it worked. I copy/pasted the original project back into my workspace and the hole code worked smoothly - even with the Handler on. So I can't imagine a way to produce a minimalistic setup. btw: I'm not allowed to release the complete project folder (university stuff...)
edit2: I' using win7 64bit with java64. other javaFX programs are working (even then grafic intensive oracle samples). I'm not using any JavaFX specific repository setup or builder

Okay, I faced the same problem a few minutes ago and I think I found the source this time.
I'm running my code ALWAYS in debugging mode. To check the EventHandlers condition, I created some breakpoints in Eclipse. I also created a breakpoint at the following line of code (see above for more code)
public void handle(KeyEvent arg0) {
A mouseover over the breakpoint provides the following information:
Multiple markers at this line
Method breakpoint:NewList [Entry] - handle(KeyEvent)
implements:javafx.event.EventHandler .handle
I don't know what is happening here exactly but I think its something like this:
I'm overriding a JavaFX EventHandler Method and the debugger has to check the breakpoint on every single JavaFX interaction/EventHandler call. So Eclipse cant handle the flood of checks in a propper time and all seems to be very slow.
To clear that out: the breakpoint itself does not have to be called at any time, just the existing of it is enough to cause the problems.
Deactivating the breakpoint or running the application in a non-debugging mode will fix all problems. I think it should be a good idea to avoid all entry-breakpoints in any kind of Listener/EventHandler :)