This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [Patch] Java: Add heap dump and analyze support.
- From: Tom Tromey <tromey at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org, "Johannes P. Schmidt" <jschmidt at avtrex dot com>
- Date: 07 Feb 2007 13:25:25 -0700
- Subject: Re: [Patch] Java: Add heap dump and analyze support.
- References: <45AEB57B.5090807@avtrex.com> <m3y7ntld3x.fsf@localhost.localdomain> <45BE8A03.6040101@avtrex.com>
- Reply-to: tromey at redhat dot com
>>>>> "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