Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Method Restriction Levels - Interfaces/Abstracts  RSS feed

 
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was practicing overriding methods from reference to abstract to extend and was wondering why setting readBook() or setBook() to anything but public in Book or EBook classes is giving me compiler error? Isn't setting them to protected or package private same or weaker restriction level as they are in the reference?

 
Marshal
Posts: 64496
225
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look in the Java® Language Specification, which tells you that

A method in the body of an interface may be declared public or private (§6.6). If no access modifier is given, the method is implicitly public.

If you aren't using Java10‑type private methods, then all interface methods are public and must only be overridden with public access.

You can't override private methods anyway; they have no existence in the subclass.
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should have known it was some basic rule behind this:)
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Given the following code snippet,



1. I don't understand how do the parameters work in the Walk method()?
2. If one was to access any of the walk methods from the Test class' main(), how would the code layout?

I appreciate any hints. Thanks
 
Campbell Ritchie
Marshal
Posts: 64496
225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please indent your code correctly. I had to count the {} to work out whether the square and rectangle are or are not inner classes in the Printable interface. Poorly‑indented code is difficult to read, and you, having less experience than me, will experience such difficulties much more than I do.

Remind yourself of the rules about method overloading. Remember also that overloading is resolved at compile time, not like overriding which is resolved at runtime. More details about compile time resolution here. Briefly, it seeks the most specific match; if you pass Rectangle or Square references, those are more specific than Printable, so it will go for those methods and a Circle will go for the method with Printable as its parameter type.
I trust you only wrote that code to investigate overloading; you would learn a lot more if you added lines like System.out.println("Square method."); to those walk(...) methods.
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry about the indentations. When I copy the code from NetBeans it shifts around. I'll pay more attention to it.

You are correct. I was looking into overloading by passing references, and through I must admit, some trial and error I came up with passing class and reference to walk() and to be honest a bit surprised that it worked. So that's why I asked the question about the logic of how it worked.

Since you mentioned adding the print statements to the walk() to see what happens, I added more code to the main() of the Test class to make sure the print results came out the same. But, is there a good way  to consolidated all these different instantiations?

 
Campbell Ritchie
Marshal
Posts: 64496
225
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you mean something like this?Don't know why you are getting problems copying from NetBeans, sorry.
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now that's what I'm talking about:)


 
Campbell Ritchie
Marshal
Posts: 64496
225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would have displayed the names of the methods in the overloadings:-You should find the same names for square and rectangle, but if you have a circle class or triangle, that will go as plain simple Printable.
Some nice repeated code there. Good thing this code is just there to see what happens if......
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since I originally setup Printable as an interface and others to implement it to see how they interact by passing a reference, I left them the way they were setup. But you're right, now that I see how they interact, the code has a lot of room to streamline.
 
Bartender
Posts: 1207
82
Angular Framework AngularJS Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jake Monhan wrote:Sorry about the indentations. When I copy the code from NetBeans it shifts around. I'll pay more attention to it.

Select the source file and press Alt + Shift + F  ( Or right click --> Format ) in NetBeans IDE to format the code then copy and paste that code in code tags, see If it helps.
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll give it a try. Thanks
 
Saloon Keeper
Posts: 10249
216
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:If you aren't using Java10‑type private methods, then all interface methods are public and must only be overridden with public access.


This is actually one of by biggest peeves about Java. I wish that virtual methods had the same access level as the interface they were declared in, whether or not you specify that access level explicitly.

Let's say I have a package containing a package private interface, because that interface is only used within the package. It also contains a public class that implements that interface. As it stands, my class MUST expose the methods declared in the interface, even though I would have liked them to remain private to the package.
 
Enthuware Software Support
Posts: 4308
35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

Campbell Ritchie wrote:If you aren't using Java10‑type private methods, then all interface methods are public and must only be overridden with public access.


This is actually one of by biggest peeves about Java. I wish that virtual methods had the same access level as the interface they were declared in, whether or not you specify that access level explicitly.

Let's say I have a package containing a package private interface, because that interface is only used within the package. It also contains a public class that implements that interface. As it stands, my class MUST expose the methods declared in the interface, even though I would have liked them to remain private to the package.


That could get complicated. What if a class a.C implements an interface b.I that has a package private method m()? Depending on how the language handles this situation, it will cause inconsistency one way or the other.
 
Stephan van Hulst
Saloon Keeper
Posts: 10249
216
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I wish that virtual methods had the same access level as the interface they were declared in, whether or not you specify that access level explicitly.


a.C wouldn't be able to implement b.I unless b.I was public, and if it's public, its virtual methods would be public as well.
 
Jake Monhan
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at the last 3 posts, it looks like this is something to be debated for improvements(?) in java 11.
 
Paul Anilprem
Enthuware Software Support
Posts: 4308
35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

Stephan van Hulst wrote:I wish that virtual methods had the same access level as the interface they were declared in, whether or not you specify that access level explicitly.


a.C wouldn't be able to implement b.I unless b.I was public, and if it's public, its virtual methods would be public as well.


Ok, got you. So, you mean only a package private interface can have package private methods?
 
Stephan van Hulst
Saloon Keeper
Posts: 10249
216
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes.

I'm not aware of any technical reasons not to implement this in the language, maybe the designers wanted to keep things simple. The current situation really annoys me though.
 
Campbell Ritchie
Marshal
Posts: 64496
225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Anilprem wrote:. . . Ok, got you. So, you mean only a package private interface can have package private methods?

That is what Stephan would have liked, but not what the language implemented. There are all sorts of features which users don't like. I personally don't like permitting calling static methods on instance references, or allowing the construct int numbers[] =...
But we are stuck with them.
 
Paul Anilprem
Enthuware Software Support
Posts: 4308
35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Paul Anilprem wrote:. . . Ok, got you. So, you mean only a package private interface can have package private methods?

That is what Stephan would have liked, but not what the language implemented. There are all sorts of features which users don't like. I personally don't like permitting calling static methods on instance references, or allowing the construct int numbers[] =...
But we are stuck with them.


Ability to access static members using a reference variable is the worst  
 
Campbell Ritchie
Marshal
Posts: 64496
225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Anilprem wrote:. . . Ability to access static members using a reference variable is the worst  

Good point. If you look in books like Java Puzzlers by Bloch and Gafter, you can see the sort of error that can occur if you call static methods on an instance reference.
 
The harder I work, the luckier I get. -Sam Goldwyn So tiny. - this ad:
how do I do my own kindle-like thing - without amazon
https://coderanch.com/t/711421/engineering/kindle-amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!