[windup-dev] Status update - Decompiler - WINDUP-235

[Ondrej Zizka]

Hi,

update on WINDUP-235:

Procyon's API is a bit low-level.
There's a package procyon-decompilertools, whose API is a bit weird and 
tangled, and of course, without a bit of javadoc.
That package worked for .jar decompilation since that's the use case for 
that package. Decompiling .class is not.
Procyon Wiki says it should be able to decompile a .class file, but it 
is not - an ITypeLoader impl to get it from a filesystem is missing.

More, I think picking up from the .jar one by one would be slow.
I'm going to implement it so it would decompile files as accepted by a 
filter, in one pass over given .jar.

Another approach is to move this to higher level, and when asked to 
decompile "all classes in org.mycompany.*", query the graph for where 
they are, and then decompile all classes from those jars, again, using a 
filter.
Still, querying for all classes would be slow. So I suggest to store an 
information about what jar contains which packages in the graph (if we 
don't yet), WDYT?

And lastly - one idea - not sure how much time Windup spends on 
comparing package prefixes, but we could build a package tree in the 
graph when scanning, and when looking for classes from given package 
org.foo.*, we could select with Gremlin:
     PackageModel[name=org] -- contains --> PackageModel[name=foo] -- 
contains --> JavaClassModel  .loop()
That could be faster when the numbers of classes in the projects get to 
hundreds of thousands.

Ondra