we unzip everything to start with, anyway.


On Wed, Sep 3, 2014 at 11:33 AM, Pete Muir <pmuir@redhat.com> wrote:
Isn’t the point that picking up classes one by one from a compressed jar slow, because the jar is represented as a stream, and doesn’t support random access?

On 3 Sep 2014, at 16:26, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:

> I'm not convinced that decompiling a single class would be slow without seeing evidence. Filters is an interesting alternative (and could be used to implement single file decompilation), is it possible for you to contact the author of Procyon and ask how to do this (single class decompilation)?
>
>
> On Tue, Sep 2, 2014 at 11:11 PM, Ondrej Zizka <ozizka@redhat.com> wrote:
> 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
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> windup-dev mailing list
> windup-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev


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



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."