harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: JVM spec interpretation questions
Date Wed, 28 Dec 2005 13:04:26 GMT
On 12/28/05, bootjvm@earthlink.net <bootjvm@earthlink.net> wrote:
> All,
> For you gurus out there, I have some questions about
> interpretation of the JVM 2.0 spec.  I am trying to clarify
> certain operational details of array and exception handling.
> I would appreciate the collective wisdom of you lurkers out
> there on The List who know about these things.  Thanks in
> advance for your advice:
> Question 1:
> -------------
> JVM 2.0 spec, section 2.15 states:
>     Arrays are objects, are dynamically created, and may
>     be assigned to variables of type Object (ยง2.4.7). All
>     methods on arrays are inherited from class Object
>     except the clone method, which arrays override. All
>     arrays implement the interfaces Cloneable and
>     java.io.Serializable.
> Based on my experience, I find two possible interpretations
> of this statement.  Using an example,
>     public class X {};
>     public class Y extends X {};
>     methodZ() { Y yArray[3]; }
> Does this mean that,
> (A) Array objects of type Y (such as yArray[3]) will inherit everything
> from X, which in turn inherits from java.lang.Object?  And does
> Y need to implement a 'Y.clone()' method, or perhaps is an 'X.clone()'
> method applicable or appropriate?
> (B) Or does this mean that Y effectively inherits directly and ONLY
> from java.lang.Object, and must also implement a 'Y.clone()'
> method?  Or possibly skip 'Y.clone()' if it never intended to be
> used by the code?
> I am debating back and forth as to which was is correct.  Is
> it (A) or (B) or something else?  What have I missed here?

Arrays are classes that implement both Serializable and Clonable,
single as that. The inherintance tree for arrays mimics of the
component types. Take ArrayList as an example:

ArrayList extends AbstractList > AbstractCollection > Object.
ArrayList implements List, RandomAccess, Cloneable and Serializable.

This  means:

ArrayList[] instanceof AbstractList[]
AbstractList[] instanceof AbstractCollection[]
AbstractCollection[] instanceof Object[]

ArrayList[] instanceof List[]
ArrayList[] instanceof RandomAccess[]
ArrayList[] instanceof Cloneable[]
ArrayList[] instanceof Serializable[]

And this is why there is the ArrayStoreException:

Collection[] col = new ArrayList[1];
col[0] = new HashSet(); //throws ArrayStoreException

> Question 2:
> -------------
> JVM 2.0 spec, section 2.16 states:
>     Every exception is represented by an instance of the class
>     Throwable or one of its subclasses; such an object can be
>     used to carry information from the point at which an exception
>     occurs to the handler that catches it....
> JVM 2.0 spec, section 2.16.4 states:
>     The class Exception is the superclass of all the standard
>     exceptions that ordinary programs may wish to recover
>     from....
>     The class Error and its standard subclasses are exceptions
>     from which ordinary programs are not ordinarily expected
>     to recover. The class Error is a separate subclass of Throwable,
>     distinct from Exception in the class hierarchy, in order to allow
>     programs to use the idiom
>         } catch (Exception e) {
>     to catch all exceptions from which recovery may be possible
>     without catching errors from which recovery is typically not
>     possible.
> Seeing as any Java program can throw a java.lang.Throwable or
> a subclass, in addition to its subclasses java.lang.Exception and
> java.lang.Error, I need some clarification of the spec.  An 'Exception'
> is something that a program should recover from, that is, once it
> is finished processing, the program should continue with its 'finally()'
> clause, if any, and carry on.  On the other hand, an 'Error' is something
> where 'ordinary programs are not ordinarily expected to recover' from
> and which the handler is typically not defined in the application.
> I have some questions here:
>     (A)  If an 'Error' is caught by an application handler and does not
>     exit() the program or some other drastic action, I presume that
>     the application just keeps running.  But if it is not caught, meaning
>     that none of the methods in the stack have a handler, then it must
>     be handled by the handler provided by the JVM.  At this point, does
>     the thread quit, just like an 'Exception' does, or should the JVM
>     shut down completely?
>     (B)  In the API spec 1.5.0, there are only two known direct subclasses
>     of java.lang.Throwable.  Is there any reason at all to EVER expect an
>     application to define some class that is a direct subclass of java.lang.Throwable
>     that is, not also a subclass of 'Exception' or 'Error'?  If so, then I have two more
>     questions, which seems to also arise in java.lang.Object anyway:
>     (C)  What about a 'Throwable' that is neither an 'Exception' or an
>     'Error'?  This situation arises in 'java.lang.Object.finalize() throws Throwable
>     How is this handled?  From the following statements in the API doc:
>         If an uncaught exception is thrown by the finalize method, the
>         exception is ignored and finalization of that object terminates....
>         Any exception thrown by the finalize method causes the finalization
>         of this object to be halted, but is otherwise ignored.
>     I understand the functionality to mean that if ANY Throwable of any
>     kind occurs during finalize() for which a handler is not provided by
>     the program in some way, then that is the end of all work in this method.
>     End of subroutine.  Period.  Is there ANY other possible interpretation?
>     (D)  I presume the generalize approach for any direct 'Throwable' is the
>     same as for an 'Exception', but does it do like an 'Error', which is presumed
>     not recoverable, or is it completely user defined?  On the face of it, it looks
>     to me like it is just another handler and that once it finishes, any finally()
>     block will run and the thread continues.  Is this correct?
> Thanks much for your time and your wisdom,
> Dan Lydick

The JVM should handle exception in an uniform way, no special
treatment for Error, Thowable or any other. The exception are static
initializers, as Jeroen noted. Other than that the rule is simple:
when an exception is thrown unwind the stack until you find a handler,
otherwise pass it to the proper handler and finish the Thread. A JVM
only dies if no daemon thread is active.


View raw message