Cant figure out the proper configuration

[GeremyHamlett]

No matter what I try I receive this error. I have tried moving my JDK to a path thats shorter assuming it was the path length. Any one have a clue what might be the issue here?

This is the error thrown everytime I save a java file. Below is the lines of the coffee script. I'm fairly certine it has something to do with my javac path but nothing I try seems to work.

Error: spawn ENAMETOOLONG
    at exports._errnoException (util.js:837:11)
    at ChildProcess.spawn (internal/child_process.js:298:11)
    at Object.exports.spawn (child_process.js:351:9)
    at BufferedProcess.module.exports.BufferedProcess.spawn (C:\Users\ghamlett\AppData\Local\atom\app-1.4.1\resources\app.asar\src\buffered-process.js:188:44)
    at new BufferedProcess (C:\Users\ghamlett\AppData\Local\atom\app-1.4.1\resources\app.asar\src\buffered-process.js:50:14)
    at C:\Users\ghamlett\.atom\packages\linter-javac\node_modules\atom-linter\lib\helpers.js:86:81
    at _exec (C:\Users\ghamlett\.atom\packages\linter-javac\node_modules\atom-linter\lib\helpers.js:60:10)
    at Object.exec (C:\Users\ghamlett\.atom\packages\linter-javac\node_modules\atom-linter\lib\helpers.js:134:10)
    at file:///C:/Users/ghamlett/.atom/packages/linter-javac/lib/init.coffee:69:19
    at process._tickCallback (node.js:368:9)

init.coffee : lines 67-71
# Execute javac
helpers.exec(@javaExecutablePath, args, {stream: 'stderr', cwd: wd})
.then (val) =>
@parse(val, textEditor)

[steelbrain]

@GeremyHamlett ENAMETOOLONG is a common error on windows, it's a limitation of file system. Either your atom version is old and is installing really deep nested dependencies or the process you're trying to spawn has a really long path.

[florianb]

@GeremyHamlett thank you for posting that error. I think this issue may be related to #38 and is currently under investigation.

May i ask you if you are using any additional parameters or classpath-configurations?

[GeremyHamlett]

@steelbrain Thanks for the info. My atom is up to date. I will try to see if I can shorten the paths. Maybe a quick test on a small project at the root of the FS would be good.

@florianb I would probably be using some but at this point I'm just trying to get it to recognize Javac.

I looked at issue 38 and thought the same thing but the error looked different enough where I thought I would go ahead and ask.

Thanks for the input guys. I'll keep digging and add any info I find.

[steelbrain]

@GeremyHamlett It would be very helpful if you would tell us the executablePath by adding a console.log(@javaExecutablePath) before helpers.exec(@javaExecutablePath, args, {stream: 'stderr', cwd: wd}) in init.coffee

[GeremyHamlett]

@steelbrain
Here is the log output. I moved my jdk to a very short path to test. Still get the same result.

autocomplete-java project root dir: C:\workspace\repair
JavaClassLoader.js:58 autocomplete-java load start, full refresh: true
JavaClassLoader.js:87 autocomplete-java loading project classes. loadMembers: false
JavaClassLoader.js:108 autocomplete-java loading system classes.
JavaClassLoader.js:87 autocomplete-java loading project classes. loadMembers: true
JavaClassLoader.js:108 autocomplete-java loading system classes.
init.coffee:68 c:\jdk8\bin
JavaClassLoader.js:76 autocomplete-java load end, full refresh: true

Just to complicate things, when I test against a single java file at a very short system path (c:\temp) i get a completely different error

Error: ENOTDIR: not a directory, scandir 'C:\Temp\DisplayViewLoadStatus.java'
Error: ENOTDIR: not a directory, scandir 'C:\Temp\DisplayViewLoadStatus.java'
    at Error (native)

[steelbrain]

@GeremyHamlett From your debug output, I see c:\jdk8\bin set as the executable path. It's a directory if I'm not mistaken and the option expects a file path. Can you try setting it to c:\jdk8\bin\javac.exe?

[GeremyHamlett]

Same results. No changes in the errors at all. Either from the shorter path or longer.

[florianb]

This bug is considered as being untestable. I'd like to try to create a quick-patch for the next milestone but it will be resolved at least with the next upcoming major-release #76 - thank you all for your patience.

[florianb]

@GeremyHamlett currently we have here several issues.

ENAMETOOLONG

ENAMETOOLONG is a result from the os telling us, that our javac-call is too long.

I tell you how this may happen, so you can probably find a way fixing this for your own. Currently the linter call is built by concatenating the Javac-executable-path (defaults to simply javac), any options and the source-files.

The option are headed by -Xlint:all, followed by additional classpath-definitions you might have configured in the package-settings.

Then there come the source-files. And that's what is troubling the most at the moment - i guess. With #32 there was a mechanism introduced sending all java-file-paths from the repository your current file resides to the compiler. This was done to allow the linter checking cross-dependencies between java-files. Since every file gets appended with its full path, the current limit of the windows-command line of 8.191 characters may get easily exceeded if you have ~140 java-files in your repository. Not to speak about the case if you use deep directories to bunker your java-files.

ENOTDIR

It seems that we're treating a fs-node as directory although it isn't. It may be that the entire directory is missing or the temp-dirctory is a symlink. To quickly solve that, ensure there's no symbolic folder in the path.

I think...

...both issues are caused by a suboptimal implementation. I am thankful we're now aware of them so we will put efforts into avoiding them in the upcoming major-release #76. Thank you so far! 🍬

For now, i will try to find a quick patch (probably just limiting the source-collector).

If you want to help, you are very welcome to proove my thesis and verify both error-appearances.

[florianb]

I added a quick and 💩 fix which ensures, that the assembled lint-command does not exceed the assumed limit of your current platform. Which is in that implementation 7.900 characters for win32 and 130.000 chars for everything else. If the limit is exceeded no more sourcefiles get appended except from the currently opened file, to ensure it gets linted.

If the limiter takes action it leaves an information in the console on how many sourcefiles aren't recognized by that run. As a result, some references may not be resolved - ending up in showing an error for these names.

We could consider disabling reference-errors in that case. That would be at least less annoying.

I am closing this for now - feel free to leave any notes.

[Justsnoopy30]

@florianb The quick and easy fix does not work for me. With a big .classspath, the linter doesn't work and errors with ENAMETOOLONG in the console.

[Justsnoopy30]

Pinging @Arcanemagus as the most recent contributor.

[Arcanemagus]

I don't personally use this linter, and don't have a good enough understanding of Java to suggest a fix. From the look of the rest of the discussion here it seems like this is a result of yet another terrible decision by the Java language designers. If you can come up with a solution and send in a PR (hopefully with tests!) I would be happy to merge it so everyone can benefit.

[Justsnoopy30]

I now get

 linter-javac: parsing:
 The command line is too long.

[Justsnoopy30]

This is just a normal sized classpath.

[Justsnoopy30]

This is the only java linter for atom, and I can't use it because of this.

[Justsnoopy30]

Note that I'm on Windows 10.

[florianb]

If you want help - open a new issue and ask for help. Use the verbose logging setting and attach the log. I am going to lock this conversation.