> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Brian Jones
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Doesn't compile? Hmm, I'll check after church tomorrow. I
> don't think it's
> > different. What is in your classpath when compiling, and in what order?
> > vm/reference is it for now.
> > --John Keiser
>
> Try the build process and look at the errors it is spitting out
> regarding vm/reference. I think a lot of the errors I saw were
> methods without bodies. There are also problems with not setting the
> value of final variables in an initializer or every constructor, at
> least according to Sun's JDK.
>
OK, first off, CVS is absolutely 100% equal to what I have at home now. The
changes don't appear to cause the behavior you talk about, though.
Methods without bodies shouldn't have happened at all. The stuff in CVS
from before does compile. I've been using guavac. javac cannot, I repeat,
*cannot* compile the core classes here. Rather, it can compile them, but it
will not spit out an output file.
final variables, eh? Odd. I wonder if that's just something guavac didn't
find ... I'll check later.
Can you send an error file, pretty please? :) If you don't, I'll still do
it myself, but I'd really appreciate it since you apparently have everything
ready to try and do the compile. I may be able to tell you what's going on
without going to the trouble of setting up the build process just yet.
One thing: you must have java/lang/ThreadGroup.class *from Classpath* in
your path, because Thread uses some package-private methods in it. That is
the only dependency I know of between vm/reference and the main tree.
Note that if you have java/lang/ThreadGroup.class in your classpath, javac
is not going to be too happy with you. I hope Kiev can handle it better.
*crosses fingers*
--John Keiser
