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
