berchoice.blogg.se - Building a java jar file

We will see the details on a future blog post but we need to consider one other aspect first. Ok now, to solve symbols we will have to implement the scoping rules and navigate both the ASTs obtained from Javaparser and the CtClasses obtained from Javassist. Solve symbols: combining heterogenous models Finally not all the information available in the bytecode are easily retrievable through the reflection API.it could possibly conflict with real dependencies of effective java.when a class is loaded the static initializers are executed and it could be not what we want.While it would be easier there are some drawbacks: Someone could think that it would be easier to just add the dependencies in the classpath of effectivejava and then use the normal classloader and reflection to obtain the needed information.

Or we can also load that class by using Javassist: this what the method findTypedoes, returning an instance of CtClass. For doing that we can use the method findEntry. Given a list of ClasspathElement we can then search for the element corresponding to a given name (e.g., ). This method should be invoked once per jar and result should be cached. In this way we get a list of ClasspathElements. How we start? First of all we read the entries listed in the jar ( getElementEntriesInJar). (.makeClass classPool ((.contentAsStreamThunk entry))) (let [entry (findEntry typeName classEntries) "return the CtClass corresponding to the given name, or nil" (first (filter (fn (= typeName (pathToTypeName (.path e)))) classEntries))) "return the ClasspathElement corresponding to the given name, or nil" Path'' (clojure.string/replace path' #"/" ".") (let [path' (.substring path 0 (- (.length path) 6)) (filter (fn (.endsWith (.path e) ".class")) (getElementsEntriesInJar pathToJarFile))) (map (partial jarEntryToClasspathElement jarfile) entries'))) (let (defn- jarEntryToClasspathElement Ĭontent (fn (.getInputStream jarFile jarEntry))] An element on the classpath (a single class, interface, enum or resource file) For performance reasons we could want to build a cache of elements contained in a given JAR. To do so, we would need to open the JAR files and look among its contents.

Our symbol solver should look among a list of entries (our classpath entries) in order, and see if a certain class can be found there. Build a model of classes contained in JAR files Javaparser provides to us the ASTs we need for the first point, for the second one we are going to build a model of classes in JAR files using Javassist.

among the classes contained in the JAR files used as dependencies.

on the ASTs of the classes of the project we are examining.

So to solve symbol we need to look for corresponding declarations: However one key point is that to solve symbols we need to look among imported classes, extended classes and external classes in general which may be part of the project or be imported as dependencies. It is especially complex to resolve methods, because of overloading. Now, scoping rules are much more complex than the bunch of little steps I just described. If we cannot still find a correspondence we need to look among the fields declared by the class and if have still no luck we may have to luck among the fields inherited by this class. If not we can look among the parameters of that method. For example we may look if a certain symbol corresponds to a local variable. To solve symbols we can navigate the AST and apply scoping rules. Are they references to local variables? To arguments of the current method? To fields declared in the class? To fields inherited from a super-class class? What type they have? To answer this question we need to be able to resolve symbols. We need to figure out what foo, method, a, b, c are.