Community
Participate
Working Groups
The -J option of the eclipse java compiler is currently reported as being ignored, and likely is. Because of this, ecj may fail with the large projects like GNU Classpath when the compiler runs out of the allowed memory. With the recent GNU Classpath CVS head, the following message was observed: /usr/bin/ecj -1.5 -J-Xmx400m -warn:-deprecation,serial,typeHiding,unchecked,unused,varargsCast -proceedOnError -bootclasspath '' -classpath ../vm/reference:..:../external/w3c_dom:../external/sax:../external/relaxngDatatype:../external/jsr166:.:: -d . @classes incorrect classpath: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space When using Sun's javac, the -J-Xmx400m options helps to pass this place of compilation, asking to give more memory. Without this option, javac fails exactly with the same out of memory error and on the same build line as well. Reported against Eclipse Java Compiler v_585_R31x, 3.1.2 release under Fedora Linux (i686 architecture)
Can we do something here, since we are not building the executable ourselves.
The trivial workaround is to find the ecj startup scrip (this may be the /bin/ecj or something like that) and manually edit it how needed (the script contains the commands to launch the eclipse with the default java virtual machine). The real solution would be to provide a startup loader that would check the options, needed to pass to the virtual machine, and would pass them. This likely should be written in C.
Closing as INVALID. We don't build the executable or provide the script. This should be done when building the executable or inside the script.
