JDT more correct than Javac

Discussions

News: JDT more correct than Javac

  1. JDT more correct than Javac (18 messages)

    In a strange but true case involving generics, Bruce Eckel, in an Artima discussion thread, explored a test case in which javac would not compile code that appeared to be syntactically correct. The correctness of the code was later confirmed in further testing that used the JDT (Eclipse) compiler. The whole discussion is nicely summarized by R.J. Lorimer at the EclipseZone.

    The code in question is as follows.
    package code;

    interface HasColor {
      java.awt.Color getColor();
    }

    class Dimension {
      int x, y, z;
    }

    class ColoredDimension<T extends Dimension & HasColor> {
      T item;
      ColoredDimension(T item) { this.item = item; }
      T getItem() { return item; }
      java.awt.Color f() { return item.getColor(); }
      int getX() { return item.x; }
    }
    Though the error message states that x is not public in code.Dimension and consequently cannot be accessed from outside the package, it is clear that Dimension.x should be clearly visible from within ColoredDimension. To further confuse matters, Bruce and James Watson both confirm that this code will compile if one removes out all of the artifacts dealing with HasColor.
    package code;

    interface HasColor {
      java.awt.Color getColor();
    }

    class Dimension {
      int x, y, z;
    }

    class ColoredDimension<T extends Dimension > {
      T item;
      ColoredDimension(T item) { this.item = item; }
      T getItem() { return item; }
      //java.awt.Color f() { return item.getColor(); }
      int getX() { return item.x; }
    }
    It somehow seems that javac is confused by the additional interface implementation yet this all works as expected when working in Eclipse. How many here noticed that while everyone was distracted by the generics, Bruce used his right hand to directly access another objects member variable? The question is will the bug manifest itself when one uses a public getter? Since declaring x public in Dimension is also another fix for this problem one can only guess that the answer to that question is use but it maybe doing so for all the wrong reasons. What it does point out is that testing complex features requires complex testing or luck or both.

    Threaded Messages (18)

  2. I believe it was Aristotle who said "One swallow does not make a summer"?

    -krish
  3. I believe it was Aristotle who said "One swallow does not make a summer"?-krish
    +1
  4. Then Javac did what?[ Go to top ]

    Will someone please explain to me when people started confusing "then" and "than"? I mean, its vs it's I can understand. Even their/there/they're are homophones. Then and Than aren't even pronounced the same way.
  5. After spending too much time for Java/C/Basic (IF...THEN) some of people start to write "then" on keyboard automatically, even if "than" should be used.
  6. Then Javac did what?[ Go to top ]

    Will someone please explain to me when people started confusing "then" and "than"? I mean, its vs it's I can understand. Even their/there/they're are homophones. Then and Than aren't even pronounced the same way.

    That depends on what region you hail from. Where I grew up, they are pronounced pretty much exactly the same. I'm not saying it's correct but it's case.
  7. What's the matter, Robert?[ Go to top ]

    For example, I don't complain if you cannot properly write in russian or ukrainian...
    So, as we used to say "Learn Albanian!"..
  8. What's the matter, Robert?[ Go to top ]

    Стопудово, Евген!

    Ф Бабруйск учить Олбанский!!
  9. Better then the Bard of Avon[ Go to top ]

    Will someone please explain to me when people started confusing "then" and "than"?

    It must have been in Elizabethan times, since Shakespeare didn't distinguish between them in spelling. But it bugs the heck out of me when I read it, so I have to agree with you that it's a problem.

    On a related subject, has anyone noticed that when you go to log in to this site it prompts you to "Enter you email"?
  10. English mistakes[ Go to top ]

    For example, I don't complain if you cannot properly write in russian or ukrainian...
    So, as we used to say "Learn Albanian!"..

    On one hand, people for whom English is not the first language (myself included) should try to learn from their mistakes so as not to repeat them.

    On the other hand, if people go through the trouble of pointing out mistakes, they should do so in a polite and constructive manner to encourage others to perceive the correction as a teaching effort rather than as an aggressive, pejorative comment.
  11. Than, then, than, then...[ Go to top ]

    Will someone please explain to me when people started confusing "then" and "than"?
    At least 3/4 of the times I go to type "than", what comes out is "that". Just the way my fingers work. Sometimes the error remains uncorrected. C'est la vie.
  12. JDT more correct then Javac[ Go to top ]

    Absolutely fascinating. Let's create an acronym.
  13. JDT more correct then Javac[ Go to top ]

    Absolutely fascinating. Let's create an acronym.

    AJAB? A JAvac Bug? It would be appropriate, because the acronym would describe something that has long existed.

    Disclaimer: I am not associated with Adaptive Path :)
  14. Even tried disassembling[ Go to top ]

    And things look normal. Check it out at my post.
  15. Even tried disassembling[ Go to top ]

    And things look normal. Check it out at my post.

    You removed all references that would require a cast to Dimension. That's why it erases to HasColor. If you do either of the following you will get a much different result:

    int getX() { return ((Dimension)item).x; }

    class Dimension {
      protected int x, y, z;
    }

    Both of these cause item to erase to Dimension.
  16. Re :Even tried disassembling[ Go to top ]

    And things look normal. Check it out at my post.
    You removed all references that would require a cast to Dimension. That's why it erases to HasColor. If you do either of the following you will get a much different result:int getX() { return ((Dimension)item).x; }class Dimension {&nbsp;&nbsp;protected int x, y, z;}Both of these cause item to erase to Dimension.

    Indeed. My point was however that the compiler didn't confuse in the erasure process, which makes it even weirder - It could've been "easier" to understand if the erasure had gone wrong too..
  17. JDT more correct then Javac[ Go to top ]

    There are many examples. For example, two test cases I found last year:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=113218
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=113236

    Both of them reported to Sun in 2004 (!) year.
  18. JDT more correct than Javac[ Go to top ]

    I helped document another case where javac malfunctions and JDT don't. The JLS and JDT agree that the declaration of a foreach cursor can be annotated. Javac wrongly rejects it.

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=111076
  19. itsabug[ Go to top ]

    Heres a possible reason,

    Specifier Class Package Subclass World
    private Y N N N
    no specifier Y Y N N
    protected Y Y Y N
    public Y Y Y Y

    The javac security check fails when the & keyword is used and package level accesses are attempted.

    You can reproduce the same problem ( with a different error ) by just adding a package level getter on Dimension called getX() and then calling it in the template. javac wont even see the method. This may be because package level stuff is not allowed to be accessed by subclasses. (unless they are in the same package which they are!?)

    The security check overthinks and assumes that the parameter class could be from another package when in fact that is validated when parsing the type declaration of the class in the <T extends something I should be able to extend> clause. The interface being involved just goes down a different code path for the access check nothing mysterious.

    I suspect that the interface being involved bug goes something like this...All interfaces are public so use the standard access check ignoring package level access.

    When in fact we can have package level interfaces. Although its wierd to do that.

    your welcome SUN fix it.