On Wed, Sep 3, 2014 at 12:58 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
we unzip everything to start with, anyway.
On Wed, Sep 3, 2014 at 11:33 AM, Pete Muir <pmuir(a)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(a)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(a)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(a)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(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."