You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2006/11/24 12:25:11 UTC
[classlib] incremental build is no more?
I can't recall how many days I have to do full rebuild after updating
workspace in the morning, because just "ant" complained about java
compilation errors...
I did not give that much consideration until today, when trivial local
modification in luni class did not compile again. Could someone adept
in classlib build look into this, please?
Just added empty line in SecurityManager.java:
>ant build-java -Dbuild.module=luni
...
-compile:
[javac] Since compiler setting isn't classic or modern,ignoring fork setting
.
[javac] Compiling 1 source file to C:\apache-dev\Harmony\trunk\working_class
lib\build\classes
[javac] Since compiler setting isn't classic or modern,ignoring fork setting
.
[javac] ----------
[javac] 1. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 66)
[javac] security.checkPermission(RuntimePermission.permissionToCreateSec
urityManager);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^
[javac] RuntimePermission.permissionToCreateSecurityManager cannot be resolv
ed
[javac] ----------
[javac] 2. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 107)
[javac] checkPermission(RuntimePermission.permissionToModifyThread);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] RuntimePermission.permissionToModifyThread cannot be resolved
[javac] ----------
[javac] 3. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 124)
[javac] checkPermission(RuntimePermission.permissionToModifyThreadGroup)
;
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] RuntimePermission.permissionToModifyThreadGroup cannot be resolved
[javac] ----------
[javac] 4. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 174)
[javac] checkPermission(RuntimePermission.permissionToCreateClassLoader)
;
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] RuntimePermission.permissionToCreateClassLoader cannot be resolved
[javac] ----------
[javac] 5. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 207)
[javac] checkPermission(RuntimePermission.permissionToExitVM);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] RuntimePermission.permissionToExitVM cannot be resolved
[javac] ----------
[javac] 6. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 272)
[javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
()) {
[javac] ^^^^^^^^^^^^^^^^^^^
[javac] The method getStackClassLoader(int) is undefined for the type ClassL
oader
[javac] ----------
[javac] 7. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
i\src\main\java\java\lang\SecurityManager.java
[javac] (at line 272)
[javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
()) {
[javac] ^^^^^^^^^^^^^^^^^^
[javac] The method getClassLoaderImpl() is undefined for the type Class<capt
ure-of ?>
[javac] ----------
<snip>
--
Alexey
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Matt Benson wrote:
> Or talk to the jdt/ecj team: 1) why they set
> includeJavaRuntime when bootclasspath is empty, and 2)
> if they can't or won't change that behavior, could
> they support a custom compilerarg or some other way to
> get around the issue...
For sure, I raised it as Eclipse bug#165976.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by Matt Benson <gu...@yahoo.com>.
--- Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
> > Check the commit log for 'build-java.xml'. That
> snippet looks
> > familiar; I'd swear it was like that at one point
> and then removed
> > because incremental compilation was failing.
>
> Yea, we don't want to use the old version of the
> files we are compiling.
> Ideally we want the bootclasspath to be empty --
> but as Matt discovered
> the compiler adapter takes empty bootclasspath to be
> default value (i.e.
> the JRE JARs).
>
> For now I've set it to an arbitrary JAR that we
> compile against. Please
> check that it fixes the incremental build problem,
> then I'll try and
> figure out a more meaningful value to set.
>
Or talk to the jdt/ecj team: 1) why they set
includeJavaRuntime when bootclasspath is empty, and 2)
if they can't or won't change that behavior, could
they support a custom compilerarg or some other way to
get around the issue...
-Matt
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Check the commit log for 'build-java.xml'. That snippet looks
> familiar; I'd swear it was like that at one point and then removed
> because incremental compilation was failing.
Yea, we don't want to use the old version of the files we are compiling.
Ideally we want the bootclasspath to be empty -- but as Matt discovered
the compiler adapter takes empty bootclasspath to be default value (i.e.
the JRE JARs).
For now I've set it to an arbitrary JAR that we compile against. Please
check that it fixes the incremental build problem, then I'll try and
figure out a more meaningful value to set.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by Nathan Beyer <nb...@gmail.com>.
Check the commit log for 'build-java.xml'. That snippet looks
familiar; I'd swear it was like that at one point and then removed
because incremental compilation was failing.
-Nathan
On 11/26/06, Alexei Zakharov <al...@gmail.com> wrote:
> I've performed several experiments with the command line version of
> ecj (org.eclipse.jdt.internal.compiler.batch.Main) and I found that it
> takes system libs form somewhere even if such libs wasn't specified
> with -cp / -classpath. I was surprised because AFAIK it shouldn't. But
> nevertheless. If -bootclasspath is used instead of -classpath then
> everything works good. So I can suggest the following fix:
>
> in build-java.xml:
> ---
> <target name="-compile" depends="-prepare-depends">
> ...
> <javac .....>
> ...
> +
> + <bootclasspath path="${build.output}"/>
> </javac>
>
> <call-modules target="build" />
> </target>
> ---
>
> It works ok for incremental build as well as for full rebuild. Please
> note that this doesn't mean that we are going to run ecj on top of
> Harmony class libraries. I.e.
>
> java -classpath .\depends\jars\ecj_3.2\ecj_3.2.jar
> org.eclipse.jdt.internal.compiler.batch.Main -bootclasspath
> .\build\classes
> <blah> <blah>
>
> differs from
>
> javac -Xbootclasspath:.\build\classes -classpath
> .\depends\jars\ecj_3.2\ecj_3.2.jar
> org.eclipse.jdt.internal.compiler.batch.Main <blah> <blah>
>
> RI goes mad in the last case.
>
> Thanks,
>
> 2006/11/24, Tim Ellison <t....@gmail.com>:
> > Alexey Varlamov wrote:
> > > I can't recall how many days I have to do full rebuild after updating
> > > workspace in the morning, because just "ant" complained about java
> > > compilation errors...
> > > I did not give that much consideration until today, when trivial local
> > > modification in luni class did not compile again. Could someone adept
> > > in classlib build look into this, please?
> >
> > Well I can see the problem...
> >
> > Running with ant -v shows the javac command is being passed a classpath
> > with the JARs of the running JRE too and they are ahead of the Harmony
> > JARs. So we are compiling against the code running Ant, and if that is
> > not Harmony you are trying to compile against Sun/BEA/whatever.
> >
> > Just have to figure out why Ant is adding extra stuff to the classpath
> > when we have explicitly defined it?
> >
> > Regards,
> > Tim
>
>
> --
> Alexei Zakharov,
> Intel Enterprise Solutions Software Division
>
Re: [classlib] incremental build is no more?
Posted by Alexei Zakharov <al...@gmail.com>.
I've performed several experiments with the command line version of
ecj (org.eclipse.jdt.internal.compiler.batch.Main) and I found that it
takes system libs form somewhere even if such libs wasn't specified
with -cp / -classpath. I was surprised because AFAIK it shouldn't. But
nevertheless. If -bootclasspath is used instead of -classpath then
everything works good. So I can suggest the following fix:
in build-java.xml:
---
<target name="-compile" depends="-prepare-depends">
...
<javac .....>
...
+
+ <bootclasspath path="${build.output}"/>
</javac>
<call-modules target="build" />
</target>
---
It works ok for incremental build as well as for full rebuild. Please
note that this doesn't mean that we are going to run ecj on top of
Harmony class libraries. I.e.
java -classpath .\depends\jars\ecj_3.2\ecj_3.2.jar
org.eclipse.jdt.internal.compiler.batch.Main -bootclasspath
.\build\classes
<blah> <blah>
differs from
javac -Xbootclasspath:.\build\classes -classpath
.\depends\jars\ecj_3.2\ecj_3.2.jar
org.eclipse.jdt.internal.compiler.batch.Main <blah> <blah>
RI goes mad in the last case.
Thanks,
2006/11/24, Tim Ellison <t....@gmail.com>:
> Alexey Varlamov wrote:
> > I can't recall how many days I have to do full rebuild after updating
> > workspace in the morning, because just "ant" complained about java
> > compilation errors...
> > I did not give that much consideration until today, when trivial local
> > modification in luni class did not compile again. Could someone adept
> > in classlib build look into this, please?
>
> Well I can see the problem...
>
> Running with ant -v shows the javac command is being passed a classpath
> with the JARs of the running JRE too and they are ahead of the Harmony
> JARs. So we are compiling against the code running Ant, and if that is
> not Harmony you are trying to compile against Sun/BEA/whatever.
>
> Just have to figure out why Ant is adding extra stuff to the classpath
> when we have explicitly defined it?
>
> Regards,
> Tim
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> I can't recall how many days I have to do full rebuild after updating
> workspace in the morning, because just "ant" complained about java
> compilation errors...
> I did not give that much consideration until today, when trivial local
> modification in luni class did not compile again. Could someone adept
> in classlib build look into this, please?
Well I can see the problem...
Running with ant -v shows the javac command is being passed a classpath
with the JARs of the running JRE too and they are ahead of the Harmony
JARs. So we are compiling against the code running Ant, and if that is
not Harmony you are trying to compile against Sun/BEA/whatever.
Just have to figure out why Ant is adding extra stuff to the classpath
when we have explicitly defined it?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by Oliver Deakin <ol...@googlemail.com>.
Yup, Ive seen this too - the Java incremental build stage fails
intermittently, but a full rebuild works fine.
fyi the native incremental build works fine for me, so if you're only
making native changes you can
still just use "ant build-native" without need to clean.
Geir Magnusson Jr. wrote:
>
>
> Tim Ellison wrote:
>> Elena Semukhina wrote:
>>> On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>>> I'm doing fulll rebuild for about two weeks (at least)
>>>
>>> Me too for about a week...
>>
>> Huh? What happens if you just type 'ant' at the top level then?
>
> I have this problem too, but never had time to look. It's common that
> when I do a svn update, the build will then fail w/o a clean....
>
> geir
>
>
>>
>> Regards,
>> Tim
>>
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Evgueni Brevnov wrote:
> It fails with compiler errors. Alexey provided typical output in the
> first message.
D'oh - thanks, looking...
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by Evgueni Brevnov <ev...@gmail.com>.
It fails with compiler errors. Alexey provided typical output in the
first message.
Thnaks
Evgueni
On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr. wrote:
> > Tim Ellison wrote:
> >> Elena Semukhina wrote:
> >>> On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>>> I'm doing fulll rebuild for about two weeks (at least)
> >>>
> >>> Me too for about a week...
> >>
> >> Huh? What happens if you just type 'ant' at the top level then?
> >
> > I have this problem too, but never had time to look. It's common that
> > when I do a svn update, the build will then fail w/o a clean....
>
> How does it 'fail'? (missing files, compile error, bogus results, ??)
> can you provide more info.
>
> Regards
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Elena Semukhina wrote:
>>> On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>>> I'm doing fulll rebuild for about two weeks (at least)
>>>
>>> Me too for about a week...
>>
>> Huh? What happens if you just type 'ant' at the top level then?
>
> I have this problem too, but never had time to look. It's common that
> when I do a svn update, the build will then fail w/o a clean....
How does it 'fail'? (missing files, compile error, bogus results, ??)
can you provide more info.
Regards
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Elena Semukhina wrote:
>> On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> I'm doing fulll rebuild for about two weeks (at least)
>>
>> Me too for about a week...
>
> Huh? What happens if you just type 'ant' at the top level then?
I have this problem too, but never had time to look. It's common that
when I do a svn update, the build will then fail w/o a clean....
geir
>
> Regards,
> Tim
>
Re: [classlib] incremental build is no more?
Posted by Tim Ellison <t....@gmail.com>.
Elena Semukhina wrote:
> On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>
>> I'm doing fulll rebuild for about two weeks (at least)
>
>
> Me too for about a week...
Huh? What happens if you just type 'ant' at the top level then?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] incremental build is no more?
Posted by Elena Semukhina <el...@gmail.com>.
On 11/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>
> I'm doing fulll rebuild for about two weeks (at least)
Me too for about a week...
Evgueni
>
> On 11/24/06, Alexey Varlamov <al...@gmail.com> wrote:
> > Good news is that
> > ant -f modules\luni\build.xml
> > works fine for the same sutiation.
> >
> > 2006/11/24, Alexey Varlamov <al...@gmail.com>:
> > > I can't recall how many days I have to do full rebuild after updating
> > > workspace in the morning, because just "ant" complained about java
> > > compilation errors...
> > > I did not give that much consideration until today, when trivial local
> > > modification in luni class did not compile again. Could someone adept
> > > in classlib build look into this, please?
> > >
> > > Just added empty line in SecurityManager.java:
> > > >ant build-java -Dbuild.module=luni
> > > ...
> > > -compile:
> > > [javac] Since compiler setting isn't classic or modern,ignoring
> fork setting
> > > .
> > > [javac] Compiling 1 source file to
> C:\apache-dev\Harmony\trunk\working_class
> > > lib\build\classes
> > > [javac] Since compiler setting isn't classic or modern,ignoring
> fork setting
> > > .
> > > [javac] ----------
> > > [javac] 1. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 66)
> > > [javac] security.checkPermission(
> RuntimePermission.permissionToCreateSec
> > > urityManager);
> >
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > ^^^^^^^^^^^^
> > > [javac] RuntimePermission.permissionToCreateSecurityManager cannot
> be resolv
> > > ed
> > > [javac] ----------
> > > [javac] 2. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 107)
> > > [javac] checkPermission(
> RuntimePermission.permissionToModifyThread);
> > > [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [javac] RuntimePermission.permissionToModifyThread cannot be
> resolved
> > > [javac] ----------
> > > [javac] 3. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 124)
> > > [javac] checkPermission(
> RuntimePermission.permissionToModifyThreadGroup)
> > > ;
> > > [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [javac] RuntimePermission.permissionToModifyThreadGroup cannot be
> resolved
> > > [javac] ----------
> > > [javac] 4. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 174)
> > > [javac] checkPermission(
> RuntimePermission.permissionToCreateClassLoader)
> > > ;
> > > [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [javac] RuntimePermission.permissionToCreateClassLoader cannot be
> resolved
> > > [javac] ----------
> > > [javac] 5. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 207)
> > > [javac] checkPermission(RuntimePermission.permissionToExitVM);
> > > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [javac] RuntimePermission.permissionToExitVM cannot be resolved
> > > [javac] ----------
> > > [javac] 6. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 272)
> > > [javac] if (ClassLoader.getStackClassLoader(3) ==
> cls.getClassLoaderImpl
> > > ()) {
> > > [javac] ^^^^^^^^^^^^^^^^^^^
> > > [javac] The method getStackClassLoader(int) is undefined for the
> type ClassL
> > > oader
> > > [javac] ----------
> > > [javac] 7. ERROR in
> C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > > i\src\main\java\java\lang\SecurityManager.java
> > > [javac] (at line 272)
> > > [javac] if (ClassLoader.getStackClassLoader(3) ==
> cls.getClassLoaderImpl
> > > ()) {
> > > [javac]
> ^^^^^^^^^^^^^^^^^^
> > >
> > > [javac] The method getClassLoaderImpl() is undefined for the type
> Class<capt
> > > ure-of ?>
> > > [javac] ----------
> > > <snip>
> > >
> > > --
> > > Alexey
> > >
> >
>
--
Thanks,
Elena
Re: [classlib] incremental build is no more?
Posted by Evgueni Brevnov <ev...@gmail.com>.
I'm doing fulll rebuild for about two weeks (at least)
Evgueni
On 11/24/06, Alexey Varlamov <al...@gmail.com> wrote:
> Good news is that
> ant -f modules\luni\build.xml
> works fine for the same sutiation.
>
> 2006/11/24, Alexey Varlamov <al...@gmail.com>:
> > I can't recall how many days I have to do full rebuild after updating
> > workspace in the morning, because just "ant" complained about java
> > compilation errors...
> > I did not give that much consideration until today, when trivial local
> > modification in luni class did not compile again. Could someone adept
> > in classlib build look into this, please?
> >
> > Just added empty line in SecurityManager.java:
> > >ant build-java -Dbuild.module=luni
> > ...
> > -compile:
> > [javac] Since compiler setting isn't classic or modern,ignoring fork setting
> > .
> > [javac] Compiling 1 source file to C:\apache-dev\Harmony\trunk\working_class
> > lib\build\classes
> > [javac] Since compiler setting isn't classic or modern,ignoring fork setting
> > .
> > [javac] ----------
> > [javac] 1. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 66)
> > [javac] security.checkPermission(RuntimePermission.permissionToCreateSec
> > urityManager);
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > ^^^^^^^^^^^^
> > [javac] RuntimePermission.permissionToCreateSecurityManager cannot be resolv
> > ed
> > [javac] ----------
> > [javac] 2. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 107)
> > [javac] checkPermission(RuntimePermission.permissionToModifyThread);
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [javac] RuntimePermission.permissionToModifyThread cannot be resolved
> > [javac] ----------
> > [javac] 3. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 124)
> > [javac] checkPermission(RuntimePermission.permissionToModifyThreadGroup)
> > ;
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [javac] RuntimePermission.permissionToModifyThreadGroup cannot be resolved
> > [javac] ----------
> > [javac] 4. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 174)
> > [javac] checkPermission(RuntimePermission.permissionToCreateClassLoader)
> > ;
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [javac] RuntimePermission.permissionToCreateClassLoader cannot be resolved
> > [javac] ----------
> > [javac] 5. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 207)
> > [javac] checkPermission(RuntimePermission.permissionToExitVM);
> > [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [javac] RuntimePermission.permissionToExitVM cannot be resolved
> > [javac] ----------
> > [javac] 6. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 272)
> > [javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
> > ()) {
> > [javac] ^^^^^^^^^^^^^^^^^^^
> > [javac] The method getStackClassLoader(int) is undefined for the type ClassL
> > oader
> > [javac] ----------
> > [javac] 7. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> > i\src\main\java\java\lang\SecurityManager.java
> > [javac] (at line 272)
> > [javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
> > ()) {
> > [javac] ^^^^^^^^^^^^^^^^^^
> >
> > [javac] The method getClassLoaderImpl() is undefined for the type Class<capt
> > ure-of ?>
> > [javac] ----------
> > <snip>
> >
> > --
> > Alexey
> >
>
Re: [classlib] incremental build is no more?
Posted by Alexey Varlamov <al...@gmail.com>.
Good news is that
ant -f modules\luni\build.xml
works fine for the same sutiation.
2006/11/24, Alexey Varlamov <al...@gmail.com>:
> I can't recall how many days I have to do full rebuild after updating
> workspace in the morning, because just "ant" complained about java
> compilation errors...
> I did not give that much consideration until today, when trivial local
> modification in luni class did not compile again. Could someone adept
> in classlib build look into this, please?
>
> Just added empty line in SecurityManager.java:
> >ant build-java -Dbuild.module=luni
> ...
> -compile:
> [javac] Since compiler setting isn't classic or modern,ignoring fork setting
> .
> [javac] Compiling 1 source file to C:\apache-dev\Harmony\trunk\working_class
> lib\build\classes
> [javac] Since compiler setting isn't classic or modern,ignoring fork setting
> .
> [javac] ----------
> [javac] 1. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 66)
> [javac] security.checkPermission(RuntimePermission.permissionToCreateSec
> urityManager);
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^
> [javac] RuntimePermission.permissionToCreateSecurityManager cannot be resolv
> ed
> [javac] ----------
> [javac] 2. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 107)
> [javac] checkPermission(RuntimePermission.permissionToModifyThread);
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [javac] RuntimePermission.permissionToModifyThread cannot be resolved
> [javac] ----------
> [javac] 3. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 124)
> [javac] checkPermission(RuntimePermission.permissionToModifyThreadGroup)
> ;
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [javac] RuntimePermission.permissionToModifyThreadGroup cannot be resolved
> [javac] ----------
> [javac] 4. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 174)
> [javac] checkPermission(RuntimePermission.permissionToCreateClassLoader)
> ;
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [javac] RuntimePermission.permissionToCreateClassLoader cannot be resolved
> [javac] ----------
> [javac] 5. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 207)
> [javac] checkPermission(RuntimePermission.permissionToExitVM);
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [javac] RuntimePermission.permissionToExitVM cannot be resolved
> [javac] ----------
> [javac] 6. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 272)
> [javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
> ()) {
> [javac] ^^^^^^^^^^^^^^^^^^^
> [javac] The method getStackClassLoader(int) is undefined for the type ClassL
> oader
> [javac] ----------
> [javac] 7. ERROR in C:\apache-dev\Harmony\trunk\working_classlib\modules\lun
> i\src\main\java\java\lang\SecurityManager.java
> [javac] (at line 272)
> [javac] if (ClassLoader.getStackClassLoader(3) == cls.getClassLoaderImpl
> ()) {
> [javac] ^^^^^^^^^^^^^^^^^^
>
> [javac] The method getClassLoaderImpl() is undefined for the type Class<capt
> ure-of ?>
> [javac] ----------
> <snip>
>
> --
> Alexey
>