8003562: Provide a command-line tool to find static dependencies

[Mandy Chung]

On 11/28/2012 11:53 AM, Alan Bateman wrote:
>
> I suspect you will get a lots of feedback on the output once people 
> get a chance to try it out. 

That's what I expect too :)

> Personally I think I would print the code source against each of the 
> dependence if it's in a JAR file (might be more than one). That makes 
> inter-dependencies obvious when giving it a list of JAR files. 

-P will show the source or profile name.  I initially had the default to 
print the code source but the output looks a bit clutter as it includes 
the source of the platform API as well.  I agree with you that including 
the code source will make the inter-dependencies obvious especially from 
JAR files.   What about by default printing the code source if the 
dependence is from the input files or -classpath option but exclude the 
platform API.  So the -P option is to show the platform/profile 
information (i.e. either the profile name or the code source from JDK).

> For missing types then I think I would print something like "not 
> found" as the code source rather than a series of warnings at the 
> beginning. 

It shows "null" currently and s/null/found makes sense.

> The other way I'd probably use is to just give it the application's 
> usual classpath (application and libraries) and have it print the 
> dependencies on the platform and other libraries, ie: don't print 
> intra-dependencies. 

I have been thinking about that use case.  It would analyze all classes 
given in the -classpath option.

> I think if there were just the two modes -classpath and -d might not 
> be needed. 

I wasn't sure if -d might be needed or not.  I would be interested in 
finding out all transitive dependencies to see what dependencies other 
libraries may pull in.  I think -d 0 and -d 1 (default) would be 
useful.  -d 0 would often give lot of output and I was thinking 
specifying the depth would help the diagnosis when unexpected 
dependencies are found and certainly we need to experiment it further to 
see if we should keep -d or not.

> I'm also not sure if -r is needed. 

I think -r together with -p or -e would be useful to diagnose what 
classes reference a specific type or package when such dependency is 
unexpected.

> I think -v is very useful and arguably should be the default with a 
> -package option to get more terse output (I don't have strong opinion 
> on which should be the default, just good to see that it has both).
>

We can evaluate the default when we will get more feedback.  Essentially 
there are 3 level of dependency granularity:
1. class level
2. package level
3. code source level (no intra-dependencies) - this is like the 
cross-module dependencies.

I'll leave the package level as the default.

> I realize the profiles.resources is just temporary but just an FYI 
> that there are only 3 profiles proposed at this time: compact1, 
> compact2 and compact3.
>

I have overloaded it to include other supported APIs.  Perhaps I should 
rename it to jdk.properties

> Otherwise I think it will be great to have this tool in the JDK, will 
> be very useful.
>

Thanks for the feedback.

Mandy