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


_______________________________________________
windup-dev mailing list
windup-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev