Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.21.MISMATCH!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Compile Problem involving Dependencies Date: Sat, 29 Oct 2011 17:06:43 -0700 (PDT) Organization: http://groups.google.com Lines: 34 Message-ID: <31537605.902.1319933203136.JavaMail.geo-discussion-forums@prmv24> References: Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 216.239.45.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1319933577 389 127.0.0.1 (30 Oct 2011 00:12:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 30 Oct 2011 00:12:57 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9307 markspace wrote: > Novice wrote: >> The fresh build did the trick; all the compiler >> errors went away and I was able to run the applet successfully. I like >> Eclipse but it does seem to get confused sometimes; > >=20 > You're welcome. NetBeans seems to have the same problem. Periodically= =20 Pretty much *all* build systems have this problem. > weird errors show up and I have to do the "clean and rebuild full=20 > project." I guess it might be common behavior related to some compiler= =20 > API they both use, since Java has made one available for programmers a=20 > while back. >=20 > *shrug* At least you didn't have to reach for the "big red switch." It's common behavior to all build systems, particularly Java-esque ones tha= t track dependencies through the .class files in the "-d" target directory = of javac. In the face of refactoring and certain strange scenarios, .class files rema= in in the target directory for which either the source files have a changed= transitive dependency or the source no longer exists or a constant is not = deemed worthy of a recompile or what-all. Later another class sees something in the now-no-longer-valid .class file a= nd weirdness ensues. Finally the hapless programmer does a full "clean", a= nd voil=E0! Problem solved. --=20 Lew