Getting VirtualFile for an _inner_ class in a library dependency

 

Basically what the title says. I use an IntelliJ-plugin that currently has a bug when trying to get the contents of inner classes from libraries. I need that bug fixed, so I worked around it.

The pull request where I 'kludged' around the problem and tried to detail the problem is here: https://github.com/ebean-orm-tools/ebean-idea-enhancer/pull/9 That pull requests also references a minimal demo that shows the problem. Unfortunately the solution I wrote is fugly at best, and probably buggy in some way I can't see.

To summarize:
psiClass.getContainingFile() gives the outer(containing) class' file. Not the inner class.
Is there a better way to get the VirtualFile (or the contents)?

 

1
4 comments

Please take a look at `CompilerPathsEx.findClassFileInOutput(PsiClass)` method - it solves a similar problem.

It is impossible to get a correct VirtualFile instance for an inner class starting from the `getContainingFile()`.

0

Thanks!

That did it! Basically just use projectIndex instead of module to get the 3rd party dependencies. I.e.

ProjectFileIndex.getInstance(psiClass.getProject())
.getClassRootForFile(containingFile)
.findFileByRelativePath(classNamePath + ".class")

One question though:

Is there ever any chance that ProjectFileIndex and compileContext.getModuleByFile() will differ in what they return? E.g. if the same class name is present in multiple modules? Ebean uses JavaPsiFacade and GlobalSearchScope today, so I'm guessing no?

0

While the question above IS still interesting, I solved it in a imho better way by getting the module of the class being enhanced and looking through that's GlobalSearchScope, and then using the projectIndex. (compared to using the compilerContext)

Thanks again for the help and answer the question if you feel like it :)

0

Implementations of `CompileContext` class all delegate to `ProjectFileIndex` - so results should be the same.

0

Please sign in to leave a comment.