-1

I understand that unlike in C++, if I don't specify "public" or "private" when declaring a data member, it can be accessed from anywhere in the same package.

The designers of the Java language could have chosen the opposite, but instead they preferred to make class members public (in the same package) by default.

Any idea why?

an00b
  • 11,338
  • 13
  • 64
  • 101
  • 3
    "public" is not the same as "package-wide". – EboMike Mar 18 '11 at 23:00
  • This isn't a question for here - you should check the FAQ http://stackoverflow.com/faq – Brian Roach Mar 18 '11 at 23:01
  • @EboMike I understand that "public" is not the same as "package-wide" but this feature still surprises as I explained in my comment to @Roflcoptr below. I am trying to understand the benefits of this approach (I admit: It's very convenient for me as a programmer). – an00b Mar 18 '11 at 23:14
  • 1
    @Brian Roach Understanding design decisions is part of being a programmer. – an00b Mar 18 '11 at 23:20

7 Answers7

4

They're not public, they're accessible to members of the same package. The Java ethos is that a given package represents a coherent set of coperating responsibilities, so by default they should be able to interoperate.

You can always use a specific access level if you wish to enforce differnt semantics.

pauljwilliams
  • 19,079
  • 3
  • 51
  • 79
4

The default visibility in Java is package-private. This means you can access those entities if from the same package. I don't know why you think the default visibility is public.

RoflcoptrException
  • 51,941
  • 35
  • 152
  • 200
  • Thanks for explaining this. I was pleasantly surprised when Java let me set a data member of one class from a difference class (in a separate file), since I didn't have to go through the hassle of creating an accessor. It's more convenient but isn't against one of the principles of OO? – an00b Mar 18 '11 at 23:11
  • @an00b A separate file is not the same as another package. But I don't think that this has anything to do with OO principles, since its only the default visibility. You can change it whenever you want. – RoflcoptrException Mar 18 '11 at 23:13
  • I understand that a separate file is not the same as another package but still this is so different from C++. I recall how every textbook I read back then insisted that private-by-default is the way of OO ("information hiding") -- even when accessed from the same file! (in C++). I am trying to understand the mindset of Java, which is still new to me. – an00b Mar 18 '11 at 23:18
  • @an00b that's difficult to answer for me but Java is not the only OO language that is doing this. For example C# uses a very similar approach. However I personally think that package private is in the middle between keep information as private as possible and comfort that allows to access entities without specifying the visibility explicitly. – RoflcoptrException Mar 18 '11 at 23:23
2

I don't know the decision behind from sun as they invented java, but IMHO its because you need package-private types far more often then private or public classes.

For example, if you create a API in org.example.myapi.* you will try to have the calls to your API from outside to need as few classes as possible to keep thinks simple and all helper classes you need to let the API do what they should, should not be seen from outside. Most of the times you need more package-private API helper classes then public API call classes.

moritz
  • 5,094
  • 1
  • 26
  • 33
  • 1
    I'm using almost never the default access level - mostly private or public, with a bit protected. My theory is that they simply couldn't find a good keyword for "package-access", so they let it be the no-keyword case. – Paŭlo Ebermann Mar 19 '11 at 01:38
  • I haven't read the question careful enough (coffee is empty :). I have given this example for the use of package-private on class level. i don't remind if i ever used package-private on a class member, except for simple examples. – moritz Mar 19 '11 at 01:46
2

@anOOb wrote this in a comment ... and it deserves a thorough response.

I was pleasantly surprised when Java let me set a data member of one class from a difference class (in a separate file), since I didn't have to go through the hassle of creating an accessor. It's more convenient but isn't against one of the principles of OO?

It is actually deeper than OO. The principle is the principle of data encapsulation, and it applies to non-OO design as well.

The primary aim of accessors and mutators is to encapsulate the state; i.e. to prevent implementation details of a class from being visible outside of the class. There are two main reasons for doing this:

  • It simplifies reasoning about the behavior of a class if you control or prevent access to its internal state.

  • It makes it easier to change the implementation type and invariants of a state variable. If the code that uses a class only uses accessors / mutators (i.e. getters / setters) to access the object state, then you can often make changes to the classes state representation and invariants while hiding the effects of the changes from the callers; e.g. here's a trivial example

    private int counter;
public int getCounter() { return counter; }

    becomes

    private long counter;
public int getCounter() { return (int)counter; }
public long getLongCounter() { return counter; }

There are two more reasons we use accessors / mutators in Java:

  • An accessor or mutator method's behavior can typically be overridden in a subclass. By contrast, in Java you can't override or even change the visibility of an exposed attribute.

  • There are lots of frameworks / tools that depend on your classes having accessors and mutators with method names / signatures that follow the conventions of the JavaBeans spec.

It should also be noted that simple getter and setter methods are inlined by the JIT compiler, and therefore have minimal performance impact.

You should not think of creating accessors as a "hassle" that you should try to avoid. In fact, accessors (and mutators) are an important part of writing good quality Java code. This is considered to be "best practice", and typical style / bug checker programs will flag exposed state variables as problems.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

Just for reference:

Access Levels

--------------------------------------------------
Modifier    Class    Package    Subclass    World
--------------------------------------------------
public        Y         Y           Y         Y
protected     Y         Y           Y         N
no modifier   Y         Y           N         N
private       Y         N           N         N
bancer
  • 7,475
  • 7
  • 39
  • 58
1

I'd simply say that it would have been better if they made the default access level private. The idea was probably, as others note, that package access level would be the most frequently used access level because packages "represent a coherent set of cooperating responsibilities" (Visage). However, it turned out that private is the most frequently used access level.

IMO, the Java designers would change the spec to make private the default access level if they had a timemachine.

Community
  • 1
  • 1
Enno Shioji
  • 26,542
  • 13
  • 70
  • 109
0

Your assumption is wrong; fields are not public by default. The table below describes all visibility levels in Java:

Modifier    Class  Package Subclass World
public      Y      Y       Y        Y
protected   Y      Y       Y        N
no modifier Y      Y       N        N
private     Y      N       N        N

More info here: http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

Travis Webb
  • 14,688
  • 7
  • 55
  • 109
  • he said public in the same package, not public. He should have said package visibility but had the right intention just used incorrect description. – Alb Mar 19 '11 at 00:07