Back from trying to figure out all the cases where jdeps and my utility don't compute the same dependencies, for classes of JDK8_60/rt.jar, and each time which is right.
What I did is modify my code to make it behave like jdeps for each encountered difference, and then re-run the comparison to see what was left. Below I list all the cases for usage of jdeps with "-verbose:class -filter:none" options, i.e. when computing all dependencies, API or not (with "-apionly" option there were many more differences, possibly due to assumptions about what "API" means - we could exclude that for now). 1) Jdeps ignores dependencies caused by package-info class files. ===> Maybe intended? Ex.: @javax.xml.bind.annotation.XmlSchema(namespace = "http://xmlns.oracle.com/webservices/jaxws-databinding";, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) package com.oracle.xmlns.internal.webservices.jaxws_databinding; ===> Doesn't see dependencies to java.lang.Object and javax.xml.bind.annotation.XmlSchema 2) Jdeps ignores types of parameters of annotations (as said in initial mail). Ex. (in java.beans): @Documented @Target(CONSTRUCTOR) @Retention(RUNTIME) public @interface ConstructorProperties { String[] value(); } ===> Doesn't see dependencies to java.lang.annotation.ElementType and java.lang.annotation.RetentionPolicy. ===> Could reproduce the behavior by ignoring/skipping "element_value" items. 3) Jdeps doesn't parse class signatures containing generic types properly, but it does fine for fields or methods signatures. Ex. (in java.lang.management.PlatformComponent): interface MXBeanFetcher<T extends PlatformManagedObject> { public List<T> getMXBeans(); } ===> Doesn't see dependency to java.lang.management.PlatformManagedObject. ===> For example, dependency to Object is properly computed from signature "Ljava/lang/ThreadLocal<Ljava/lang/Object;>;" but not from "<E:Ljava/lang/Object;>Ljava/lang/ThreadLocal<TE;>;". ===> Could reproduce the behavior by skipping all characters following ':' up to the '>' closing the scope. 4) Jdeps doesn't compute a dependency to java.lang.Deprecated when @deprecated or @Deprecated is only in the Javadoc, in which case there is no "Ljava/lang/Deprecated;" descriptor/signature in the class file but still a "Deprecated" attribute. ===> Maybe intended? Ex.: javax.xml.bind.Validator ===> Could reproduce the behavior by skipping "Deprecated" attributes, and only having dependency to java.lang.Deprecated due to the descriptor/signature. 5) Jdeps ignores (some? all?) dependencies to com.sun.istack.internal.NotNull and com.sun.istack.internal.Nullable Ex. (in com.sun.istack.internal.Pool): public interface Pool<T> { @NotNull T take(); void recycle(@NotNull T t); } ===> Doesn't see dependencies to com.sun.istack.internal.NotNull ===> Could not find a way to reproduce this behavior, other than having specific cases for these annotations. I created a similar test class, with a similar annotation @MyNotNull, and jdeps would detect it (???). 6) For java.util.stream.FindOps, jdeps properly doesn't compute a dependency to java.util.stream.TerminalSink (which is only used in nested classes), but for some reason there is a "()Ljava/util/stream/TerminalSink;" descriptor in FindOps.class (???) so my library considers there is the dependency... Lastly a few remarks about -apionly: jdeps help says it restricts the analysis to dependences "from the signature of public and protected members of public classes including field type, method parameter types, returned type, checked exception types etc" But: 1) It can actually compute dependencies from a protected, package-private or private class, for example if they have public fields. Maybe it should not be the case for (package-)private classes (or whenever there is a non-API class in the way to the top level class), because it would show transitive dependencies that could not be followed through the API. (Ex.: private class Priv {public Double getDouble(){...}} public class Pub {public Priv getPriv(){...}} ===> Through the API we could never go from Pub to Double but according to jdeps it would be possible.) 2) It does not consider public and protected nested classes as dependencies (even though they are in the API of the class). 3) Should annotations of APIs be considered APIs? (at least for some trivial cases they are) -Jeff De : Jeff Hain <jeffh...@rocketmail.com> À : Mandy Chung <mandy.ch...@oracle.com>; "jigsaw-dev@openjdk.java.net" <jigsaw-dev@openjdk.java.net> Envoyé le : Jeudi 27 août 2015 23h24 Objet : Re: jdeps and annotations parameters >It looks like a bug. I have filed an issue to look into further: > https://bugs.openjdk.java.net/browse/JDK-8134625 >Mandy Ok. I was starting to check my jdeps-like library(an upgrade of sourceforge.net/projects/jcyclesto compute dependencies in various ways and with more info(deps byte size, classes causing packages dependencies, etc.))against jdeps on all rt.jar class files, and I'm starting to see a lot moredifferences. The idea was both:- to check correctness of libraries against each other,- and, where dependency-or-not would be conventional (such as, should a nested class always depend on its surrounding class, or not, or on all of them up to top level one (since they are all in InnerClasses attributes), etc.) to use jdeps convention to keep things simple. I will send you details (off list?) when I got them (with and without -apionly) (test does Runtime.exec(jdeps) for each class, takes time :). Then you could tell me what looks like a bugand what looks like a convention. -Jeff
