• Post Reply Bookmark Topic Watch Topic
  • New Topic

interfaces  RSS feed

 
Randall Twede
Ranch Hand
Posts: 4696
8
Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i tried to write this interface

and classes tike this

i get a compiler error saying
attempting to assign weaker access privileges; was public
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Methods declared in interfaces are always public, sadly. This was an oversight during the initial design process of Java.

You can't implement the interface with a package private method, because you would be trying to make the method more private.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You also shouldn't name your custom class Character. Character is already a well known class in the standard API. I always avoid giving my types names that are already used in the packages java.lang, java.util and java.io.
 
Randall Twede
Ranch Hand
Posts: 4696
8
Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You also shouldn't name your custom class Character. Character is already a well known class in the standard API. I always avoid giving my types names that are already used in the packages java.lang, java.util and java.io.

well it is a all by itself default package type program so i'm not worried about that
i did do this which works


the interface and implementing classes are package access, but the methods are public.
actually i think i might rename the Character class. it might help with something else in the program.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Methods declared in interfaces are always public, sadly. This was an oversight during the initial design process of Java.

You can't implement the interface with a package private method, because you would be trying to make the method more private.


Why is it sad? If a class is only visible within its package, then nothing outside the package can call that method anyway.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is usual to omit the keywords public static in interfaces, because all their methods are implicitly public static.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:Why is it sad? If a class is only visible within its package, then nothing outside the package can call that method anyway.


What if you have a public class that implements a package private interface because that's useful to other classes in the package? Then the class is forced to export methods that might never have been intended to stray out of the package.
 
Roberto Perillo
Bartender
Posts: 2273
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:It is usual to omit the keywords public static in interfaces, because all their methods are implicitly public static.


Hum... that's true for fields, but not for methods. Methods are not implicitly static, but are implicitly public. For instance:

 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did I say methods are public static? Good grief! What a mistake
 
dennis deems
Ranch Hand
Posts: 808
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
Dennis Deems wrote:Why is it sad? If a class is only visible within its package, then nothing outside the package can call that method anyway.


What if you have a public class that implements a package private interface because that's useful to other classes in the package? Then the class is forced to export methods that might never have been intended to stray out of the package.


Do you have a particular scenario in mind? It seems to me that the public class either shouldn't implement the package-scope interface or shouldn't be public. I am quite suspicious of the phrase "useful to other classes in the package" which could be used to justify all sorts of abuses.
 
Roberto Perillo
Bartender
Posts: 2273
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Good grief! What a mistake


I think you meant abstract instead of static, right?!
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I must have meant abstract.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:Do you have a particular scenario in mind? It seems to me that the public class either shouldn't implement the package-scope interface or shouldn't be public. I am quite suspicious of the phrase "useful to other classes in the package" which could be used to justify all sorts of abuses.


I don't see why it would necessitate abuse. Do you also think that it's weird for a class to have both public and package private methods? Package private methods in a public class can be extremely useful, if two classes in the package have to work together, but want to export one simple API. So if this aggregation is useful, then why can't we generalize the contract of these package private methods in a package private interface? What if we want the package private class not to use the public class explicitly? Say, when we want to be able to plug in a different class hierarchy later.

I can't think of a very specific example right now, but I know I've run into problems in the past with interfaces forcing public methods.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
Dennis Deems wrote:Do you have a particular scenario in mind? It seems to me that the public class either shouldn't implement the package-scope interface or shouldn't be public. I am quite suspicious of the phrase "useful to other classes in the package" which could be used to justify all sorts of abuses.


I don't see why it would necessitate abuse. Do you also think that it's weird for a class to have both public and package private methods? Package private methods in a public class can be extremely useful, if two classes in the package have to work together, but want to export one simple API. So if this aggregation is useful, then why can't we generalize the contract of these package private methods in a package private interface? What if we want the package private class not to use the public class explicitly? Say, when we want to be able to plug in a different class hierarchy later.


Without knowing the specifics, it sounds very much to me as if at least one of these classes is taking on too much responsibility. Btw, "package private" is an ungainly phrase. I have not known a single java developer to use it. The few times I have used it I have been misunderstood to say "private". Why not simplify everything and just say "package"?
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:I can't think of a very specific example right now, but I know I've run into problems in the past with interfaces forcing public methods.

I have to admit, I'm with Dennis on this one. The whole point of an interface is that its API is public, and it also defines a type, so you can't have a public class that implements both a public and package interface without giving away information that clients shouldn't know about.

I have to admit to having run into the same problems as you describe myself, but it was usually due to bad design on my part; and what you want can be produced with a composite class and a package interface that extends a public one.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
Dennis Deems wrote:Why is it sad? If a class is only visible within its package, then nothing outside the package can call that method anyway.


What if you have a public class that implements a package private interface because that's useful to other classes in the package? Then the class is forced to export methods that might never have been intended to stray out of the package.


I really can't imagine how this would ever come up. And if in some rare corner case it does with a small refactoring.

I admit that it seems a bit inconsistent or asymmetrical or just plain odd that a package private interface doesn't have the option to make its methods non-public. Still, having said that, the use case does seem awfully unusual, and possibly design-smell-y. Though I wasn't there when the decision was made, and though I don't actually know squat about language and compiler design, I can see how it might have made things simpler just to blanked require that all interface methods are always public, and not expend the effort and add the complexity to support this oddball use-case.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!