This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General 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
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Method Restriction Levels - Interfaces/Abstracts

 
Ranch Hand
Posts: 95
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: 65053
247
  • 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: 95
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: 95
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: 65053
247
  • 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: 95
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: 65053
247
  • 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: 95
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now that's what I'm talking about:)


 
Campbell Ritchie
Marshal
Posts: 65053
247
  • 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: 95
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: 1244
86
Hibernate jQuery Eclipse IDE Angular Framework Spring MySQL Database AngularJS Tomcat Server Java
  • 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: 95
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll give it a try. Thanks
 
Saloon Keeper
Posts: 10418
223
  • 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: 4331
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: 10418
223
  • 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: 95
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: 4331
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: 10418
223
  • 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: 65053
247
  • 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: 4331
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: 65053
247
  • 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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!