remove members from Object

[liujoey]

Eclipse has a really good feature that user could add a filter on assist list that specify which type he does not like to see.

For example: I have java.awt.* and java.lang.Object in the filter list, so when Eclipse shows the content assist, any member from Object and awt package will be hidden. Who wants to see those methods like toString() or equals() or notifyAll()?

[Shougo]

Well, I don't know it is useful feature. But Pull Request is wellcome.

[kamichidu]

I also think, it's sooo good feature! But sorry, I have no time to do it, patches wellcome.

(off-topic: I have an idea to re-implement this plug-in. Current java parser and completion system are bad. I wanna fix them when I have enough time.)

[Shougo]

(off-topic: I have an idea to re-implement this plug-in. Current java parser and completion system are bad. I wanna fix them when I have enough time.)

:+1:

[vheon]

(off-topic: I have an idea to re-implement this plug-in. Current java parser and completion system are bad. I wanna fix them when I have enough time.)

@kamichidu I'm using eclim right now, but I would love to get away from it, so If I could be of any help I would love to if I can. What did you have in mind?? I wanted to try and use the parser from eclipse itself...

[leonschreuder]

(off-topic: I have an idea to re-implement this plug-in. Current java parser and completion system are bad. I wanna fix them when I have enough time.)

@kamichidu I'm using eclim right now, but I would love to get away from it, so If I could be of any help I would love to if I can. What did you have in mind?? I wanted to try and use the parser from eclipse itself...

I've also played with the idea of writing a java completion engine, while working on my android plug-in. It was too much work, so I settled on trying to see if I could fix some bugs in javacomplete for the time being.

My idea was to add a java support to the awesome YouCompleteMe plug-in. That would be faster, non-blocking and I would only need to write a plug-in for an already existing and optimized system. Since that uses python, and python has no java-parsing library, I've looked into java-parsers written in java. This one seemed interesting.

Anyway. I'll continue to see what I can do with javacomplete, but I'd love to help if anyone starts something better...

[vheon]

@meonlol

My idea was to add a java support to the awesome YouCompleteMe plug-in. That would be faster, non-blocking and I would only need to write a plug-in for an already existing and optimized system. Since that uses python, and python has no java-parsing library, I've looked into java-parsers written in java. This one seemed interesting.

So we are two who had the same idea :+1: I look YCM very closely so that was my first idea, to write just the completer and let YMC do the rest.

In the process to find a proper parser I look at javaparser too, and even though I didn't test it, it doesn't seems to be error resilient, which means that it could not be used to parser java code while not properly written which is not good when you have to write a completion engine, for example:

public class TestClass {
  public static void main(String[] args) {
    System.

At that point we have not closed the curly braces and the parser, if not written for this purpose could complain about the missing braces and not give you the info you want. That is why I wanted to use the parser of eclipse itself which is a library on its own. In fact there is a project that does this already which is jostillmanns/javacomplete. I ask for clarification of the API that he created since it wasn't very clear but I got no answer back.

Anyway. I'll continue to see what I can do with javacomplete, but I'd love to help if anyone starts something better...

One could always start to make javacomplete better and then separate the basic completer from the vim client.

[kamichidu]

(I'm not a native English speaker. If you find a mistake or bad English, please tell me. I'll describe any sentences.)

YCM is a good coice, but I want to implement by lua interp. or pure vim script it will launch quickly. I always want vim and other plugins to respond quickly. e.g. my vim life is really short, launch by launch. I think vim's omnifunc way is really smart since it works anywhere.

Now, I'll write some java parser in pure vim script at here. That repository is just a external vital repository, see vital itself. The advantage is just a portable, avoiding conflict. I definitly think, for the completion, parser handles small code. It means the parser in java has disadvantage for its launching time. (You know jvm is really fast but launching is really slow.)

Java class-file parser is available here. It works well, I have a plan to use it for javacomplete.

@vheon eclipse's ASTParser is really useful. But it's must be used in jvm. I read many eclipse jdt codes, finaly I got an idea it's toooo big and slower for my usecase. If you can help me, you able to write test codes, to find corner cases of my javaparser. Thanks a lot.

[vheon]

@kamichidu

but I want to implement by lua interp. or pure vim script it will launch quickly.

My main concern about writing the parser in vim script is performance. I don't want to say "NO" before seeing any data of it being slow, but I can predict that it will be. Have you thought of writing it in golang? it would be very fast, being a compiled language, and starting a new go executable is almost instant since is statically compiled, and we could cross compile the parser for every platform. I know you already do that with your plugin manager so you know what I'm talking about.

It means the parser in java has disadvantage for its launching time. (You know jvm is really fast but launching is really slow.)

I absolutely agree with that. In fact If I was going to that path I was thinking to wrap it in a server that would remain active to reduce the overhead of the jvm starting time.

[leonschreuder]

In the process to find a proper parser I look at javaparser too, and even though I didn't test it, it doesn't seems to be error resilient, which means that it could not be used to parser java code while not properly written which is not good when you have to write a completion engine

I hadn't thought about the incomplete code, that javacomplete project seems more comment-parsing oriented anyway. I think jostillmanns/javacomplete looks a lot like what we would actually need. That one is already running a java-completer and it's running in a daemon (server) process already as well.

My main concern about writing the parser in vim script is performance.

I agree. I would try to fix javacomplete as it is, but as completion requires a lot of time-intensive parsing, I think that if we would start a new project, vimscript would not be my first choice.

YCM is a good coice, but I want to implement by lua interp. or pure vim script it will launch quickly.

YCM is actually much faster than the omnifunc, and you can query asyncronously as described here.

Have you thought of writing it in golang?

I have not yet written any golang, but I was already interested in learning it since syncthing is built in go. I can't find a java parser for golang though, so that also means we would have to build the parser and completer from scratch. Or maybe we could start with some javascript parser.

[kamichidu]

@vheon

I agree with you, go is very cool.

In the past, when I think about best choice of the programming language for building java parser, It's lua. lua_jit is very fast and vim supports it (if_lua).

But now, we have other candidates, I think go is better choice than lua.

You know my plugin manager? It's my pleasure! :) I'm into go now.

I absolutely agree with that. In fact If I was going to that path I was thinking to wrap it in a server that would remain active to reduce the overhead of the jvm starting time.

Thanks. I usually use vim in the short-time. For example, I always live in the console and launch vim when I need to edit some files, and then I immediately quit it. The server apps launched from vim inside, it's looks nice to me except managing any servers inside some vim. I used to use a server app for this, finally I drop a server and use java normal app which store results to local-file-system.

I interested in go for parser.

@meonlol

jostillmanns/javacomplete seems to work under only linux or mac. Does it work under windows? jostillmanns/javacomplete uses unix domain socket for to communicate its client. I have tried to it, it really cool, except windows support.

I want to re-write this project (Shougo/javacomplete), and I want to drop old files.

YCM is actually much faster than the omnifunc, and you can query asyncronously as described here.

YCM is good, but I don't want to depend YCM and neocomplete and others. I like omnifunc because we just need a vim itself.

I can't find a java parser for golang though, so that also means we would have to build the parser and completer from scratch. Or maybe we could start with some javascript parser.

That's right, I want to implement whole parsing system for java. It's a bit boaring but it's fun to me.

[vheon]

You know my plugin manager? It's my pleasure! :)

I was browsing your github account and I saw it. I've never use it (yet) but the idea is pretty interesting :+1:

jostillmanns/javacomplete seems to work under only linux or mac. Does it work under windows? jostillmanns/javacomplete uses unix domain socket for to communicate its client. I have tried to it, it really cool, except windows support.

It's one of the first things I saw and I don't understand why use domain socket over bare java.net.Socket which if I remember correctly internally use jio so it would be performant anyway.

That's right, I want to implement whole parsing system for java. It's a bit boaring but it's fun to me.

I've never written a parser before, but the idea seems fun :)

I usually use vim in the short-time. For example, I always live in the console and launch vim when I need to edit some files, and then I immediately quit it.

I live in the terminal too, but I usually launch (n)vim once and then foreground it when I need the terminal or use the :terminal of neovim. But anyway once we got the parser and the functionality, extracting it to make a long living server will not be that hard, so I'm ok on working on the "omnicomplete" version first :+1:

[leonschreuder]

I think we all agree we should use golang and build a new java-parser in it.

But anyway once we got the parser and the functionality, extracting it to make a long living server will not be that hard, so I'm ok on working on the "omnicomplete" version first

As I understand it, go doesn't need a runtime and is so fast that we probably don't even need a long living server at all. And I a agree with starting with the omnicomplete version. It's nice not to exclusively depend on YCM and you are right that we can easily add support for it later.

So where do we start? I've not yet had the chance to start learning go (probably will have some time next week), so I think it would be better if someone else starts the project.

As to the work-flow: I really like the stability unit-testing with TDD gives me in java. I don't know if and how this works in golang, but how do you guys feel about testing?

[vheon]

@meonlol

As I understand it, go doesn't need a runtime and is so fast that we probably don't even need a long living server at all. And I a agree with starting with the omnicomplete version. It's nice not to exclusively depend on YCM and you are right that we can easily add support for it later.

The client/server architecture was useful before because it would mitigate the startup time of a possible jvm which in java is a relevant part. But a running server could bring other functionality like caching. I understand that @kamichidu don't want the client server architecture because of the "short living session" usecase but it was worth noting :)

As to the work-flow: I really like the stability unit-testing with TDD gives me in java. I don't know if and how this works in golang, but how do you guys feel about testing?

I'm not very good at it but I try whenever possible to do TDD, but with TDD or not tests are important and I think @kamichidu agrees with this (there are tests even here in javacomplete).

[kamichidu]

@meonlol @vheon

I did making a tool for generating java grammar file in json format. You can get here.

Then, we remain to make a go yacc grammar file from a json file which jls-grammar-gen generated.

Thank you for your agreement about omnicomplete version first! I prepare to make a java parser in go-lang.

So where do we start?

Anywhere. I can create a repository in github, and you can create it in your github, and we can create it in our organization. Which one is the best?

fmmm... I will create a repository by the end of this month. Let's discuss about it, and I will follow the decision.

TDD in go-lang

I completely agree with importance of testing. go-lang has a simple test tool, go test. See http://golang.org/pkg/testing/ .

[vheon]

I can create a repository in github, and you can create it in your github, and we can create it in our organization. Which one is the best?

I don't have prior experience with organization on github so I don't know. But as soon as we create the repo on github we could discuss on gitter instead then open issues as a way to comunicate.

[kamichidu]

I'm alive, I'm in trouble thus...