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.

Bug 222072 - Groovy syntax checking has problems with generics
Summary: Groovy syntax checking has problems with generics
Status: RESOLVED FIXED
Alias: None
Product: groovy
Classification: Unclassified
Component: Code (show other bugs)
Version: 7.3
Hardware: PC Windows Vista
: P3 normal with 1 vote (vote)
Assignee: Martin Janicek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-13 21:23 UTC by mclaassen
Modified: 2014-07-16 12:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Netbeans project showing the error (16.95 KB, application/x-zip-compressed)
2012-11-13 21:23 UTC, mclaassen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mclaassen 2012-11-13 21:23:35 UTC
Created attachment 127740 [details]
Netbeans project showing the error

Using the recent dailies (or 7.3beta2) I have noticed that the syntax checker is highlighting errors in my groovy scripts that are not errors.

We have some files that use generics in, I think, a pretty unique way.  For instance, we have a class similar in structure to this:

public class Base<T extends Base<T>> implements Comparable<T> {
	@Override
	public int compareTo(T other) {
		return 0;
	}
}

Doing this trick with the generics, allows for the Base class to implement an interface in an extensible way.  Now, whether or not this is a good idea or not, the groovy script syntax checker cannot handle imports of classes specified in this manner.

This is a new-ish bug, however I don't do groovy stuff that often, so I don't know how new.  Checking now, I see that in 7.2, the imports are highlighted as errors in the editor, but the file is not badged with the error badge.
Comment 1 Martin Janicek 2012-11-19 12:10:25 UTC
Hi, thanks for the report. The error-badges in groovy files is a new feature (in NetBeans 7.2 there were no badge even if the file was uncompilable).

I'm trying to reproduce your problem, but I can see quite a different results than you. I created new Java project with groovy script and paste your code snipped inside. The result file has following content:

package javaapplication19

def name='martin'

println "Hello $name!"

public class Base<T extends Base<T>> implements Comparable<T> {
    @Override
    public int compareTo(T other) {
        return 0;
    }
}

..I can see no error inside that file. Could you please confirm this behavior or tell me what should I change to see the same problem as you?

Anyway, I see some highlighting issues related to generics in this file.
1] With the caret location on Base name, there is no highlight for the usage located in the generic param
2] There is no highlighting for T parameter
3] If the caret location is on Comparable there is no highlighting at all

Those are different issues that the original one, so I'll create a separate tickets for them.
Comment 2 Martin Janicek 2012-11-19 12:25:46 UTC
Ah sorry, I didn't notice the attached project. I can see the problem now, it's a valid issue, so setting TM = 7.3. Thanks!
Comment 3 mclaassen 2013-01-17 21:08:05 UTC
Is this going to be addressed in 7.3?  I see on the Wiki that the code freeze date was planned to be January 9.  Not exactly sure what this means, but I was still hoping this would be fixed.  I love the badges when they work.  However, this false positive error badge is pretty distracting and I don't notice legitimate ones.
Comment 4 Martin Janicek 2013-01-25 13:45:02 UTC
(In reply to comment #3)
> Is this going to be addressed in 7.3?

Not really, but since the groovy error badges feature were disabled for the NB7.3 final (they caused some performance issues in Grails applications), it does not really matter.

> I see on the Wiki that the code freeze date was planned to be January 9.  

It is just the day when a new release branch is created and only high priority issues are allowed and pushed to the 7.3 branch.
Comment 5 Martin Janicek 2014-07-16 12:53:56 UTC
No error in current dev version. I believe this has been fixed together with similar issue 236003 (web-main #ef5bddcdf234)

--> Closing the ticket