Sorry, I guess I will need a reproducible example to evaluate. I tried to remove unused imports from the javac/langtools source code (which in my experience does more complex stuff with imports than NetBeans sources do) and it is still buildable after that.

The thing is, this only happens with a few classes - I have other classes with loads of Lombok imports and the importing looks fine.

I still don't know what the root cause is, but this is definitely something new in my change from 7.1.2 to 7.2RC1 and would be a show stopper for me upgrading - so keen to help get to the bottom of this!

I had a look at the generated source code from Lombok and it also still needs the imports in order to compile. Let's keep this opened for a little while (helps me to find it) to give me time to find a standalone failure case.

(In reply to comment #3)
> I had a look at the generated source code from Lombok and it also still needs
> the imports in order to compile. Let's keep this opened for a little while

So could you please try to take the generated source code, replace the original with it and see if it still produces incorrect unused imports? Using the generated code would probably make it easier to find a standalone case.

> (helps me to find it) to give me time to find a standalone failure case.

Very well, lets assign it to you until the reproducible test case is found.

replacing original, the import warnings no longer show up. I'll investigate getting a standalone.

Jan, I could send you my project privately if you'd like to see this?

Found the culprit! It is the Lombok @Synchronized annotation. Test case:


import java.util.Collections;
import lombok.Synchronized;

public class Scratch {

    public static void main(String[] args) {
        new Scratch().scratch();
    }
    
    @Synchronized
    void scratch() {
        Collections.emptySet();
    }
}

Thanks for the testcase. The cause of the problem is the synthetic (generated) synchronized block - everything under a synthetic tree not is considered to be synthetic (holds for all currently existing standard trees generated by javac, AFAIK). In fact, it breaks a lot of the Java support, not only the unused imports. I will need to think which of the possible conclusions is most appropriate:
1. fix is possible in Lombok. Then ideally it should be fixed there, as Lombok is the part of the system doing something very strange. Actually, I think I know how to fix the problem with @Synchronized (Lombok could skip generating the synchronized block when running in NB editor), but similar problem occurs with @SneakyThrows and that is not that simple to resolve.
2. a reasonably-sized workaround is possible in NetBeans, without causing problems to the Java language support (I am very reluctant to do any changes to improve the Lombok support that would cause any problems to the Java language support). Not sure yet this is possible for @Synchronized/@SneakyThrows. I am almost sure this is possible for "val", at the cost of slowing down editor for Lombok-enabled projects (but noone else).
3. the given feature is impossible to support properly without writing a lot of specialized code (a new language support in the most general case).

So basically the NetBeans Java parser can't see methods with the @Syncronized annotation on them, because they are rewritten in the compile stage? Ouch!

Does option 1 imply that some Lombok features would be skipped when "compiled on save"? That's nasty.

Perhaps a Netbeans only, option 2, solution would be best as Lombok will only grow in popularity and some specialist support for it might help.

When I found Lombok, I really hoped that they would stick to source code rewrites which are always valid Java on both ends: essentially just annotations sitting on top of already valid code. However, some of the method-related features (especially from lombok-pg) go too far IMHO, as does 'var' (that's starting to be a new language). It is somewhat ironic that an annotation-based feature causes the problem here!

Personally, I'd be happy with support for just the annotation-based features.

You seem to be thinking about Lombok already - do you want to create an issue report with them on this to open the discussion? (I'll quietly step away and let the experts do the talking...)

  http://code.google.com/p/projectlombok/issues/list

(In reply to comment #9)
> So basically the NetBeans Java parser can't see methods with the @Syncronized
> annotation on them, because they are rewritten in the compile stage? Ouch!

The body is wrapped with a synchronized block during annotation processing.

> 
> Does option 1 imply that some Lombok features would be skipped when "compiled
> on save"? That's nasty.

No, it could skip @Synchronized only while in the editor. Could generate the current code when compiling to classfiles. Don't know how to do that with @SneakyThrows, though.

> 
> Perhaps a Netbeans only, option 2, solution would be best as Lombok will only
> grow in popularity and some specialist support for it might help.

Meaning that whatever new feature is added to Lombok, someone in NetBeans would spend a week, a month or maybe half a year updating the IDE to handle it properly? And refix that for each version of Lombok that may do stuff a little bit differently? All this instead of improving/fixing the Java support? That does not sound like something that could scale (you are welcome to send patches, though, as long as they do not break the Java support). I don't mind spend a hour or two now and then to make source code written in Lombok work better, but long-term systemic effort to make it work correct is something different - that could actually affect the quality of the IDE support for the Java language.

> 
> When I found Lombok, I really hoped that they would stick to source code
> rewrites which are always valid Java on both ends: essentially just annotations
> sitting on top of already valid code. However, some of the method-related

Well, at the beginning, its often not a valid Java (e.g.:
    @SneakyThrows
    void scratch() {
        throw new Exception();
    }
is not a valid Java - a Java compiler must produce a compile-time error according to JLS for this code, to the best of my knowledge), and has a different semantics from the Java language in other cases (@Synchronized). At the other end of Lombok, it might be valid Java tree, but that is obviously not enough for an IDE. For example, when the user Ctrl-clicks in the editor the IDE needs to find out on what element the user clicked. More data than just a "valid Java tree" are needed for that.

> features (especially from lombok-pg) go too far IMHO, as does 'var' (that's
> starting to be a new language). It is somewhat ironic that an annotation-based
> feature causes the problem here!

Not sure why "annotation-based feature" should be something conceptually different from "val"/"var"? Lombok still does not use official or semi-official APIs to do that - it still messes with javac internal/implementation structures.

> 
> Personally, I'd be happy with support for just the annotation-based features.
> 
> You seem to be thinking about Lombok already - do you want to create an issue
> report with them on this to open the discussion? (I'll quietly step away and

I may if I will find some time (even though I would not define that as "want to"). Still feels as strange approach - its Lombok, not NetBeans, doing something very, very, fragile and weird.

> let the experts do the talking...)
> 
>   http://code.google.com/p/projectlombok/issues/list

FYI, I have filled:
http://code.google.com/p/projectlombok/issues/detail?id=393

Greatly appreciated, Jan! I really hope Netbeans + Lombok can continue to play well because my recent discovery of Lombok has kept me from moving on to other languages.

Jan, for your reference, the lombok-pg (I guess it's for "proving ground" or something) project has taken your comments to heart:

https://github.com/peichhorn/lombok-pg/issues/99

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss