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&gt; wrote:

See line 21: http://paste2.org/d9Wyydfc On Wed, Sep 3, 2014 at 12:58 PM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com&gt; wrote: -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."

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(a)redhat.com | c: 980.226.7865 | http://www.redhat.com ----- Original Message ----- From: "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; To: "Windup-dev List" <windup-dev(a)lists.jboss.org&gt; 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(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