aspose file tools*
The moose likes Beginning Java and the fly likes what linking mechanism uses java (early or late) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "what linking mechanism uses java (early or late)" Watch "what linking mechanism uses java (early or late)" New topic
Author

what linking mechanism uses java (early or late)

Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
question rises because of this code:



so it looks like variable type matters. But I always thought that java uses early linking, so matters only actual type. Java version 1.6

[ June 29, 2008: Message edited by: Gasan Gouseinov ]

[ June 29, 2008: Message edited by: Gasan Gouseinov ]
[edit]Add code tags. CR[/edit]
[ June 29, 2008: Message edited by: Campbell Ritchie ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39884
    
  28
More of a beginner's question.

What is wrong with the code? It compiled when I tried it.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39884
    
  28
I think (not quite sure):

Static linking (better term than early linking) for static members.
Dynamic linking (better term than late linking) for instance members.

Can you not get that code to compile? It worked for me, but I deleted the package declarations.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39884
    
  28
Probably better still to say compile-time and run-time linking.

But Java definitely doesn't simply use "early" linking.
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
I'm using java 1.6 and eclipse ganymed. It says on line that I marked as illegal AClass.var is not visible. Package should be different. So parent and child are in different ones.
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
so, if I clearly understood. Java uses actual object type rather than formal parameter type for resolving non-static fields and methods and uses uses formal type for static ones. The problem is that in beforementioned code it matters what is the formal parameter type, what looks strange.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39884
    
  28
Originally posted by Gasan Gouseinov:
so, if I clearly understood. Java uses actual object type rather than formal parameter type for resolving non-static fields and methods and uses uses formal type for static ones.
Yes, you are correct about that.

I tried compiling with the package declarations and got a compiler error similar to yours. I can only presume it is because the static main method doesn't actually override a method in the superclass that the protected variable is not "visible."

Anybody else got any ideas?
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
It says on line that I marked as illegal AClass.var is not visible. Package should be different. So parent and child are in different ones.
Your two packages are different: my.test and my.test3 are separate packages. Since the variables are both protected, only classes in the same package (i.e. in my.test) and, for your instance variable 'var', code within classes which inherit from it can see them. Hence the fact that both aren't visible inside your static method residing in a different package.

Remember instance methods are subject to polymorphism - so you can override methods in subclasses. That means you can do something like:Now it would be very common to have an object of type Volunteer but, without further testing, only know that it's of type Employee. So you might end up writing:Under polymorphism, you need this last line to print the value 0.0 - otherwise you can have a Volunteer instance which is giving you something other than 0.0 as a salary, a grave mistake! You see, if overriding a method in a subclass didn't have this effect, then polymorphism just wouldn't work as you'd constantly be testing subclass types all the time and having to cast, which would ruin all the benefits of OO programming!

But static methods cannot be overridden as they exist on one class only. Hence the difference in visibility of static and instance variables between packages, and the way in which class type is determined for each (polymorphism doesn't apply to static methods, so they use the declared class type rather than the actual one).

By the way, you have two lines which are identical but apparently give different behaviour - did you mean this?Hope that makes sense - I'm tired


Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
I can only presume it is because the static main method doesn't actually override a method in the superclass that the protected variable is not "visible."
Well you're right in that the static method doesn't inherit from the superclass, and therefore isn't subject to the normal inheritance conditions on the protected variables. Of course, overriding is a sufficient but not necessary condition for protected variables to be visible inside the method: you could create a new instance method on DClass which would then have access to the protected variables from AClass.

All that is special about static methods is they can access all visibilities of the class in which they reside only, protected and default visibility both from those in the same package, public from everywhere. That means if you declare a private instance variable in DClass, the static main method can view it (on any instance), while a private instance variable in AClass would be hidden from the static main method. In this case, inheritance says that var is a member of DClass as well as AClass. However, it's protected so only accessible to the static method when accessed on classes in the same package. Since the AClass instance isn't in the same package, that line fails. But DClass is in the same package, and "inherits" (see next paragraph) 'var', so the static method does have visibility on it and can access it.

The reason this gets very confusing quickly is because variables work slightly differently to methods. You can't override or inherit instance variables in the same way as instance methods, you just declare replacements ("shadowing") in subclasses. However, a class also "inherits" any variables from the superclass for which it has visibility (i.e. all variables other than private and possibly package-private). So this can lead to some confusion. In particular: it is the actual object type used to invoke instance methods but the declared variable type used to reference instance variables. Since by shadowing these may be different on each class in the hierarchy, and we have no way to know which actual instance a variable refers to, the interpreter's only option is to refer to the variables on the declared type directly - these may be "inherited" or shadow variables. Hence the discrepancy in what you're seeing: if you repeat this with accessor methods, you'll find it does what you expect because they inherit following straightforward rules.

It makes sense to me, but I might not be expressing myself well enough. I'm sure there's a line/paragraph/chapter in the Java Language Specification to explain this formally. Feel free to ask for clarification.
[ June 29, 2008: Message edited by: Charles Lyons ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39884
    
  28
That sounds like what I thought, and yes you have expressed it better than I could, Charles. Thank you.
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
Thanks. Need a couple of time to understand the answers.
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
we have no way to know which actual instance a variable refers to


Is this because of java uses for purposes of virtual function table doesn't keep information about what actual type are fields related with, but only keeps this information for methods?

the interpreter's only option is to refer to the variables on the declared type directly


I'm not good understand what you mean by interpreter - is it in compile time or in runtime in jvm (does the interpreter makes bytecode and replaces all invocations of fields with references to the formal type variables or I'm not clearly understand what variable is and how it represented in bytecode, sorry)
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
Is this because of java uses for purposes of virtual function table doesn't keep information about what actual type are fields related with, but only keeps this information for methods?
Well if it will help to look at it from the C++ perspective, then yes, all methods in Java are implicitly virtual while all variables (as in C++) cannot be marked virtual. Hence the method on the actual object is invoked while it is the variables on the declared type which are accessed. This is the same as C++ when using all virtual methods.
I'm not good understand what you mean by interpreter - is it in compile time or in runtime in jvm
The interpreter is the platform-dependent program which, at runtime, translates Java bytecode (.class files) into native machine instructions so the program can execute. Most JREs then use a Just In Time (JIT) native compiler so the code executes at near, and sometimes better than, native speeds. The Sun JRE distributes with the HotSpot JVM, featuring an interpreter and JIT compiler.

You're right that it's a somewhat clearer picture in C++ because you can have non-virtual methods which do the same things as variables, so everything seems consistent. Then add virtual functionality as an afterthought and it still seems consistent.

Does that clear it up for you?
Gasan Guseynov
Ranch Hand

Joined: Jan 03, 2006
Posts: 67
Many thanks for useful answer.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: what linking mechanism uses java (early or late)