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

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