|
|
|
Re: Not Using the Internal Compiler [message #901563 is a reply to message #901280] |
Mon, 13 August 2012 12:18 |
Dani Megert Messages: 3802 Registered: July 2009 |
Senior Member |
|
|
On 10.08.2012 17:31, Peter Wilhelm Gstettner wrote:
> First, I do not know, if this is the right place for this, but google
> brought me here, so I might as well give it a try ;)
>
> In fact, using it's own compiler causes some trouble in the real
> world. This is because the compiler that comes with eclipse seems to
> be a lot more capable than the one shipped with your (or my) JDK.
>
> Especially when generics are used, there seem to be some major
> shortcomings in current javac implementations (at least for jdk 1.6_x).
> So someone can write some amount of code until he or she recognizes
> that something will not work/compile in the to be shipped product
> (because ant/maven/gradle will fail to build it using javac).
The same is true if you just stay with javac only: newer versions have
this bug fixed (even if you set the source and target to 1.6) and if you
then switch to another/older version, it won't compile.
Dani
>
> e.g I got something like the following, which compiles fine in eclipse
> but fails to compile with javac:
>
>
> package weird;
>
> public class DoesNotCompile {
>
> class A<X extends A<X>> {
> class B<Y extends A<X>> {
> }
> }
>
> class C extends A<C> {
> public C() {
> B<C> b = new B<C>();
> System.out.println("b: " + b.toString());
> }
> }
> }
>
>
>
> vs. javac:
>
>
> formerly-black-sheep:src peter$ javac weird/DoesNotCompile.java
> weird/DoesNotCompile.java:12: type parameter weird.DoesNotCompile.C is
> not within its bound
> B<C> b = new B<C>();
> ^
>
>
>
> NOTE: it will not make any difference if the outer class
> (DoesNotCompile) is left and the classes A and C are put in separate
> files. Just put them in one file for convenience...
|
|
|
|
Powered by
FUDForum. Page generated in 0.05040 seconds