> Another live example is self hosting scenario. When we build classlib,
> all harmony JAR files are passed in -classpath argument to ECJ. When we
> build working_jdktools, -classpath doesn't contain boot harmony classes,
> and so compiler cannot find j.l.Object and fails to compile
> working_jdktools.
FYI I've fixed JPDA build at r541625. Now jdktools can be built with
pure HDK using even the old versions of ECJ. Another problem I've
found is that our javac tool from HDK rejects to compile even simple
HelloWorld.java. I don't know if I am the first person who reports
about this and how such situation could happen at all. But the fact
is: HDK I've built today contains broken javac. AFAIU this is the same
issue you have talked about - javac tries to construct a classpath for
ECJ using only "org.apache.harmony.boot.class.path" property that does
not contain kernel classes. I've fixed it in r541654 by adding values
specified in "sun.boot.class.path" too as it was suggested in this
thread. It will be removed after fixing
"org.apache.harmony.boot.class.path".
As for "java -jar ecj.jar ..." - looks like it can be fixed only by
downloading new version of ecj.jar that includes Oliver's patch.
Thanks,
2007/5/23, Gregory Shimansky :
> Alexey Petrenko wrote:
> > And the most of the application would call compiler as javac I think.
> >
> > Gregory, is "/jre/bin/java -jar ecj.jar > file>" a live example?
>
> This is how stand alone eclipse compiler available from [1] is supposed
> to be launched.
>
> Another live example is self hosting scenario. When we build classlib,
> all harmony JAR files are passed in -classpath argument to ECJ. When we
> build working_jdktools, -classpath doesn't contain boot harmony classes,
> and so compiler cannot find j.l.Object and fails to compile
> working_jdktools.
>
> [1]
> http://download.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/download.php?dropFile=ecj.jar
>
> > 2007/5/23, Nathan Beyer :
> >> Couldn't we just always pass a bootclasspath argument to the ECJ
> >> class? The code would need to do some manipulation on any explicit
> >> values passed, but that shouldn't be too difficult.
> >>
> >> -Nathan
> >>
> >> On 5/22/07, Gregory Shimansky wrote:
> >> > Hello
> >> >
> >> > While investigating the bug described in HARMONY-3565 I found out that
> >> > ECJ (eclipse compiler that we use for java compilation) doesn't work
> >> > quite correctly with Harmony. It tries to guess boot classes looking
> >> for
> >> > files for ${java.home}/lib/*.jar files.
> >> >
> >> > This works for Sun, but doesn't work for Harmony because we have our
> >> > boot classes in ${java.home/bin/default/*.jar,
> >> > ${java.home/lib/boot/*.jar and ${java.home}/lib/boot/*/*.jar files. ECJ
> >> > doesn't find them and so running ECJ from the command line as
> >> >
> >> > /jre/bin/java -jar ecj.jar
> >> >
> >> > produces and error that j.l.Object and other core classes cannot be
> >> > resolved. The bug is reproducible both on DRLVM and IBM VME. When
> >> > passing -bootclasspath or -classpath switches to ECJ explicitly, it
> >> > finds boot classes just fine (this is how it is done in our javac
> >> > launcher, it passes -classpath switch with value of
> >> > org.apache.harmony.boot.class.path property to
> >> > org.eclipse.jdt.internal.compiler.batch.Main class).
> >> >
> >> > I don't have a quick solution on how to fix the bug. Tuning ECJ to make
> >> > it understand Harmony's JAR files layout doesn't seem to be a good idea
> >> > because the actual JAR files are specified in
> >> lib/bootclasspath.properties.
> >> >
> >> > We could also ask Eclipse developers to make ECJ understand
> >> > org.apache.harmony.boot.class.path property, what do you think?
> >> >
> >> > --
> >> > Gregory
--
Alexei Zakharov,
Intel ESSD