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.

Bug 46284 - J2SEProject should provide ability to set compile heap size even using default platform
Summary: J2SEProject should provide ability to set compile heap size even using defaul...
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P3 blocker with 1 vote (vote)
Assignee: Tomas Zezula
Depends on:
Blocks: 41537
  Show dependency tree
Reported: 2004-07-19 13:45 UTC by tboerkel
Modified: 2004-08-31 15:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

build.xml (5.39 KB, text/plain)
2004-07-19 13:45 UTC, tboerkel
Details (2.26 KB, text/plain)
2004-07-19 13:46 UTC, tboerkel
build-impl.xml (23.65 KB, text/plain)
2004-07-19 13:47 UTC, tboerkel
Ant debug output. (39.66 KB, text/plain)
2004-07-19 14:25 UTC, tboerkel

Note You need to log in before you can comment on or make changes to this bug.
Description tboerkel 2004-07-19 13:45:22 UTC
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\build.xml:40: Error running
${platform.javac} compiler
BUILD FAILED (total time: 4 seconds)

Using NB 20040715. Attaching build.xml and
Comment 1 tboerkel 2004-07-19 13:45:50 UTC
Created attachment 16311 [details]
Comment 2 tboerkel 2004-07-19 13:46:16 UTC
Created attachment 16312 [details]
Comment 3 tboerkel 2004-07-19 13:47:15 UTC
Created attachment 16313 [details]
Comment 4 tboerkel 2004-07-19 14:25:08 UTC
Created attachment 16319 [details]
Ant debug output.
Comment 5 Jesse Glick 2004-07-19 20:36:08 UTC
Correcting component...
Comment 6 Jesse Glick 2004-07-19 20:38:15 UTC
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.
Comment 7 tboerkel 2004-07-20 07:46:19 UTC
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
Comment 8 Tomas Zezula 2004-07-20 08:17:48 UTC
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.
Comment 9 tboerkel 2004-07-20 08:50:51 UTC
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


Comment 10 Tomas Zezula 2004-07-20 14:29:32 UTC
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
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.
Comment 11 tboerkel 2004-07-20 14:39:08 UTC
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).
Comment 12 Tomas Zezula 2004-07-20 15:11:13 UTC
I agree with you and I will ask the UI people about it.
Comment 13 Tomas Zezula 2004-07-21 14:17:04 UTC
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).
Comment 14 tboerkel 2004-07-21 21:09:14 UTC
People have to know, that Default Platform is the same as Internal
Compiler in NB 3.6.
Comment 15 tboerkel 2004-07-21 21:26:31 UTC
Last try to set the summary correct...
Comment 16 Tomas Zezula 2004-07-29 13:31:25 UTC
Can't be scheduled to promo-D because of UI freeze.
Comment 17 Tomas Zezula 2004-08-26 22:19:56 UTC
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 ***
Comment 18 Jesse Glick 2004-08-27 02:57:00 UTC
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.)
Comment 19 Tomas Zezula 2004-08-30 10:46:27 UTC
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.
Comment 20 Jesse Glick 2004-08-30 23:11:51 UTC
"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.
Comment 21 Tomas Zezula 2004-08-31 09:29:02 UTC
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.
Comment 22 Jesse Glick 2004-08-31 14:03:06 UTC
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.
Comment 23 Tomas Zezula 2004-08-31 15:16:22 UTC
Current broken reference support does not solve the problem, the
systemName is not the java edition, specification number, profiles and
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.
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.
I can change the state to WANTFIX. I don't want to have 3 versions of
Comment 24 Jesse Glick 2004-08-31 15:17:44 UTC
OK with me.