8003562: Provide a command-line tool to find static dependencies
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
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
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
> 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
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.
More information about the core-libs-dev