jdeps and annotations parameters

[Mandy Chung]

Just to double check: are you using 8u60 jdeps?  or jdk9 jdeps?

Mandy

On 09/01/2015 11:59 AM, Jeff Hain wrote:
>
> 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 <jeffhain at rocketmail.com>
> *À :* Mandy Chung <mandy.chung at oracle.com>; 
> "jigsaw-dev at openjdk.java.net" <jigsaw-dev at 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/jcycles
> to 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 
> more
> differences.
>
> 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 bug
> and what looks like a convention.
>
>
>
>
> -Jeff
>
>
>