[Patch] Java: Add heap dump and analyze support.
Tom Tromey
tromey@redhat.com
Wed Feb 7 22:37:00 GMT 2007
>>>>> "David" == David Daney <ddaney@avtrex.com> writes:
David> New version of the patch:
Thanks. I'm afraid I have one blocking concern.
David> Index: libjava/classpath/lib/Makefile.am
[...]
David> +gcj_tools_classpath = $(top_srcdir)/tools/classes
David> +compile_classpath = $(vm_classes):$(top_srcdir):$(top_srcdir)/external/w3c_dom:$(top_srcdir)/external/sax:$(top_srcdir)/external/relaxngDatatype:$(top_srcdir)/external/jsr166:.:$(USER_CLASSLIB):$(PATH_TO_ESCHER):$(gcj_tools_classpath)
We purposely avoid putting the tools classes into the core class path.
This avoids any chance of a dependency on tools stuff by the core;
this would be bad due to the use of ASM in the tools.
I wonder if we could fix this by putting the new tool code into
standard.omit, and then compile it separately using a special rule of
some kind, with a classpath pointing to the tools zip.
David> + if (rest.length != 1)
David> + {
David> + optionParser.printHelp();
David> + System.exit(1);
David> + }
It is somewhat better to put checking code like this into a validate()
method which throws OptionException. This yields more "GNU like"
output.
Tom
More information about the Java-patches
mailing list