File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Some abstract methods from standard API: how to find where implemented? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Some abstract methods from standard API: how to find where implemented?" Watch "Some abstract methods from standard API: how to find where implemented?" New topic
Author

Some abstract methods from standard API: how to find where implemented?

Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
Hi,
let's see the snippet below from http://java.sun.com/docs/books/tutorial/essential/io/dirs.html



at the line #4, we have the method newDirectoryStream() from class Path in jdk7, i put the codes in an example to check ...
that works fine, as any other such method does.

But it's an abstract method, i looked into its source and nothing (as it should be). but it actually does something, i want to know where the code of operations implemented? (consider this method just as an example, i know there are other methods like this one in the API)

Thanks in advance


I'm really tired of being engaged with stuff other than Java and programming

Wish to get back soon to my love...
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

With getClass() you can find out the actual class. Class.getSuperclass can then be used to get the entire list of (indirect) super classes. Check these classes for the implementation. This may not be possible; if the class is a Sun private one (the package starts with com.sun, sun or sunw) then you may be able to get the source by getting the JVM source code but otherwise it's just not publicly available.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
Thank you, that was exactly as you mentioned...(the class was sun.nio.fs.WindowsDirectoryStream)

But how it redirects to this class, i mean for example in some superclasses of I/O API, there are abstract methods that implemented by subclasses (or usually the documentation hint with specified by...), or i can ask this way:
how it decied what class to implement that method? it's not just clear...i hope you get what i am trying to find out
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Path.newDirectoryStream() returns an implementation.
Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
David Newton wrote:Path.newDirectoryStream() returns an implementation.

How? from where? Shouldn't an abstract method have been specified/implemented somewhere!?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36464
    
  15
Find the Path class and read its code. Find the Stream returned from that method, and use its getClass() method, then go through and find things like name using the methods of the Class<T> class.

That might help.
kunu patil
Greenhorn

Joined: Sep 24, 2007
Posts: 20
Esmaeil Ashrafi wrote:
David Newton wrote:Path.newDirectoryStream() returns an implementation.

How? from where? Shouldn't an abstract method have been specified/implemented somewhere!?


Hi

I think, as it seems, WindowsDirectoryStream is in sun.nio.fs; implementation of newDirectoryStream() method may be underlying OS specific. JVM knows about underlying OS and figures out that which implementation should be used for abstract method.

Could you try getClass() and Class.getSuperclass methods and run this program on Unix/Linux and see what it returns?

Please correct me if I am wrong.
Thanks.

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Esmaeil Ashrafi wrote:
David Newton wrote:Path.newDirectoryStream() returns an implementation.

How? from where? Shouldn't an abstract method have been specified/implemented somewhere!?

It *is* implemented, in the implementation returned by method.
Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
@ Campbell Ritchie
I did it before, and again did that as you suggested:
this method returns an interface (DirectoryStream<Path>), i did the following snippet:

an got the following output:


So, i don't know how to deal with these informations to figure out what i'm trying to!

@ kunu patil
It's of course OS specific and without trying i can say for UIX/Linux that will be a different class implements that.But how JVM knows!?...please follow to the last of this post to figure out what I'm trying to see

@ David Newton
Of course it *is* implemented...


Gentlemen,
Actually i don't care about the implementation or details of implementations performed by implementer class!
what I'm confusing about, is the procedure that JVM uses when encounters to such this abstract methods
And to make it more clear, i try to give you a semantic view by the following snippet:


Then the tester class, where JVM automatically jumps from encrypt to suitable encode (i think...)


Obviously there is some mechanism to call expected class to implement the encode method from encrypt method, it is somehow more simple than that i firstly illustrated
How could it (Path.newDirectoryStream() for instance) be explained upon this example

Sincerely
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36464
    
  15
Esmaeil Ashrafi wrote:[b]@ Campbell Ritchie
. . . i did the following snippet: . . . an got the following output:
Which is your answer. Whether you can find out any more, I don't know. Note that a sun. package may be changed in future releases.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

Esmaeil Ashrafi wrote:It's of course OS specific and without trying i can say for UIX/Linux that will be a different class implements that.But how JVM knows!?...

It depends. First of all, the JVM knows the OS. Just check System.getProperty("os.name"). Now there could be two ways that the abstract class is determined:
- check some system property. This is for instance done in javax.swing.filechooser.FileSystemView; if the file separator is \ it will return a WindowsFileSystemView instance, if it is / it will return a UnixFileSystemView instance, and otherwise it will use a GenericFileSystemView instance. java.awt.Toolkit does it using reflection based on the "awt.toolkit" property.

- hard code it. An example is used in java.io.File. This uses package-private class java.io.FileSystem. This has a native method to return the FileSystem instance to use. In the src.zip I found in my Windows JDK there are package-private classes java.io.Win32FileSystem and java.io.WinNTFileSystem that both extend java.io.FileSystem. I assume that in the src.zip found in Linux JDK there would be a class java.io.UnixFileSystem. The native method probably just returns an instance of one of those classes; the class is hard coded into the JVM which is OK because the Linux JVM is naturally different from the Windows JVM.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

Rob Prime wrote:I assume that in the src.zip found in Linux JDK there would be a class java.io.UnixFileSystem.

Guess what? I just installed Sun's Java 6 JDK and checked the src.zip file, and indeed there is a file with exactly that name.
Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
Thanks Rob, it is now much more clear to me;

Could following interpretation be right?
in my example,Cipher (the abstract class) is made from one of its subclasses, so when this instance calls the encrypt method (defined in superclass) that calls method encode (the abstract in superclass), firstly looking for method implementation in the instance (subclass) make sense to JVM

And about standard API, when JVM sees no implementation (for example for DirectoryStream<Path>) in my class or package, follows the ways you explained. If so, it seems somehow confusing to understand, it should be predefined in JVM, i think! that is call to newDirectoryStream() cause JVM to call specified class Hard-Coded into JVM...

I also uncompressed the file rt.jar in the lib directory of private JRE folder in jdk7 and found those classes...

Rob Prime wrote:...
...The native method probably just returns an instance of one of those classes; the class is hard coded into the JVM which is OK because the Linux JVM is naturally different from the Windows JVM.


what that means (phrase in bold) ?

Sincerely yours
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

Esmaeil Ashrafi wrote:Could following interpretation be right?
in my example,Cipher (the abstract class) is made from one of its subclasses, so when this instance calls the encrypt method (defined in superclass) that calls method encode (the abstract in superclass), firstly looking for method implementation in the instance (subclass) make sense to JVM

Right. Every method call will look for the definition as low in the hierarchy as possible - in the actual class if possible, otherwise it checks the super class until the implementation is found. This also happens if the method is called from a super class as you described.

And about standard API, when JVM sees no implementation (for example for DirectoryStream<Path>) in my class or package, follows the ways you explained. If so, it seems somehow confusing to understand, it should be predefined in JVM, i think! that is call to newDirectoryStream() cause JVM to call specified class Hard-Coded into JVM...

The thing is, a lot of this information is explicitly hidden, because you don't need the details. Just like every Iterator returned by an iterator() method (e.g. List, Collection) is of some undefined class, all you need to know is that it implements Iterator and you can call its methods. Likewise, all you need to know is that newDirectoryStream() returns a DirectoryStream<Path>. That's enough knowledge to use the returned object as it was intended. The details are, as far as Sun is concerned, irrelevant. That the object is an instance of sun.nio.fs.WindowsDirectoryStream under Windows and perhaps sun.nio.fs.UnixDirectoryStream under Linux does not matter at all; both implement the same interface, and those methods are all you'll need.

Let's just see it as a case of "need to know basis".

Rob Prime wrote:...
...The native method probably just returns an instance of one of those classes; the class is hard coded into the JVM which is OK because the Linux JVM is naturally different from the Windows JVM.


what that means (phrase in bold) ?

That the name of the class may be hard coded in the source code of the JVM. Somewhere in the Linux source code it may say whereas in the Windows source code it may say (those are equivalent to Java's "public static final String DIRECTORY_STREAM_CLASS = ..."). I haven't ever read any JVM source code so I can't tell for certain but it's quite possible.
Esmaeil Ashrafi
Ranch Hand

Joined: Feb 22, 2010
Posts: 73
Uuuumm, i can say as a Java nerd, i've got good information to extends my knowledge about Java!

Thank you very much
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

You're welcome.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Some abstract methods from standard API: how to find where implemented?
 
Similar Threads
overriding abstract method
Serialization !!!!!!!!!!!!! Help me out
Abstract definition & Interface
My Study Notes !!!
transient variable ? is there any other way