Bugs like bug #292534 suggest that it should be possible to pass a -Xmx to a ecj invocation in order to increase the maximum heap size available to the compiler. The current launch setup doesn't implement this, though. Therefore I suggest the following code for the launch script, e.g. for ecj-3.3: #!/bin/bash gjl_package=eclipse-ecj-3.3 gjl_main="org.eclipse.jdt.internal.compiler.batch.Main" ecj_args=( ) while [[ $# -ge 1 ]]; do case "$1" in -Xmx*) gjl_java_args="${gjl_java_args} $1" ;; *) ecj_args=( "${ecj_args[@]}" "$1" ) ;; esac shift done set -- "${ecj_args[@]}" unset ecj_args source /usr/share/java-config-2/launcher/launcher.bash You might even want to implement the generation of such a launcher in some eclass, where the pattern to be matched by the case could be given as an argument. Up to you.
Actually to match javac behavior, it should not process -Xmx, but any parameter starting with -J should be passed to java (without the -J), so the parameter is passed as -J-Xmx786M in gnu-classpath you mention. To implement it in the whole gjl launcher would work too, but since it's expected only for javac compiler, it would be a nonstandard solution that nobody uses. We already have a way to pass java args to gjl launchers (also nonstandard, but already done :) Perhaps a general standard solution would be JAVA_OPTS.
(In reply to comment #1) > To implement it in the whole gjl launcher would work too, but since it's > expected only for javac compiler, it would be a nonstandard solution that > nobody uses. We already have a way to pass java args to gjl launchers (also > nonstandard, but already done :) Perhaps a general standard solution would be > JAVA_OPTS. I know about gjl_java_args, as the fix for bug #292534 works this way. I see little benefit in renaming that variable to JAVA_OPTS, because it's still nonstandard, only now the name doesn't clearly say so, and the chance of a name collision is much greater. I'm more concerned in the way third party build scripts use ecj. The fact that the gnu-classpath make files pass -Xmx to ecj suggests that there are ecj versions out there which might accept it. Dunno how standard these are. So my prime concern is not match ejc to javac, but to match our ecj to the ecj scripts other distros and the upstream packages have - although I haven't investigated these so far.
eclipse-ecj-3.3 is gone. Closing.
