You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jay Handfield <ja...@ia.com> on 2000/03/22 21:11:49 UTC
[PATCH]: Added maxmemory option to javadoc task
Hello,
When building the javadocs for my project, I kept getting
out of memory exceptions. The ideal solution to this problem
would be to have javadoc run in process and set the max memory
higher via the JAVACMD variable, but I understand that this is not
possible because the sun class calls System.exit(). As an
alternative I have come up with a patch to the javadoc task that
will allow you to set the maximum memory of the javadoc JVM. For
example,
<javadoc srcdir="myproj" maxmemory="64m"/>
will add a -J-Xmx64m to the javadoc command line (under java2).
Does this seem like a reasonable solution? I would be happy to
supply a patch for the documentation also, if this patch gets applied.
Thanks,
Jay Handfield
Re: [PATCH]: Added maxmemory option to javadoc task
Posted by Jay Handfield <ja...@ia.com>.
Hello,
Thomas Haas wrote:
>
> Jay Handfield wrote:
>
> Solution 2) and 3) look both very promising. As Sam Ruby pointed out in another email, disabling
> the call to fork can be done in the subclass.
I am willing to add more command line options like max and min memory to
the Java task this weekend using solution 2. However I just noticed an
obstacle to having the Javadoc task extend the Java task. It turns out
that the Javadoc task is actually execing the javadoc shell script on
the command line instead of java? Looking at the CVS log I can see the
switch from java to javadoc was done relatively recently.
The log message indicates the problem was that there was that the
tools.jar was not getting into the classpath of the child JVM, which was
running the child java sun.tool.javadoc.Main class. To solve this
problem Stefano switched to using the javadoc shell script instead,
which does includes the tools.jar automatically. I think we will need
to find a different way to solve this problem before we are able to
switch the Javadoc task to inherit from the Java task. How about using
the java.home property to add the tools.jar to the child java classpath
task automatically? Is the java.home property always available (it
seems to be on my systems)?
> If you are going to hack on the Exec/Java task, I have other suggestions (and I am willing to help
> implementing):
>
> * Implement the funcionality of Exec/Java in a seperate class not inheriting from Taskdef so it
> can be used in others. Rational: The Javac and Jikes tasks reimplement features of Java,
> because they extend MatchingTask and multiple inhertiance is not possible.
> * Exec should use Runtime.exec(String[]) instead of Runtime.exec(String), which would eliminate
> the need for the runAnt shell script and ease using arguments with spaces.
> * Subtaskes should be able to put filters on the output/inputstream to/from the spawned
> processes. Jikes could profit from this.
These sound like good ideas to me. But I would like to finish getting
some version of the maxmemory option into the Javadoc task first, both
because I really need this on my project and because I prefer to develop
in incremental steps (especially on a project I am just learning). Once
that happens I would be happy to help you implement these things.
Thanks,
Jay
Re: [PATCH]: Added maxmemory option to javadoc task
Posted by Thomas Haas <th...@softwired-inc.com>.
Jay Handfield wrote:
> Possible solutions:
>
> 1) The quick fix is for me to add my maxmemory option to the
> java task as well.
>
> 2) More uniformly, we could add options to the java task for more (all?)
> of the java command line options. For example, maybe there should be an
> option for minimum heap size also? We may want to split the in-process
> and out-of-process java tasks if we do this?
>
> 3) Another uniform solution would be to add a resolveJvmArgs method to
> the Java task that rewrites the JVM args to take the Java version into
> account (Much like translatePath takes the OS dependencies into
> account.)
>
> What do other people think? I would be happy to implement any changes
> people think we need.
Solution 2) and 3) look both very promising. As Sam Ruby pointed out in another email, disabling
the call to fork can be done in the subclass.
If you are going to hack on the Exec/Java task, I have other suggestions (and I am willing to help
implementing):
* Implement the funcionality of Exec/Java in a seperate class not inheriting from Taskdef so it
can be used in others. Rational: The Javac and Jikes tasks reimplement features of Java,
because they extend MatchingTask and multiple inhertiance is not possible.
* Exec should use Runtime.exec(String[]) instead of Runtime.exec(String), which would eliminate
the need for the runAnt shell script and ease using arguments with spaces.
* Subtaskes should be able to put filters on the output/inputstream to/from the spawned
processes. Jikes could profit from this.
- tom
Re: [PATCH]: Added maxmemory option to javadoc task
Posted by Jay Handfield <ja...@ia.com>.
Hello,
Thomas Haas wrote:
> How about putting it into the Java task and let Javadoc extend Java (with fork=true by
> default), so the feature would be available to other java tasks, which run in VM on their own
I think you can already increase the memory of a forked javadoc task by
doing something like:
<java fork=true class=Main jvmargs="-Xmx32m">
Mmmm, I guess the current jvmargs option does the have the disadvantage
that your build file must contain knowledge about which version of Java
you are using, i.e. for a Java 1 you would need to write
<java fork=true class=Main jvmargs="-mx32m">
instead.
Possible solutions:
1) The quick fix is for me to add my maxmemory option to the
java task as well.
2) More uniformly, we could add options to the java task for more (all?)
of the java command line options. For example, maybe there should be an
option for minimum heap size also? We may want to split the in-process
and out-of-process java tasks if we do this?
3) Another uniform solution would be to add a resolveJvmArgs method to
the Java task that rewrites the JVM args to take the Java version into
account (Much like translatePath takes the OS dependencies into
account.)
What do other people think? I would be happy to implement any changes
people think we need.
Your idea of having the Javadoc task inherit from the Java task also
seems like a good idea. My only concern is how should we handle someone
turning fork off in the Javadoc task? Is this legal or do we prevent it
in the code?
Again, I would be happy to make this change if people think it is a good
idea.
> (like the JUnit task I submitted and my metamata task, which will be sent to this list soon,
> and others we are about to create).
I am looking forward to giving your Junit task a test drive.
Thanks,
Jay Handfield
Re: [PATCH]: Added maxmemory option to javadoc task
Posted by Thomas Haas <th...@softwired-inc.com>.
Hi
Nice feature.
How about putting it into the Java task and let Javadoc extend Java (with fork=true by
default), so the feature would be available to other java tasks, which run in VM on their own
(like the JUnit task I submitted and my metamata task, which will be sent to this list soon,
and others we are about to create).
- tom
Jay Handfield wrote:
> Hello,
>
> When building the javadocs for my project, I kept getting
> out of memory exceptions. The ideal solution to this problem
> would be to have javadoc run in process and set the max memory
> higher via the JAVACMD variable, but I understand that this is not
> possible because the sun class calls System.exit(). As an
> alternative I have come up with a patch to the javadoc task that
> will allow you to set the maximum memory of the javadoc JVM. For
> example,
>
> <javadoc srcdir="myproj" maxmemory="64m"/>
>
> will add a -J-Xmx64m to the javadoc command line (under java2).
>
> Does this seem like a reasonable solution? I would be happy to
> supply a patch for the documentation also, if this patch gets applied.
>
> Thanks,
> Jay Handfield
>
> ------------------------------------------------------------------------
> Index: Javadoc.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Javadoc.java,v
> retrieving revision 1.7
> diff -u -r1.7 Javadoc.java
> --- Javadoc.java 2000/03/03 14:15:42 1.7
> +++ Javadoc.java 2000/03/21 23:39:53
> @@ -79,6 +79,7 @@
>
> public class Javadoc extends Exec {
>
> + private String maxmemory = null;
> private String sourcePath = null;
> private File destDir = null;
> private File overviewFile = null;
> @@ -120,6 +121,10 @@
> private String docencoding = null;
> private Vector compileList = new Vector(10);
>
> + public void setMaxmemory(String src){
> + maxmemory = src;
> + }
> +
> public void setSourcepath(String src) {
> sourcePath = project.translatePath(src);
> }
> @@ -250,6 +255,15 @@
> // ------------------------------------------------ general javadoc arguments
> if (classpath == null)
> classpath = System.getProperty("java.class.path");
> +
> + if(maxmemory != null){
> + if(javadoc1){
> + argList.addElement("-J-mx" + maxmemory);
> + }
> + else{
> + argList.addElement("-J-Xmx" + maxmemory);
> + }
> + }
>
> if ( (!javadoc1) || (sourcePath == null) ) {
> argList.addElement("-classpath");