#18 Want to forbid UCDetector from suggesting package visibility

[Anonymous]

I, like a lot of other Java developers don't like package ("default") visibility, and don't use it in my code. (Frankly, I don't think it should have ever made it into the Java language.)

I would like to be able to have a checkbox which, when checked, would mean UCDetector would never suggest to me that a method, variable, etc. should be assigned to have package visibility. Instead, UCDetector should suggest that the method be made either public, private, or protected as necessary.

[Nobody/Anonymous]

Hi,

this is exactly was UCDetector does: :-)
It suggests that a method or field should be private or protected (public does make no sense here).
UCDetector never suggests to make a method or field to be default (package visibility).

BUT UCDetector suggest classes to have DEFAULT visibility, because classes can not be protected
(compile error). Local classes can be protected.

Here are some UCDetector messages examples:
Change visibility of Class "UseDefaultClass" to default
Change visibility of Field "QuickFixExample.useProtectedField_1" to protected
Change visibility of Field "UseProtectedClass.useProtected_public" to protected

Joerg

[Nobody/Anonymous]

Well default visibility is used a lot in JDK source for intra package access. It's good thing this access exists. Even if UCDetector doens't propose it.

[Joerg Spieler]

Marked as pending: Nothing todo (see last comment)

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[Miquel Martin]

Hi,
It looks like the OP didn't respond to further inquiries. I'd like to support his original request, in that, in my opinion (and the way I use java), package/default access is a questionable practice, and I would appreciate being able to tell UCDetector to ignore it.
Thanks!

[Joerg Spieler]

Hi Miquel,

I am not completely sure, what you mean.
Would you like to:
1. See no protected warnings at all
2. See no default warnings at all
3. Switch default warnings to protected warnings.
4. What about classes or interface default warnings? A class/interface can't be protected!

1. and 2. is already realized. Set UCDetector "Keywords" settings of "Classes/methods/fields/constants protected" to "Ignore"

For 3. we need a new checkbox as described in original request.
For 4. we must decide to show now warnings, or show default warnings

Jörg

• status: closed --> open
• milestone: --> Next_Release

[Jonathan Lovelace]

In my projects, if a class or a method (other than an inner-class constructor or method that can't be private because the outer class calls it) doesn't have an explicit visibility (public, protected, or private), this is a sign that I forgot the visibility keyword. And it never lasts long because Eclipse's compiler flags it with a warning, and so do at least two of the four (and counting) static analysis plugins I use.

So I want a way to configure UCDetector to only suggest reducing the visibility of a public class or method if it's possible to reduce it to protected or private, never to merely "default" (which I've also seen called "package-private"). The lack of this feature makes UCDetector essentially useless for me: before I run it, I have 22 warnings in my "problems" view. After I run it, I have 300-some, and all of the 100 that Eclipse shows me appear to be telling me that something could be reduced to "default" visibility, not below. And if I followed any of those recommendations, it would cause at least three warnings to replace each one it "fixed."

[Anonymous]

I share Lovelace's point. Is this featuree available now ? Couldn't see it.

[Joerg Spieler]

No the feature is not available.
Workarround: If UCDetector suggests default visibility,
simply start the declaration with "protected"

[Anonymous]

Resorting to default access is a code smell in OO, something recognised by most static anlysis tools. Access qualifies should allways be explicity specified by convention. The OP is correct that default access should not be present in Java language and should never be used in production quality code. Using protected instead of public would make things misleading in many cases. Clarity trumps bevity. Take the following code, the only access qualifies that make sense are public or private.

public static InputStream getStream(final String resourceName) {...}

[Wolffpack]

Stumbling onto this feature request, I'd also like to say that this would be great to have. I'm fixing some legacy code right now and there is just A LOT of markers, but these "change visibility... to default" are simply unwanted and make it hard for me to see the correct markers by UCDetector.

[Joerg Spieler]

Hi Wolffpack,
you can deactivate "change visibility... to default" Warnings in UCDetector preferences Dialog:
Tab "Keywords" -> Classes/Methods/Fields protected: Change to "Ignore"

Note: UCDetector does not distinguish between protected and default visibility.