Community
Participate
Working Groups
The Eclipse compiler generates very useful warnings when a variable is not used when it is private. However, no such warnings when the member is package private and nobody in the package uses it. However, a package is a module and the compiler should have full visibility to the package. It would be very useful if the compiler would also generate these package private warnings.
Will consider, time permitting. Not very likely for 3.8 though.
Even though it's not best practice, other project may contribute classes to the very same package thus the compiler cannot know about all classes that possibly exist in the very same namespace.
(In reply to comment #2) > Even though it's not best practice, other project may contribute classes to the > very same package thus the compiler cannot know about all classes that possibly > exist in the very same namespace. Yes. I also don't see how this can be ever work with incremental builds. As an implementation note, JDT/Core has NO infrastructure in place to do such cross translation unit analysis. There are no plans to create such infrastructure either.
(In reply to comment #2) > Even though it's not best practice, other project may contribute classes to the > very same package thus the compiler cannot know about all classes that possibly > exist in the very same namespace. This only happens when you screw around with the classpath. A package is a java module like a class. In the same vein, private fields are then also accessible outside the class when you use reflection. With this argument the whole concept of default package access is utterly useless. Which is kind of sad since it is actually the default ... :-(
> I also don't see how this can be ever work with incremental builds. > > As an implementation note, JDT/Core has NO infrastructure in place to > do such cross translation unit analysis. There are no plans to create > such infrastructure either. Sorry to hear that. Since packages are so important in OSGi and are necessary to decouple modules it would be nice if this important functionality could be supported in some way.
As mentioned in comment#3, this cannot be made to work well with incremental builds, which triggers rebuild of client code when definition change. The current scenario would call for inverting this picture and won't sit well. Also as mentioned in comment#2 unsealed packages could be augmented. Closing as WONTFIX.
Verified for 3.8M5
