• Post Reply Bookmark Topic Watch Topic
  • New Topic

Access Modifiers  RSS feed

 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why does this not give a compilation error?My understanding is that the Class defines the maximum audience for the class and everything inside the class. Within the class you can then shrink that audience by applying more restrictive access modifiers. However, in this example I have made the class "default" modifier i.e. visible only to the javaStuff package. But inside I've use two access modifiers which define visibility which is more than the class. Don't understand why the compiler doesn't flag this as an error.

Cheers,

PaulC.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know if the JLS has any specific discussion about why this is the way it is. It would be interesting to know how the conversation went around this question, which I'm sure it must have been discussed at some point. It's possible that someone reasoned that since the class accessibility ultimately dictates what can be accessed, it really doesn't matter much whether its innards are potentially more accessible. Besides, you may start out limiting the class accessibility at first for whatever reason, testing or what not, then go ahead and make it more widely accessible later. If you limit the access of the methods and fields the same way, you may end up having to change more code than you would have had to otherwise. That's just conjecture on my part though. To know the real reasons, we'd probably have to get the story from someone who was in the room when that decision was made.
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:To know the real reasons, we'd probably have to get the story from someone who was in the room when that decision was made.
You mean you WEREN'T in the room! How disappointing. I assumed you would have been :-)
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clements wrote:You mean you WEREN'T in the room! How disappointing. I assumed you would have been :-)

Not even as a fly on the wall, unfortunately
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this is because of the following:

A package-level (non-public) class can implement a public interface. The methods of the interface are public. You could have a method which has the interface as the return type. Code outside of the package could then call that method and get a value back that is of the interface type. The method could in reality create an instance of the package-private class and return that, but the caller on the outside doesn't need to know that. It only needs to know that it gets an object back which implements the interface.

The method from the interface that is implemented in the package-private class needs to be public, because it's public in the interface.

Like this:



 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:The method from the interface that is implemented in the package-private class needs to be public, because it's public in the interface.

Great point! Have a cow!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!