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

[Lincoln Baxter, III]

See line 21: http://paste2.org/d9Wyydfc


On Wed, Sep 3, 2014 at 12:58 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

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



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140903/67b06066/attachment.html