search

noseglid / autocomplete-java-minus

:coffee: Autocomplete for Java that only autocomplete.
https://atom.io/packages/autocomplete-java-minus
MIT License
9 stars 3 forks source link

Class indexing as a separate package/service #1

Closed keskiju closed 8 years ago

keskiju commented 8 years ago

I had an idea that classpath parsing and class indexing should be implemented as a separate package that provides services for other java packages. Then any java package could query class descriptions using the service and you would also have a central place to configure your java environment settings. People also keep requesting support for Eclipse and Maven config files. It would be nice that not every java package would have to parse classpath from .classpath file themselves. Then it would be easier to implement Eclipse and Maven support once and all java packages would benefit. See issue keskiju/autocomplete-java#14.

Since you are already implementing native javascript class file indexing features in autocomplete-java-minus, perhaps you could change direction and implement a more general java package that all java packages could use?

keskiju commented 8 years ago

Here is a quick draft: https://github.com/keskiju/atom-java-project

keskiju commented 8 years ago

I've talked with linter-javac developer about the package and currently he is waiting for it. But I've been so busy with work lately that I haven't had time to implement it yet though.

keskiju commented 8 years ago

"Basically atom-javaenv is a classpath aware indexing service that indexes java related files by scanning files, watching file changes and parsing files into descriptions. This includes build properties, class files, jar files and java source files. Other java packages may provide additional parsers for the indexer also."

noseglid commented 8 years ago

Hello,

It could definitely make sense to make a generic "java class indexer" which could be used from various packages. The majority of the implementation is in jdjs (which I've also created, but haven't had time to document it yet). I guess the only thing that could be beneficial from this package would be the collecting on all CPU cores. But that's really a minor thing considering.

Perhaps it would make more sense in the future, right now I just wanted a development environment for java so I just threw something together.

keskiju commented 8 years ago

Ok, I'll look into jdjs if I find the time to implement the indexer.

noseglid commented 8 years ago

@keskiju How far did you get on this? I feel the need to implement some caching when loading classes/jars to speed it up even further. It makes more and more sense to put the "classpath registry" in the service hub and use it from different places.

keskiju commented 8 years ago

I haven't implemented anything yet.

noseglid commented 8 years ago

I've created a package now for the classpath collecting. Documentation is lacking, but it's a start: https://github.com/noseglid/java-classpath-registry