jjh08's Profile User Rating: -----

Reputation: 55 Whiz
Active Members
Active Posts:
182 (0.24 per day)
13-July 12
Profile Views:
Last Active:
User is offline Dec 03 2013 03:30 AM

Previous Fields

OS Preference:
Favorite Browser:
Favorite Processor:
Favorite Gaming Platform:
Your Car:
Who Cares
Dream Kudos:

Latest Visitors

Icon   jjh08 studying Java in my spare time

Posts I've Made

  1. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 7 Nov 2013


    Thank you for not giving up on me after the 2134524th question on the same topic!

    It's no problem. Like I said earlier, I'm not an expert myself but I try to help out when I can. Just keep practicing, it just takes time :)
  2. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 6 Nov 2013


    It's public, so it should be visible from the Instrument class, it has the same name

    The parent class Instrument cannot just see any added methods of its child class Guitar, even though they have the same name. In other words, an Instrument only knows how to play() like an Instrument (it's actually abstract, but for the sake of the example, let's pretend an instrument has a specific sound) but it has no clue how to play() like a Guitar. Here is another example.

    However, there are several ways you can allow a parent class to see the data members of its child class.
    One way is through composition. That is you basically give the parent class an object reference of its child class. (Note: You can generally use composition anytime, it is not just limited to inheritance.)
    Another way is through a downcast. That is you perform a downcast on the parent class to the child class's method you want to call. In our case, that would be Guitar.play(). By performing a downcast, you are basically telling the compiler to not worry about type-checking at that particular point.
    You can also use inner/nested classes but I think that is a little bit complex for this topic and I would have to restudy it :P/>
    Here is a modified example of the source code which includes a demonstration of composition and downcasting:
    class Instrument {
    	  private void play() { // <--- THIS IS THE ONLY LINE CHANGED
    	    System.out.println("Play Instrument");
    	  static void tune(Instrument i) {
    	  // Demo #1 - Using composition to call Guitar.play()
    	  void callViaCompositon() {
    		  Guitar g = new Guitar();
    	  // Demo #2 - Using a downcast to call Guitar.play()
    	  void callViaDownCast() {
    		  Instrument ins = new Guitar();
    	public class Guitar extends Instrument {
    	  public void play(){
    	    System.out.println("Play Guitar");
    	  public static void main(String[] args) { 
    	    Guitar guitar = new Guitar(); 
    	   // No upcast will be performed because Instrument.play() is private, therefore Guitar.play() is a brand new method and is not inherited.

    For our example, an analogy for composition could be something like the parent Instrument asking the child Guitar : How do I play() like you?

    An analogy for the downcast could be something like the parent Instrument going to the gatekeeper (the compiler) and saying "No really, I'm actually a Guitar." and the compiler saying "Whatever dude, you can pass."


    To clarify, I'm not talking about the inheritability of the private method, I'm talking about the Polymorphism not being factored in when the subclass method is a public one, with the name of a private method in the mother class.

    I'm guessing that this is the line that is confusing to you:

    Let's break it down this way:
    When Instrument.play() is public, Guitar class inherits from it and will recieve Guitar.play(). It will get this method whether you explicitly declare it or not. Later on, at runtime, the JVM basically sees that Guitar.main() is calling a method of a base class, which is Instrument.tune(). However, the JVM also sees that you gave Instrument.tune() a 'guitar' reference and it knows that Guitar IS-A Instrument because of this line
    public class Guitar extends Instrument so instead of calling the parent class's method :
    public void play() { 
    	    System.out.println("Play Instrument");

    The JVM calls the child class's method instead :
    public void play(){
    	    System.out.println("Play Guitar");

    Remember, all of this is done via the tune() method.

    On the other hand, when Instrument.play() is private, Guitar class never inherits from Instrument class and the explicitly declared method Guitar.play() is not related to the private method Instrument.play().
    So, at runtime, when you call Instrument.tune(), the JVM still sees that 'guitar' reference (remember that Guitar IS-A Instrument) but it knows that there is no relationship between the private method Instrument.play() and the public method Guitar.play() with the exception of them having the same name so it will simply call Instrument.play() via the tune() method.

    I know that is a lot to absorb and I apologize if it is still confusing but I have no better way of explaining it than that. I hope this helps :)
  3. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 5 Nov 2013

    Hello again,


    I shouldn't know about the private methods of a class. If I call them from a subclass, and the Polymorphism in not effective, why would they run anyway?

    The private method in Instrument is not seen by any other class period so you are correct and the polymorphism was never factored in because as Peter O said, the "hidden" play() method was called from within the Instrument class via the tune() method.
    To reiterate what I said in an earlier post, Guitar.main() calls Instrument.tune(). From that point, Instrument.tune() will call Instrument.play() and the output "Play Instrument" will be displayed. It is true that Guitar class has no idea of the private method Instrument.play(). However, it uses another method Instrument.tune() which will call the private method. I apologize if my speech is redundant but I don't know how to explain it clearer than that.


    I would try the case where the mother class is public and the subclass method is private

    I did a little bit of researching and I was able to find the answer for that here. According to section "Requirements in Overriding and Hiding" of the Java Language Specification:


    The access modifier (6.6) of an overriding or hiding method must provide at least as much access as the overridden or hidden method, as follows:

    If the overridden or hidden method is public, then the overriding or hiding method must be public; otherwise, a compile-time error occurs.

    If the overridden or hidden method is protected, then the overriding or hiding method must be protected or public; otherwise, a compile-time error occurs.

    If the overridden or hidden method has default (package) access, then the overriding or hiding method must not be private; otherwise, a compile-time error occurs.

    Basically, Java will not allow a data member of a child class to have less-restricted access than its parent class. This actually makes sense because if a superclass is public, the child class has no choice but to also be public because it received its attributes (I like to think of it as DNA in a sense) from its parent.

    I hope that this helps you to get a better understanding :)
  4. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 4 Nov 2013

    Hello domenico, I will try to explain this process to best of my knowledge but I am not an expert.


    1) Guitar extends Instrument, so it has every Instrument method, without the private ones.

    I believe that this is correct.


    2) public void play() in the Guitar class, is not an override, it's more a redefinition of the play method, since it was not inherited from the mother class (it has been defined private there)

    I believe this is also correct.


    3) When I call Instrument.tune(Instrument i) upcasting happens and the Guitar is now an Instrument, but it references is still the one of the guitar object, that has the capability of public void play()'ing but that doesn't happens anymore.

    I believe what is happening at this point is that when static void tune(Instrument i) is called in main(), the key factor is not necessarily the 'guitar' reference but the method call itself. In other words, the Guitar child class calls tune() which belongs to the Instrument parent class (It also inherited tune() but this is irrelevant for our example). This tune() method will then call the "hidden" play() method which will output the original statement "Play Instrument".

    On the other hand, when the play() method of the Instrument class was public, as in your first example, the child class Guitar would inherit play() from its Parent class Instrument. So, in that case, when you call tune() in main(), the compiler/JVM (not sure which one or both) will still go through the process of checking the Parent class play() method. However, the compiler/JVM (whichever one??) sees that you inserted a 'guitar' reference within tune() and a process called late binding/dynamic binding will occur which means that the Guitar's play() method will be displayed in the output at runtime which would be "Play Guitar".
    I hope our experts can chime in and verify this information but I believe it is correct if I remember correctly.


    4) The private method inside of the mother class is called, and all the things I ever thought I learned about upcasting are gone, abruptly smashed to death.

    No, those private methods definitely were not accessed by the child class so you were originally correct.

    As for your pseudo-code:
     if (staticTypeMethod.isPrivate()) {
    else {
      if (dynamicTypeMethodExists) {
      } else {

    I don't think it matters if the method is static or dynamic but I could be wrong.
    In the example below, I basically just removed the static keyword from the tune() method and we still see the same result unless I'm not understanding your second post correctly.
    class Instrument2 {
    	private void play() {
    		System.out.println("Play Instrument2");
    	void tune(Instrument2 i2) {
    public class Guitar2 extends Instrument2 {
    	public void play() {
    		System.out.println("Play Guitar2");
    	public static void main(String[] args) {
    		Instrument2 instrument2 = new Instrument2();
    		Guitar2 guitar2 = new Guitar2();

    Anyway I hope my information will be able to help you :)
  5. In Topic: How do moderators choose threads for featured content?

    Posted 29 Oct 2013

    View PostCurtis Rutland, on 29 October 2013 - 10:24 AM, said:

    Basically, it's up to us. I personally look for threads that will likely produce (or already have produced) some interesting discussion. That's really it. I don't go out of my way to actually search for it, but if I read a thread that happens to fit, I will feature it. I don't do that often, since most threads that deserve to be frontpaged already are from some of the more automatic methods (number of replies, amount of rep given to single posts, total rep in the thread, etc...)

    My best advice is: don't try to make a thread that will get featured. Just make the threads you need to make, be it help threads or sharing great industry articles or discussion topics. If we think they need more visibility, we'll handle that side of things. If there is some particular reason you feel that your thread deserves featuring and we haven't done so, feel free to PM one of the moderators or admins (dark blue and green badges respectively), but understand that it's solely up to our discretion, and our decisions are final.

    Thanks Curtis Rutland for your insight :)
    I personally didn't have a thread that I felt needed featuring but I was just curious to how the process worked.
    Your help is much appreciated.

My Information

Member Title:
D.I.C Head
Age Unknown
March 24
Java Programming, playing video games, exercising, guitar
Full Name:
Jason H.
Years Programming:
Programming Languages:
Java - comfortable with OOP: Composition, Inheritance, Polymorphism, Interfaces
Basic Data Structures : List, Set, Queue,Map

Need to work on : Regular expressions, Generics(in depth), Arrays(in depth), Data Structures(in depth), I/O, Enumerated Types, Concurrency, and Swing/Graphical User Interfaces (GUI)

Contact Information



jjh08 has no profile comments yet. Why not say hello?