This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If I have @Entity public class EntityBean implements Serializable, TextInterface{ Then annotation hints on the line with @Entity offers to "Implement methods from TextInterface", while hints on the class definition line says "Create EJB Persistence Unit"
Could you please elaborate on what is actually wrong? I am sorry for my ignorance, but I don't know much about @Entity and entity beans. Thanks.
Sure, np. Simply put, the hints are switched. The hint on line with "public class SomeClass implements SomeInterface" should offer to implement abstract methods (as is the case in NB551). Not the line with "@Entity" Put aside @Entity, while coding I saw that in standard JSE classes/annotations too. It seems like the hint for implementing abstract classes is somehow glued to previous annotation instead of offending line. Is this better? If I see that again with JSE, I will try to post example, screenshot. Dale
a) I have renamed the issue as it is generic, not bound to @Entity annotation only but any Java @Annotation. b) see attached screenshots I made with @Deprecated annotation. HTH, dale
Created attachment 46919 [details] wrong hint line
Created attachment 46920 [details] wrong hint line
Thanks Dale for an excellent report. I'm passing it on to the hints guys for closer look.
Well, the "non-abstract" error is simply placed at the first line of the class header - which in the given case contains only "@Deprecated" annotation.
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
I'd like to NetFIX [1] this bug. Is it possible? [1] http://wiki.netbeans.org/NetFIX
I am willing to review (and apply) the patch in java.hints, so you patch(es) is(are) welcome (unless Max, the current owner of java.hints, disagrees). I would recommend to first define the scope - what kind of errors do you want to move to a more appropriate place (and what are the more appropriate places). The actual implementation of this should not be that difficult - see ErrorHintsProvider.getLine in java.hints module. Creating a few tests would also be good, see ErrorHintsProviderTest in java.hints. Note that there is a debugging panel "Errors" in the navigator that shows the error as returned by the parser (javac): the start, end and preferred positions, error kind, etc. This panel is enabled only if assertions are enabled in the IDE. For the @Entity annotation, you would need to look at a different module (probably j2ee.jpa.verification or j2ee.ejbverification).
Created attachment 80251 [details] Patch for java.hints
To start, I have changed the way lines are highlighted for all class should be abstract errors (as listed in ImplementAllAbstractMethods). Now it highlights the class name instead of the annotation. I also intend to change the EJB hint in order to highlight the annotation. I find it hard to propose changes for the several other possible errors, so I think we should address just the cases that have been reported in this issue. Other cases will result in new issues that could be addressed on their own. Still haven't had the time to look at the tests, sorry.
j2ee.jpa.verification implements the Persistence Unit fix. However, given its common infrastructure for problem detection and highlighting, a clean fix to this module would require analyzing all warnings it can generate and decide which ones belong to the @Entity annotation, to the class and to other annotations it can handle. Therefore, I suggest the current patch is applied to java.hints and another issue is filed against j2ee.jpa.verification.
The patch seems fine to me, except that "compiler.err.abstract.cant.be.instantiated" is listed twice. (Also, it might be reasonable to replace the cascade if with a switch here, but that is nitpick). Would be good to have some tests, however. If you could provide test cases (small Java classes on which the fixed version provides better results, similar to: http://hg.netbeans.org/jet-main/file/tip/java.hints/test/unit/data/javahints/TestShortErrors1.java ), I can create the automated test cases from them myself. Thanks.
> The patch seems fine to me, except that "compiler.err.abstract.cant.be.instantiated" is listed twice. That's because ImplementAllAbstractMethods also contains the error twice in getCodes() and I used it to generate the strings. I will submit a new patch without the duplicated line. > (Also, it might be reasonable to replace the cascade if with a switch here, but that is nitpick). Unless it falls through, that would actually change semantics, if I got the code right. For instance, the current code would move the token from dot in: p.new Something(); to Something since it would match dot and new. > Would be good to have some tests, however. If you could provide test cases (small Java classes on which the fixed > version provides better results, similar to: > http://hg.netbeans.org/jetmain/file/tip/java.hints/test/unit/data/javahints/TestShortErrors1.java), I > can create the automated test cases from them myself. I will attach a few examples soon.
Created attachment 82078 [details] Patch for java.hints
Created attachment 82079 [details] Broken sample Java file for better fix
Created attachment 82080 [details] Broken sample Java file for better fix
Honzo, can you review the latest version of the patch? Thanks!
Thanks for the patch, I have integrated it: http://hg.netbeans.org/jet-main/rev/68c1809c4fa4
JPA issue submitted as # 165112. Closing this issue.
Integrated into 'main-golden', will be available in build *200905220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/68c1809c4fa4 User: Jan Lahoda <jlahoda@netbeans.org> Log: #113119: correct placing of error underline for compiler.err.does.not.override.abstract and compiler.err.abstract.cant.be.instantiated errors. Contributed by misterm@netbeans.org.