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.
If the option executable="${platform.javac}" is set for javac in build.xml (which is currently the default in build-impl.xml), then I cannot compile for the default platform. I have to set the project to a specific platform, even if it is the same as the default. On the other hand, this option is needed, if you want to be able to compile to a different platform. I am using netbeans_jdkhome=D:\JDK1.4.2_05 in netbeans.conf to run NB with JDK 1.4.2_05 and my system default platform is JDK 1.5 beta 3 snapshot. I have defined both platform in the NB platform manager, in addition to the default. This is the error from building: D:\AppserverNB40\nbproject\build-impl.xml:236: D:\AppserverNB40\build.xml:40: Error running ${platform.javac} compiler BUILD FAILED (total time: 4 seconds) Using NB 20040715. Attaching build.xml and project.properties.
Created attachment 16311 [details] build.xml
Created attachment 16312 [details] project.properties
Created attachment 16313 [details] build-impl.xml
Created attachment 16319 [details] Ant debug output.
Correcting component...
Not a bug, I think. You have manually overridden the usage of <javac> and your version does not work. ${platform.javac} is not intended to be set when using the default platform; the IDE-generated script in this case will use the internal compiler. If you wish to use the external compiler you probably meant to set compiler="extJavac" rather than specifying the executable.
I got the executable="${platform.javac}" option from build-impl.xml. OK, now I removed that and added compiler="extJavac", but now I get this warning: Since compiler setting isn't classic or modern, ignoring fork setting. Also, again I cannot compile to a different platform anymore. I am starting NB with JDK 1.4.2_05, choose JDK 1.5 as platform for my project and get this error: javac: invalid target release: 1.5 Usage: javac <options> <source files> ... So, this isn't solved, yet. There must be something additional I am missing in my build.xml, I guess. Also, may I suggest, to provide GUI options for: - internal or external compiler - heap memory setting or options string for external compiler
The value of ${platform.javac} is valid only in the case of non default platform. In case of default platform (the platform IDE runs on) the value is not set since the compiler is not forked. If you need to modify/extend your build.xml to allow compilation with explicit platform you have to set non default platform in the IDE. This probably will not change. The UI options for internal or external compiler and heap memory setting or options string for external compiler seems to me useful. But I am afraid it will be not in the promo-D, the UI is already frozen for this release. Will be addressed in the promo-E.
Actually, we only needed explicit compiler settings in build.xml because of the compiler heap memory. We need 170 MB to compile our project and the IDE normally only has 130 MB alltogether. So, we need external compilation. So, is there no possibility in the current version to: - get external compilation with heap setting - have ability to switch to another platform - work also with default platform ?
Unfortunatelly there is no UI setting for it now. But you can do it in the build.xml. There are two ways how to run compilation with eg. 170 MB. 1) Increase the heap size used by IDE to IDE size + requested size for compilation and use the default platform (which runs compilation in the IDE jvm). The memory size can be changed in the netbeans/etc/netbeans.conf 2) Create non default platform and set it in the project. Override the -init-macrodef-javac task in the build.xml. The new -init-macrodef-javac task should be the same as the default one but add memoryMaximumSize attribute.
2) is exactly what I did, because giving NB additional 170 MB all the time is too much. But don't you think, that's too complicated? 4.0 UI may be frozen, but this is too cumbersome for a 4.0. Most users are no Ant experts (and should not have to be).
I agree with you and I will ask the UI people about it.
The issue should be rather named "J2SEProject should provide UI for setting compile heap size". The default platform will never allow you to set a compiler heap size since the defaul platform runs in the IDE jvm (the heap is alredy given at the IDE start). This is the biggest difference between explicit and default platform. Explicit platform is more customizable but the compilation is slower (needs to start new JVM).
People have to know, that Default Platform is the same as Internal Compiler in NB 3.6.
Last try to set the summary correct...
Can't be scheduled to promo-D because of UI freeze.
This issue is a duplice of the enhancement #46995: "Allow setting more javac options in j2seproject's" which is already fixed. You can specify the -J-Xmx256M option to the additional javac parameters in J2SEProject properties/Compile Sources. Of course the platform must be the non default one. The default platform runs in the IDE memory space. *** This issue has been marked as a duplicate of 46995 ***
I don't think it's a duplicate; Thomas was talking about the situation that he wishes to use the default platform, just running javac in forked mode with VM args. For 4.0 at least, you can do this by overriding -init-macrodef-javac to use compiler="extJavac" and pass nested <jvmarg>s. (I think; haven't tried it.)
The default platform is identical to non default one created for jdk given by ${JDK_HOME}. The default platform was always problematic. Personally I think it should not be there (and 1st project creation should force you to create new platform, the same way Idea does). The only reason for default platform are small projects since the default platform runs javac in the IDE heap (speed up of compilation). But for bigger projects user should use the non standard platform. Overriding -init-macrodef-javac to use compiler="extJavac" and pass nested <jvmarg>s is the same as defining non standard platform.
"Overriding -init-macrodef-javac to use compiler="extJavac" and pass nested <jvmarg>s is the same as defining non standard platform." - not really, because defining a non-default platform means making your build reliant on the user setting a path to a particular JDK. Many real-life build scripts use an external compiler with the default platform (i.e. Ant's JDK) so they can set the compiler heap size and other such things. So I still don't think this request was addressed at all. However we may have reasons to not want to ever address it, in particular the complexity it would add.
Jesse I agree, but I think that defining explicit platform is a reasonable way how to solve the problem with javac memory size. Overriding ant target is another way, I've already described above, but this is not acceptable for ordinary user. Other solution is to add fork flag into project.xml which will cause the default platform to run as forked process (as the non default platform does), but I don't think we want to do this. If someone needs it, he should define explicit platform. The only problem of the explicit platform is its sharability, which should be solved in next release.
How could sharability of an explicit platform be solved in the next release? We already use an abstract token name for the platform that you can set to whatever you like. But each user still needs to define that path manually (though the Broken References dialog makes this less painful). Using a relative path (the only way to make it sharable with no additional setup) is unlikely to be useful for many people; few people keep a dedicated copy of the JDK around in their project dir. Conversely, Ant lets you fork javac and pass it VM parameters without having to explicitly specify its location, which is useful. As you say, we would probably need a third option in project.xml to use the default platform but fork javac. (Or might be some way to do this entirely with Ant properties.) Again, I'm not saying we need to do this, just disagreeing that this request was in fact handled.
Current broken reference support does not solve the problem, the systemName is not the java edition, specification number, profiles and vendor. Something like: There is no MyJDK platform. Is much more worse than something like: Missing J2SE Platform 1.5 Vendor: Sun Microsystems I think that current fix solves the reported problem (Thomas was not able to compile his project. Agree he needs to switch platforms, but I don's see any strong opinion against it). But Thomas also wants us to document the behaviour of default platform. <cite> Additional Comments From Thomas Boerkel 2004-07-21 13:09 PDT People have to know, that Default Platform is the same as Internal Compiler in NB 3.6. </cite> I can change the state to WANTFIX. I don't want to have 3 versions of build-impl.xml.
OK with me.