classes and methods

[kevin Abel]

I am learning about overloading objects.   I see these words in front of classes and methods showing where it can be seen.  Are they available at both the Class and Method level?  

Private  - The value can only be seen by the class.
Default  -- I am guessing that it is the default value of a variable.  I dont know yet.  I'll probably learn about it later on.
Protected  -- no idea yet
Public  -- The Class/Method can be seen by everyone else.

I have been learning Java with a base of knowledge that I forget and learn over many years.  Maybe I should just start from the beginning.  I don't know.  I only need enough to write Selenium Test Scripts so I might be better off just learning the parts as I go forward.  Please forgive me if I ask things I should know being this far into Java but I"m in a strange learning curve.

Thanks,

Kevin

[Carey Brown]

Access Modifers apply to classes, methods, and fields.

Java provides a default specifier which is used when no access modifier is present. Any class, field, method or constructor that has no declared access modifier is accessible only by classes in the same package.

Most thing should be specifically identified as private unless otherwise needed directly by other classes.

Protected is like private with the exception that an immediately inherited subclass also has access.

[Campbell Ritchie]

Have a look in the Java™ Tutorials. I think I have given you the right section.

You usually only apply the term overloading to methods and constructors, and it has a very specific meaning. The name is the same but the parameters are different.

[Junilu Lacar]

Carey Brown wrote:Protected is like private with the exception that an immediately inherited subclass also has access.

That seems to imply that not all subclasses have access to protected members, which isn't true. All subclasses can access a protected member because you can't specify a more restrictive access for an inherited member in a subclass. You either keep the same access specified by the superclass or you make it wider.

Can you clarify what you mean by "immediately inherited"?

[Campbell Ritchie]

I also don't think that is correct; protected members are also accessible to all code in the same package. What does protected mean in C++?

[Stephan van Hulst]

An overview:

private: Only code within the same source file can access the member.

default: Only code within the same package can access the member.

protected: Only code within the same package and code inside a subclass can access the member, but when from a subclass, you can't access the inherited member through a reference of the superclass.

public: The member is accessible everywhere. Since Java 9, modules only have access to public members in other modules if the dependency module exports the member.

[Ganesh Patekar]

Stephan van Hulst wrote:An overview:
private: Only code within the same source file can access the member.

I don't think so since a source file (a .java file) can have code of another class which doesn't have access to the private member of another class defined in the same source file.
Test.java (a source file)

class Time {
	Time() {
		Test t = new Test();
		System.out.println(t.testNo); //CE not visible 
	}
}

public class Test {

	private int testNo = 1;
}

Rather I would say private members are directly accessed only within the class they are declared in.

[Stephan van Hulst]

My apologies, I had considered this scenario, but I was strongly convinced that you could actually access the private members of top-level classes declared within the same file.

Ganesh Patekar wrote:Rather I would say private members are directly accessed only within the class they are declared in.

This is also not correct. A nested class can access private members of an enclosing class, and an enclosing class can access private members of a nested class.

I guess the correct way to describe private access would be: Only code within the declaring class, or code within enclosing or nested classes of the declaring class can access the private member.

[Campbell Ritchie]

Let's see what the JLS has to say:-

That JLS section, example 6.6.5 wrote:A private class member or constructor is accessible only within the body of the top level class (§7.6) that encloses the declaration of the member or constructor. It is not inherited by subclasses.

[Stephan van Hulst]

That leaves up to interpretation what is included in the body of the top level class. I'm pretty sure that includes the bodies of nested classes though.

[Liutauras Vilda]

Stephan van Hulst wrote:I'm pretty sure that includes the bodies of nested classes though.

Indeed. Everything what is in between of {...} of the top level class.

[Liutauras Vilda]

Well, now that I think more, except static nested classes.

[Piet Souris]

A simple example:

public class JavaRanch13 {

    /**
     * @param args the command line arguments
     */
    
    private int i = 5;
    private static int j = 5;
    public static void main(String[] args) {
//        StringBuilder sb = new StringBuilder("abcde");
//        System.out.println("position of d = " + sb.indexOf("d"));
    }
    
    static class A {
        private static int a;
        private int b;
        A() {
            a = i;   //  error
            b = j;   //  okay
        }
    }
    
    class B {
        private int b;
        B() {
            b = i;   // okay;
        }
    }

}

[Campbell Ritchie]

Liutauras Vilda wrote:. . . except static nested classes.

The variables are visible within a static nested class, but not accessible because of another rule that code in a static context cannot access instance members. Try it and see what sort of compiler error message you get.

[Liutauras Vilda]

We have broaden discussion boundaries slightly from the original. Actually we were talking about members. Since static aren't members, I'm not sure why I've mentioned them and shot myself to a foot.

[Ganesh Patekar]

Stephan van Hulst wrote:an enclosing class can access private members of a nested class.

Agreed I was wrong. I didn't think of private members declared in inner class.

[Liutauras Vilda]

Ganesh Patekar wrote:

Stephan van Hulst wrote:an enclosing class can access private members of a nested class.

Agreed I was wrong. I didn't think of private members declared in inner class.

I'm unsure about the wording.

I think nested inner class can access enclosing classes private members, not other way round. But I might misunderstanding the wording.

[Ganesh Patekar]

Liutauras Vilda wrote:I think nested inner class can access enclosing classes private members

Yes  

not other way round.

No, enclosing class can access private members of inner class.

Also private member of inner class is accessible in another inner class (of same enclosing class) which is already stated in Campbell's JLS quote.
Here is an example

public class Test {

	private int testNo = 1;

	/*
	 * inner class's private member in enclosing class
	 */
	private int x = new inner().innAge;

	class inner {
		private int innAge = 20;

		/*
		 * Enclosing class's private member in inner class
		 */

		{
			System.out.println(testNo);//
		}
	}

	class inner2 {
		/*
		 * inner class's private member in another inner class
		 */
		private int innAge1 = new inner().innAge;

	}

	public static void main(String[] args) {
		
	}
}

But I might misunderstanding the wording.

Yes It is all about wording that's why hats off to those who document JLS.

[Stephan van Hulst]

Enclosing classes may access private members of nested classes and vice versa. That's because all code within the body of a top-level class (including nested classes) may access private members declared anywhere within that same body (including other nested classes).

A great advantage of this is that you can declare nested classes that only expose certain properties to the outside world, and have the enclosing class manipulate their internals as needed. Otherwise the only advantage of having static nested classes at all would be namespacing.

[edit]

Ganesh beat me to the punch.

[Campbell Ritchie]

You can probably even have multiple nested and inner classes which are subtypes of one another or of their enclosing type, allow instantiation only via factory methods, and still return immutable objects. Usually non‑final classes cannot be made immutable, but you can exercise much tighter control of the behaviour of private inner/nested classes.

[Liutauras Vilda]

Thanks all. I don't think I used this stuff much if at all, so got introduced to some new concepts.

[kevin Abel]

Carey
Campbell
Stephan
Ganesh
Liytauras
Piet   and anyone else I missed.  I appreciate you input and discussion.

I did't mean to open a mess here.  I wasn't sure what the modifiers are.  Since I'm new I think I will stick with Public and Private.
I'm using java to work with Selenium.  I probably wont need the other two modifiers for a while.

I am working on an exercise where I need to call a method in the class of another package.  I'm going to start a new topic.

Thanks,

Kevin

[Stephan van Hulst]

Actually, I would press you to learn default access as soon as possible. There's a good reason this access level is the default. If you need to use a member of your class outside your class, give it default access.

People get into a bad habit of making all of their non-private members public. Don't do this, only use public when you really need to.

[Jesse Silverman]

I really needed this thread!

I had read about Inner Classes and Static Inner Classes in 3 or 4 different books, and watched several videos and read a few reference sources on the Web (I had not tried to consult the JLS on this topic).

I knew from one of the classic old SCJP books I read (back when they kept urging people to consult the JLS regularly!), which made clear that when it comes to static nested classes, the enclosing class can access everything including the private static contents of all static classes contained in it, and, in fact, all of the static nested classes can see the private static contents of all the other static nested classes defined in the same outer class, as well as those of the outer class containing them.

I was proud of remembering this, because most presentations never mention this anywhere, and it seemed to be beyond the scope of most incarnations of the OCJP that have existed, or at least beyond the scope of most of the preparatory materials for them.  I was also slightly embarrassed to remember this due to the same reasons -- there are a lot of relatively basic facts I am still shaky on, this seemed to border on trivia due to being mentioned so rarely.

Still, even today, I kept having the same recurring misconception that Liutauras did when this thread was new, regarding Outer class access to private members of member inner classes, namely that the Inner classes have access to all the private members of the containing Outer class, but not vice versa -- not true in Java!

I have coded a lot in the past in C++ (much less recently) and a fair amount in C#.  I am not sure where this misconception was coming from, but probably one of those.

I know from seeing presentations from the Gods of Java at Java One or Devoxx etc. that inner classes are believed to be one of the most poorly understood parts of Java, I have seen them state that a majority of professional mostly-Java programmers forget various rules about who can do what where.  I have worked with programmers who mostly avoid inner classes because they remember there are things they don't understand well about their use...

I feel like I am no longer going to be surprised by this again in Java, tho I will write C++ or C# code in the future that won't compile -- I can't remember which.

This thread went far beyond the requirements of the original poster, who was seriously confused about some basics at the time, but contained some pretty advanced facts that I kept getting wrong in the past.

Careful reading of the Scott and Jeanne book still left that "Inner can see Outer but not vice versa" nonsense in my head, but their mock exam questions caught it, and had me both writing example programs to clarify it and coming to this excellent thread.

I think my take-home is to "Trust the Force" of the Search here on the Ranch.  I have learned so much from topics that come up in results of carefully crafted searches that looked less than promising from the thread name.  Often more than from tutorial materials that I consider better-than-average quality.

I am also struck by the overlap of "Very Friendly to Confused Beginners" and "Serious Depth of Knowledge" that is manifested here.  It is hard enough to find either alone, but in combination, rarer than Hen's Teeth.

Almost 3-year-belated thanks to all the contributors to this hidden nugget of wisdom.

[Campbell Ritchie]

Don't call static classes “inner”. Reserve that term for instance classes.