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

[Brad Davis]

Just to clarify, decompiling is much more processor intensive than seeking a JAR file to load the bytes to decompile.  So, I wouldn't worry about the cost of decompiling classes 1 by 1: that is definitely a lot lower cost than decompiling a full JAR. 

Take the following scenario:
100 classes in a JAR
Only 10 classes actually have "interesting stuff"

You should really only have Windup decompiling the 10 classes that you need to inspect more closely.  This was handled in Windup 1 by looking at the class imports (which are resolved anyway at compile time) and comparing them against the blacklist.  In Windup 2, Lincoln builds a list of regular expressions that are "classes of interest".  When you build your class graph, you should mark all classes of interest.  Then, perform a graph query where you get all of the *scan package classes, and determine if they are related to any of the classes of interest.  Only classes within the scan package that have relationships to classes of interest need to be decompiled, which should be a very small subset of the total number of classes in the application.

*scan package: you need to have 1 or more package structures that are provided at run time that says "hey, these are the classes that I actually can modify".  In other words, if I develop an application that is deployed to Weblogic, I can only modify the code that I control.  The scan package(s) represent all packages that I can control.  This is important for a number of reasons, but most importantly: it probably is not legal or at least slippery slope to decompile another vendor's JEE classes.  If you decompile everything, if the customer included weblogic.jar within their application, we should never be decompiling that.  Secondly, the customer has no control over weblogic.jar, and can not modify its code anyway.  The only code you should give hints on for modification is the customers code, since that is the only code they own/control.  This is also extremely important because reporting on too much stuff (especially stuff that the customer can not control) is like fog which clouds their path to migrating their own code.

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com 


----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Wednesday, September 3, 2014 11:26:35 AM
Subject: Re: [windup-dev] Status update - Decompiler - WINDUP-235

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