How to disable printing informations about errors in output window?

[BlueFlakes]

Environment

• Operating System: ubuntu 17.04
• JDK version: 1.8
• Visual Studio Code version: 1.16.1
• Java extension version: 0.10

[BlueFlakes]

Guys my problem is that many times when I write a few words, still line isn't completed I get auto pop up errors in output window. It distracts me a lot

So again how to disable errors from being printed in output window?

[xuaveneg]

In my case (with maven), the plugin analyses all generated .class files created during the build in the target folder, making it print a lot of errors and taking the focus of my task and of my problems window, which is quite troublesome ...

[fbricon]

can you provide a sample project reproducing those errors? better fix the root cause of the issue than hide it

[BlueFlakes]

Easiest way which I know about is to make new file and just write something
then it looks like this:

[BlueFlakes]

I was thinking about easy solution because I thought that it's a feature, so I didn't record any other ways to call out this situation.

[fbricon]

Ok, so this occurs for standalone java files with no package. Currently, one way to fix it would be to add a package declaration at the top of the file. We should definitely fix that before releasing 0.11.0.

@snjeza see this stacktrace

java.lang.IllegalArgumentException
	at sun.nio.fs.UnixPath.getName(UnixPath.java:321)
	at sun.nio.fs.UnixPath.getName(UnixPath.java:43)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.getPackageName(JDTUtils.java:197)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.getFakeCompilationUnit(JDTUtils.java:155)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.resolveCompilationUnit(JDTUtils.java:133)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.resolveCompilationUnit(JDTUtils.java:106)
	at org.eclipse.jdt.ls.core.internal.handlers.CompletionHandler.completion(CompletionHandler.java:36)

In JDTUtils, this fails if parent.getNameCount() == 0:

   String name = parent.getName(parent.getNameCount() - 1).toString();

[fbricon]

@snjeza I also seems those IOOBEs (also happening on hover) are caused by compilation units with a 0-length buffer. Might be caused by class not being saved after creating the java class file

[xuaveneg]

In my case, during the execution of my build task (using maven), The errors showing in the output console are

[Error - 10:27:32] 2 oct. 2017 10:26:41 JavaBuilder handling CoreException
File not found: [filename].
org.eclipse.core.runtime.CoreException: File not found: [filename].
	at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:45)
	at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:406)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:849)
	at org.eclipse.core.internal.resources.File.getContents(File.java:277)
	at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsByteArray(Util.java:1135)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:889)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileContents(IncrementalImageBuilder.java:831)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:860)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:191)
	at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:593)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:462)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:368)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:330)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:305)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:135)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:267)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:195)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: java.io.FileNotFoundException: [filename] (Le chemin d’accès spécifié est introuvable)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:401)
	... 28 more

(Sorry, for confidentiality reasons, I can't show screenshots or filenames here, but I have this error for most of the generated .class files in the target folder)

[fbricon]

@xuaveneg ok so that's another issue. Running a clean build from CLI, causes a discrepency between the jdt.ls server state and the file system. We need to handle that better. Can you please open a separate issue for that?
As a workaround, I suggest you avoid "clean" Maven builds, when running your task (if it doesn't cause any problems)

[fbricon]

Hopefully this should be fixed by eclipse-jdtls/eclipse.jdt.ls@d70d4bf

@xuaveneg's specific issue will be handled in #314