Sanjeev Ba

String is categorized under "Reference types and values" in the spec.
https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.3.3

It is definitely not a primitive.

Stumbled on this one in stackoverflow.

http://stackoverflow.com/questions/10756241/what-does-final-do-in-java-hard-version

The reason for this restriction [Local classes can only reference local variables and parameters that are declared final.] becomes apparent if we shed some light on how local classes are implemented. An anonymous local class can use local variables because the compiler automatically gives the class a private instance field to hold a copy of each local variable the class uses. The compiler also adds hidden parameters to each constructor to initialize these automatically created private fields. Thus, a local class does not actually access local variables, but merely its own private copies of them. The only way this can work correctly is if the local variables are declared final, so that they are guaranteed not to change. With this guarantee in place, the local class is assured that its internal copies of the variables accurately reflect the actual local variables.

Greg
Thank you for the quick reply.
If the JVM is going to make copies of vars (presumably in a compiler generated constructor of the method local inner class), why not copy the non-final local variables of the method as well.

Hello Ranchers,

Why can method local inner classes access only the local method variables declared final?
What happens to the final variables when the method returns but the reference of the method local inner class remains in heap?

Kindly clarify.

abstract class Maker{ String member; Maker(String s){ member = s; System.out.println("Assigned in abstract class"); } } public class Constructor extends Maker{ public static void main(String[] args) { Constructor c = new Constructor("test"); } Constructor(String s) { super(s); System.out.println(member); } protected Constructor(int i){ super("test"); } public Constructor(){ super("test"); } private Constructor(float f){ super("test"); } }

While the above code is legal and valid can someone tell me the point of allowing this sort of design i.e. allowing multiple constructors with different access permissions for making one type of object.

Is it fair to say exceptions and return values have similar rules while overriding methods in subclasses?
(excluding runtime exceptions and freedom not to return exception)

They can return either the class type or the subclass type as return values/exception type.
Cannot return super class type as return value / exception type.
Cannot return new exception / return type.

There is much similarity here.

More reasons why I should have a copy of the JLS handy at all times . Thanks.

You might also want to consider Mikhalai Zaikin's study material and RMH book.
Not sure if RMH has been updated recently though.

Turns out I can.

package test; abstract class Abs{ abstract void nativeMethod(); } public class AbstractNative extends Abs{ native void nativeMethod(); public static void main(String[] args) { } }

I read that Clojure is targetted at the JVM.
Is there any plan to port it on the Dalvik VM?

A native method has its implementation done in a native language, typically a ".so" and gets called via JNI.
Abstract method is as the name suggests - without a concrete implementation and leaves it to the first non-abstract subclass to implement its method.

I see your point that one is specific to implementation and the other is specifying a lack of implementation.

In this case, how do I specify an abstract method which I want to enforce to be implemented in native code?

Can a subclass of an abstract class add the native specifier to the abstract method of the parent abstract class.

I tried to create an abstract class with a native abstract method?
Why isn't this permitted?

Henry,

In the example posted by Henry, class C belongs to a different package (pkg C) than class B.
So, protected member "i" of class B can be accessed in class C only via inheritance and therefore "b.i" will not compile, because it is accessing using instance var.

I think the question is, what is "THAT OBJECT". From the context it looks like "THAT OBJECT" is B.
But, "The code responsible for the implementation of that object" is class C.

But when in class C, we do

C c = new C();
System.out.print(c.i);

we are accessing the inherited member which really means C has a member "i" due to inheritance, which stated otherwise is "Code that is responsible for the implementation of that object.

Ok, that answers my question. Thanks to both Henry and Pritish for your discussions.

I have learnt two important concepts.

1. Access level does not change upon inheritance.
2. A protected member or constructor of an object may be accessed from outside the package in which it is declared only by code that is responsible for the implementation of that object.

I think Henry summarized it beautifully in the last post.

Thanks for your contributions guys.

Yes, I am going through the same section.
While I understood the points you have explained, my question is about the access level of the protected members for classes which are subclasses of the subclass which inherits the members via the protected access specifier from the parent in a different package.

Example

package A;

class A{
protected int i;
}
-----------------------
package B;
import A.*;

class B extends A{
//inherits i; - but what is its access level ? - protected ?
}

-------------
package C;

import B;

class C extends B{
// is "i" accessible here.
}

------------------