#21 no default access


My project's coding convention allows classes like

class Pair {
int x;
int y;

I.e. you can have default-access member variables in
a class as long as there are no methods.

Unfortunately, there doesn't seem to be any
configuration settings for checkstyle that accept the
class above.
I always get a message like:

Pair.java:10: variable 'x' must be privat
e and have accessor methods.

Workaround: declare the members 'public' and use the
public member pattern option (eg. in ant, use the
publicMemberPattern attribute). But this changes the
semantics of the class.


  • Oliver Burn

    Oliver Burn - 2002-01-17

    Logged In: YES

    Question: does this really change the semantics of the
    class? Since the example given, the class Pair's scope
    is "package". By changing the members to "public" does not
    make them accessible outside the package. The scope will
    still be "package". This seems a reasonable workaround?

    If not, what kind of option would you like added to
    checkstyle? A packageMemberPattern attribute.

  • Michael McDougall

    Logged In: YES

    Oops. You're right -- the semantics only changes if
    the class is public. But public classes are also allowed to
    have default members in my convention anyway (as long as
    they have no methods), so it's still a bit of a problem.

    A 'packageMemberPattern' or 'defaultAccessMemberPattern'
    would make sense. However, it would be nice if I could
    turn off all default access members so an
    'allowDefaultAccess' flag might be nice too.

  • Lars Kühne

    Lars Kühne - 2002-01-18

    Logged In: YES

    Note the "... as long as there are no methods" part of the
    coding conventions.

    Should the 'allowDefaultAccess' flag be equivalent to
    'allowProtected', i.e. allow members with default access in
    any class - even those that contain methods? That would
    allow you to check the class without errors but would not
    enforce your coding conventions.

    BTW: Why not convert the code to use accessor methods? Does
    the direct access give you a measurable performance
    increase? I always thought that HotSpot would do the
    optimization for you if you make the accessors 'final'. But
    maybe I read too many Sun marketing papers, so correct me if
    I'm wrong ...

  • Michael McDougall

    Logged In: YES

    Well, there are a number of things that my convention requires
    that checkstyle cannot check. I'd like to check a decent
    subset of my convention without getting false violation
    messages. 'allowDefaultAccess' seemed like a simple way
    of accomplishing this without too many modifications
    to checkstyle, even if it will not flag default access
    members in classes with methods.

    As for accessor methods, it's probably out of scope for this
    bug report but here are two quick responses:
    1. sometimes you only want a very simple struct class like
    a Pair of ints -- writting accessor methods (along with all
    the javadoc) is sort of a pain.
    2. it's not only my convention -- I have to convince the
    other developers. It was hard enough to settle on a
    convention in the first place.

  • Lars Kühne

    Lars Kühne - 2002-02-05

    Logged In: YES

    This is now implemented in CVS and will be available in the
    next release


Log in to post a comment.