Java backend

[rsolomakhin]

Is there a plan to add support for Java in ycmd?

[vheon]

Using which engine? if you use vim eclim works already.

[rsolomakhin]

I'm not sure what constitutes an engine. What are its inputs/outputs? Perhaps a new one would have to be written. Eclim is too heavyweight, because it requires loading eclipse. I do not use it.

[vheon]

An engine is something that can give you the possible suggestion. Like jedi for python, OmniSharpServer for C#, clang for the C-family languages. Eclim which can be used in headless mode so running eclipse without the gui could be less expensive. Other example exists but not included in ycmd, like gocode for go, tern for javascript. I while back there was an issue discussing integrating ensime-server ycm-core/YouCompleteMe#1078

I hope I gave enough example.

[rsolomakhin]

Thank you for the examples. Indeed, it seems that a new engine would have to be written (I could take a shot at it), because I puke everytime I run eclipse or eclim.

[vheon]

Before you start writing things that could never be merged in wait until you heard from @Valloric. Aside from that I don't understand why you should start from scratch when jdt.core or janino already do what you want.

[rsolomakhin]

Sure, I want to hear what @Valloric thinks. jdt.core looks promising. It would be interesting to see performance characteristics of a code completion server using jdt.core. janino is not a full compiler and does not provide code completions, so I'm less interested in that.

[vheon]

well jdt.core is basically eclipse in headless mode and is what eclim uses and at that point I would just use eclim. Janino can parse java code and generate the AST which is what is needed for providing code completion, but I could be wrong of course ;)

[Valloric]

I'm all for ycmd integrating with a semantic engine for Java. The current approach with depending on eclim is sub-par.

If a solid Java engine exists, hooking it up to ycmd shouldn't be difficult (see the python/c# completers). If one doesn't exist, it obviously needs to be written first.

The best interface for a semantic engine is a separate binary exposing a REST API. This makes it trivial to hook up to ycmd without having to link/load it directly into the ycmd Python process.

@rsolomakhin If you want to take this on, I'll be happy to answer any questions you may have.

[rsolomakhin]

@Valloric Can you point me to the REST APIs of the other completers used in ycmd?

[Valloric]

Omnisharp is the only semantic engine that exposes a REST API; you can see how it works by reading cs_completer.py in ycmd. But I recommend you take a look at ycmd's REST API and implement a subset of it. For that, see the examples top-level directory. It has an example client you can run and tweak.

[vheon]

There's this project I've been watching https://github.com/jostillmanns/javacomplete. It uses jdt.core and already have an api. I still haven't test it but is looks promising.

[Valloric]

Also possibly useful: https://github.com/javaparser/javaparser

I do think that jdt.core seems like the best bet though, but having options is good.

[vheon]

@Valloric javaparser cannot handle unfinished source file so is not suited for completions :( I was talking with @kamichidu about implementing a new parser for java in golang from scratch actually 😏

[Valloric]

For reference, here's the JDT/Core source code on GitHub.

[wsdjeg]

now i am using https://github.com/artur-shaik/vim-javacomplete2
it works well for me

[Valloric]

The underlying semantic engine for vim-javacomplete2 is javaparser which admittedly looks pretty nice. We'll still probably go with jdt.core because that's used by Eclipse so it's used by millions and has a huge amount of features.

[vheon]

@Valloric actually is slightly different: vim-javacomplete2 use javaparser for files that are in a saved state and complete, since it can't handle unfinished code, and an internal java parser written in VimL for the file that we're currently writing which can handle unfinished code. I would go for the double parser approach but using jdt.core for the unfinished code and that is because using the AST API of jdt.core is pretty slow, in fact Eclipse don't use it all the time but have a system that gives you a high level view of the project and the objects but don't give you the errors like missing ; etc etc.

[Valloric]

Huh. The rabbit hole goes deeper it seems. I assumed that jd.core would be fast and production-ready for completion + diagnostics since it's used by Eclipse.

[icholy]

Visual Studio Code just got Java support and it's using it's own wrapper around JDT.

• https://github.com/gorkem/vscode-java
• https://github.com/gorkem/java-language-server
• https://github.com/Microsoft/language-server-protocol
• https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md

Related to #515 except I'm saying we let ycmd be a client of the language-server-protocol instead of the other way around.

[Valloric]

@icholy That's pretty sweet, I'm all for using that java-language-server then if it ends up being fast. @vheon Mentioned in a previous comment that jdt.core might be too slow, but it's worth trying out.

[icholy]

Fast enough for vs-code fast enough or us, no?

[Valloric]

Fast enough for vs-code fast enough or us, no?

I don't know what their standards for speed are, I only know what ours are (and they're pretty high). I don't expect this to be slow though if they're already using it.

[icholy]

I'll throw together a prototype when I have some time.

[vheon]

the thing that puzzles me here is that if you read https://github.com/gorkem/java-language-server#first-time-setup it looks like you have to basically install Eclipse 😕 But I would love to see it working 😜

[Valloric]

@vheon Oh that's ridiculous. Can't fathom why they'd find that acceptable.

[puremourning]

Hah. Didn't eclim already solve this ?

[icholy]

@puremourning I've never had a good experience with eclim

[wsdjeg]

@icholy did you use javacomplete2?

[icholy]

@wsdjeg no, but I think support for this protocol goes beyond java. It gives us all the vs-code back ends for free. That's a no brainer for me.

[puremourning]

Eclim... Shrug. Its main problem is that it relies on eclipse (I realise that is the point)... I use it and it works well, but I would rather not have to ever engage with or start eclipse. Or have to play config/project gymnastics.

Compared to YCM's other engines, it's a massive pain to set up and make work. But it sounds like this language server won't be any better. And won't be any better sandboxed/bundled (which is our approach to minimal user config).

Javacomplete2 requires less set up, but isn't as sophisticated as JDT/eclipse. I've had at best mixed experience with it personally.

There are other java/Scala solutions, but I think one that requires basically 0 setup would be ideal. (Like even if it reads .project and .classpath, but doesn't require an eclipse instance for example, though ideally avoiding eve this level of setup)

I'm all for java support in YCM, but I feel like we should only invest if it fits with our ethos. We're not even super happy with tern requiring a separate config, but at least we can bundle the whole thing and sort of contain it. If java support requires installing and configuring eclipse and its foibles, I'm not super excited about the advantage over eclim's omnifunc.

On 21 Sep 2016, at 00:20, Wang Shidong notifications@github.com wrote:

@icholy did you use javacomplete2?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[icholy]

My idea is that there is a generic language server completer. Advanced users can configure it to any compatible server they want to.

[puremourning]

Ycmd architecture doesn't easily lend itself to that approach presently. Not to say it isn't a neat idea of course!

On 21 Sep 2016, at 00:42, Ilia Choly notifications@github.com wrote:

My idea is that there is a generic language server completer. Advanced users can configure it to any compatible server they want to.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Valloric]

If java support requires installing and configuring eclipse and its foibles, I'm not super excited about the advantage over eclim's omnifunc.

We're not merging anything that requires installing eclipse. That's just not happening. So no need to worry.

My idea is that there is a generic language server completer. Advanced users can configure it to any compatible server they want to.

Unless a specific use-case is being addressed, I don't see this being widely useful enough to be implemented.

Any java backend will need to be as easy to configure as the rest of YCM. We don't even like having the ycm_extra_conf.py stuff for C-family projects and we really don't like the custom tern config. Asking users to install eclipse or other engines manually and out-of-band? Not something I'd be willing to merge.

[vheon]

I hope I wasn't wrong regarding installing Eclipse first 😝

Or have to play config/project gymnastics.

That is what I hate the most of the eclim experience, even though is the only way I can actually use eclipse.

I'm saying we let ycmd be a client of the language-server-protocol instead of the other way around.

That is actually an idea that on one hand I personally like because could bring to all ycmd users other semantic engines that vs-code support that we don't (even though I'm not aware of any right now) but on the other hand I think that:

• ycmd_client -> ycmd -> language-server-protocol_server -> ycmd -> ycmd_client could be a little too complex and fragile.
• how complicated would be to set up a language-server-protocol_server? or will vs-code be enough?

[icholy]

@vheon https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations

[icholy]

Rust's language server have also adopted the LSP.

[vheon]

@icholy I didn't even know Rust had its own Language Server. @jwilm do you know how does it compare to racer?

[icholy]

@vheon It's very very new, not production ready. My intention is to show that the language server protocol is gaining traction and ycmd should support it.

[jwilm]

@vheon it uses racer internally to provide more features. I was planning to add a completer for it this weekend :). I'm not sure that YCM actually supports everything that RLS does.

[icholy]

Here's another candidate: https://github.com/georgewfraser/vscode-javac

[puremourning]

I have tried vscode-javac and eclipse.jdt.ls

After some testing and exploration, i concluded that for my very-much-work-in-progress java completer using Language Server Protocol, eclipse.jdt.ls was superior.

While the java-based version is simple enough that it required little to get it working, it also suffers that the experience and feature set isn't at the level that most users would expect.

I initially intended to offer both, but decided this was a terrible idea.

[puremourning]

FWIW as this is ycmd, the ycmd branch is: https://github.com/puremourning/ycmd-1/tree/java-language-server

[vheon]

@puremourning just out of curiosity (no pressure here 😝 ) how much work do you think it needs to be production ready? I might start testing this since I think I will have to write a little Java code at work 😒

[puremourning]

A fair bit TBH. There are quite a few hacks and quite a few things that just don't work right.
Anyway here's a summary of the current status:

Standard features working:

• completions
• realtime diagnostics
• install from build.py
• basic language server management (RestartServer)
• detection of installation (optional installation)
• YcmDebugInfo and log files
• GoToDeclaration
• import completion (JDT is a pain for these, resolved by being able to set start column)
• automatic imports (post-complete hook to apply "additional fixits" associated with compeltion item)
• GetType
• basic file updating/
• FixIt
• RefactorRename
• GoToReferences
• GetDoc

Standard features not yet implemented:

• Tests!

Stretch goals:

• asyncronous messages from the server (startup progress >_<)
• actually-real-time diagnostics reporting
• fully asyncronous diagnostics delivery (outside of file parse request)

Unlikely to be implemented

• code outline
• code navigation
• highlighting (e.g. to work with @davits DyeVim)
• code lens

Things that come for free:

• basic eclipse project support
• pom.xml (maven) support (seems to work)
• gradle project support (untested)

I'd truly appreciate any feedback you do have though!

It should install with --all or --jdt-completer and the branch is up to date with master now.

[IngoMeyer441]

@puremourning Is there any new status on the Language Server Protocol integration in ycmd? This feature would be really awesome for gaining Julia completion in YCM since there is a working Julia server.

[puremourning]

@IngoHeimbach work on the java completer is progressing (slowly). i've updated the support status above.

language server protocol implementation is inline with the features needed for that, but is strictly independent of jdtls (i have working POC for clangd and a different java server). Supports TCP and stdio communication.

[bstaletic]

@puremourning I may try your fork soon. Just a few questions.

[X] GetType (throws an exception)

Is it done or does it still throw an error?

Will you wait until you make the "strtch goals" work before making a PR or will you be posting (fingers crossed) a PR once you finish the "Standard features not yet implemented"?

P.S. I may decide to help you with the implementation/tests. But not promising anything.

[puremourning]

@bstaletic cool!

I fixed the comment - GetType should work without an exception.

Stretch goals won't be in any initial PR (it's already too big TBH) unless they are necessary to make some basic functionality work properly (such as async diags, post-complete-fixits)

For ref, you'll need:

• ycmd branch
• YCM branch
• --jdt-completer flag on install.py/build.py
• Some patience maybe :)

If you use syntastic, I would strongly recommend disabling it for Java. It's not only dog slow, but it can interfere with the diags in the current patchset. I tried to disable it programmatically, but last I checked it didn't work properly.

Note: don't be tempted to try it out on the eclipse.jdt.ls code itself - it doesn't actually work for its own code (for reasons that I don't really understand, but i don't grok eclipse, so that's normal)

[bstaletic]

Okay, thanks.
The pull request is huge. Have you thought about splitting it into language server part and java part?
Also the "standard features no yet implemented" are non essential. Would you consider making a pull request without those? I'm only asking because this will be a pain to review.

[puremourning]

Yes, when it is finalised (it's still evolving now), i will split it into reviewable pieces (to the extent that is possible)

[puremourning]

project status tracking here. https://trello.com/b/Y6z8xag8/ycm-java-language-server

hoping to start pushing PRs soon. it's a big project and quite a lot of complex new stuff, so it's going to take a while!

[micbou]

Java support was added in PR #857.