harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nbe...@kc.rr.com
Subject Re: JVM spec interpretation questions
Date Wed, 28 Dec 2005 07:10:40 GMT
In regards to question one, from my understanding, all it's stating is
that an array, of any type, can be cast/referred to as a
java.lang.Object and it implements the Cloneable and Serializable
interfaces. The item type of the array has no effect, at least in
regards to cloning and serialization. So, in relation to your example,
it doesn't matter if the class is X or Y or any class.

The following snippets should valid:

class X {}

X[] xArr = new X[]{new X(), new X()};

assert (xArr instanceof Object);
assert (xArr instanceof Cloneable);
assert (xArr instanceof Serializable);

Object obj = xArr.clone();
X[] xArrClone = (X[])obj;

assert (xArr[0] == xArrClone[0]);
assert (xArr[1] == xArrClone[1]);

You should be able to substitute "X" for any class and any primitive type.

That's how I understand it at least.

BTW: Shouldn't we be checking out the 3rd edition of the language
specification? I've been assuming we're trying to build a Java 5 runtime.


----- Original Message -----
From: "bootjvm@earthlink.net" <bootjvm@earthlink.net>
Date: Tuesday, December 27, 2005 8:32 pm
Subject: JVM spec interpretation questions

> 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 
> everythingfrom 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
>    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

View raw message