Community
Participate
Working Groups
Build 20011211 From a conversation on Eclipse Corner: Your argument for compiling with another IDE is well-taken, and our behavior probably indicates that in case we meet some unresolved types inside binaries, we should be better fault-tolerant (you still need an error, but could only be a warning if it affects a member). Will log a PR to remember to revisit this (likely after 2.0). "Jakob Braeuchi" <jbraeuchi@hotmail.com> wrote in message news:9vg833$931 $1@rogue.oti.com... > hi philippe, > > > The difference is that if the error occurs inside sources, then it is > likely > > you mistyped something, and we should proceed. > > When it occurs inside binaries, there is nothing you can do to solve this > > other than fix up your classpath (it isn't a typo). > > this sounds reasonable to me. > i'm now also the proud owner of those ... antlr.debug classes and everything > runs fine in eclipse ! > > but i think if the project compiles fine (and runs fine, too) in other ides > it also should do it in eclipse. > we had such problems with compatibility before in vaj and they should not be > repeated in eclipse. > > i would like to have a feature for 'brute force' compilation. > > thanks for your patience > jakob > > > "Philippe Mulet" <philippe_mulet@oti.com> schrieb im Newsbeitrag > news:9vcll1$9i4$1@rogue.oti.com... > > The difference is that if the error occurs inside sources, then it is > likely > > you mistyped something, and we should proceed. > > When it occurs inside binaries, there is nothing you can do to solve this > > other than fix up your classpath (it isn't a typo). > > > > "Jakob Braeuchi" <jbraeuchi@hotmail.com> wrote in message > > news:9vca37$5gc$1@rogue.oti.com... > > > what's the difference between let's say a mistyped class and a class not > > > found in the class path ? > > > > > > - in case i misspell a class the compiler still tries to compile all > > classes > > > in the project. > > > - in case of a class not found in the classpath the compiler comes to a > > > complete stop ??? > > > > > > "Kent Johnson" <kent_johnson@oti.com> schrieb im Newsbeitrag > > > news:9vasrs$p33$1@rogue.oti.com... > > > > Jakob Braeuchi wrote: > > > > > > > > > but why does the compiler completely stop ? > > > > > > > > When your classpath is incorrect, you can end up with hundreds of > > compiler > > > > problems which do not help you at all... so we stop once it is clear > > that > > > > you need to fix your classpath. > > > > > > > > > > > > > > > >
How much would it cost to discard unresolved signatures alltogether (like we do in sources) ? Competitors seem to recover better than us.
javac behaves the same as we do... 1. Compile B.java using javac after creating the following 3 types in their own source files: public class A { MissingType t; } public class MissingType {} public class B extends A { public static void main(String[] args) { System.out.println(new A()); } } 2. Now delete MissingType.java & MissingType.class 3. Change B.java to be: public class B extends A { public static void main(String[] args) { System.out.println(new A().t); } } then compile it again & javac complains with: B.java:6: cannot access bogus.MissingType file bogus\MissingType.class not found System.out.println(new A().t);
Does javac reject the code if no source code is accessing the bogus field 't' ? Currently, BinaryTypeBinding.fields() and methods() are not usable in case hitting an inconsistent binary type (burning code assist).
Both javac & our compiler will successfully compile B as long as it does not reference the field t. Only when the fields/methods of the binary type A are requested is the missing class detected.
Ok, we will keep it the same as it is. The difference could be due to some different checks performed by our compiler (for instance, we do diagnose extra warnings in case a package default method is attempted to be overriden, etc... these could cause more binary types to be accessed.
