[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