harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bootjvm@earthlink.net" <boot...@earthlink.net>
Subject JVM spec interpretation questions
Date Wed, 28 Dec 2005 02:32:41 GMT


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

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?

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

    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

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

View raw message