This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I do a clean-build on a project and get the following error, ------------------------------------------------------------------- init: deps-clean: Deleting directory C:\my folder\dev\java\projects\TestProjects\build Deleting directory C:\my folder\dev\java\projects\TestProjects\dist clean: init: deps-jar: Created dir: C:\my folder\dev\java\projects\TestProjects\build\classes Compiling 396 source files to C:\my folder\dev\java\projects\TestProjects\build\classes The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space BUILD FAILED (total time: 2 minutes 16 seconds) --------------------------------------------------------- The project has many source files most of which (about 1000) have been excluded, through the include/exclude option at the project properties. As shown by the log the number of sources compiled is 396 source files. In order to avoid this error I have to add in the build.xml file the <target name="-init-macrodef-javac">.....</target> as specified in the build-impl.xml overriding this target's following line, <javac debug="@{debug}" deprecation="${javac.deprecation}" destdir="@{destdir}" encoding="${source.encoding}" excludes="@{excludes}" executable="${platform.javac}" fork="yes" includeantruntime="false" includes="@{includes}" source="${javac.source}" sourcepath="@{sourcepath}" srcdir="@{srcdir}" target="${javac.target}" tempdir="${java.io.tmpdir}"> with this one, <javac debug="@{debug}" deprecation="${javac.deprecation}" destdir="@{destdir}" encoding="${source.encoding}" excludes="@{excludes}" executable="${platform.javac}" fork="yes" memoryMaximumSize="1024m" includeantruntime="false" includes="@{includes}" source="${javac.source}" sourcepath="@{sourcepath}" srcdir="@{srcdir}" target="${javac.target}" tempdir="${java.io.tmpdir}"> adding the memoryMaximumSize="1024m", (512 was not enough) The question is whether there is some other way of solving this problem. Is it an ant problem is there a way not to use ant from a netbeans option and not get this error? It seems to me that a lot of resources are required for not that large amount of files. The behaviour in 6.1 was really dissapointing sometimes the IDE just dissapeared. The memory options -xms and MaxPermSize have both been set to 256m in netbeans.conf (this was also necessary in 6.1 otherwise it just crashed). I really like netbeans but i get the feeling that the overall memory management is an issue since the IDE seriously slows down or even not responds for some time when opening the whole project group or making simple changes on of the projects i.e. add/remove a library. The project group consists of about 10 projects each of which have about 200 source files. Unforunatelly even when the IDE does not throw this error (after the patched build.xml) the time required to clean- build is very long, sometimes the IDE might crash. I have 2GB of RAM and a 32-bit cpu with 2 cores and 3.19 GHz
Are you able to run the same script with same Ant and same JDK on command line without increased memory? Might be bug/memory leak in compiler.
http://wiki.netbeans.org/FaqOutofMemoryOnCompile Leaving open in case there is not already an issue (probably in j2seproject) to either set these flags automatically when the project gets "big" (though it is very hard to predict in advance how much heap a compilation is going to need), or at least to provide a UI for setting them, e.g. (X) Compile inside IDE ( ) Compile externally with _____ Mb heap
i will try from command line and give feedback!!
hmm
same results from command line, had to increase memory through ANT_OPTS (one of the options for assigning jvm params to ANT)
Bug prior to 7.0, not touched for the last 2 years --> P4.
The UI should be added.
You can seen the online site here http://mycomputerwindows10.com and get the all function to access desktop computers windows 10 for the batter working.