You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "bootjvm@earthlink.net" <bo...@earthlink.net> on 2005/12/28 03:32:41 UTC
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 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
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
Re: JVM spec interpretation questions
Posted by Tim Ellison <t....@gmail.com>.
Of course, Rodrigo meant:
> A JVM only dies if no *non-daemon* thread is active.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: JVM spec interpretation questions
Posted by Rodrigo Kumpera <ku...@gmail.com>.
On 12/28/05, bootjvm@earthlink.net <bo...@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.
Rodrigo