8003562: Provide a command-line tool to find static dependencies (original) (raw)

Mandy Chung mandy.chung at oracle.com
Wed Nov 28 20:50:13 UTC 2012

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

More information about the core-libs-dev mailing list