[144] in java-interest
Re: Overriding and an extention
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Mon May 29 21:48:22 1995
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Mon, 29 May 1995 18:36:50 -0800 (PDT)
To: java-interest@java.Eng.Sun.COM
Hi Jeremy,
> 1. If I have the following:
>
> class A {
> abstract void a();
> }
>
> interface I {
> void a();
> }
>
> class B extends A implements I {
> void a() {}
> }
>
> Is class B considered to have implemented both the interface and the
> abstract method?
Yes.
> Is there a way of having separate implementations,
> so "B as an A" is different from "B as an I"?
No. Unlesss you are willing to use a naming convention. This is a good
point but it is hard to solve in general for virtual methods. We've found
that this is a corner case that hardly ever occurs in practice.
> 2. Though the spec doesn't mention it, javac seems to do something
> with "break" and "continue" statements in "synchronized" and "finally"
> blocks. Do they really do something special, and if so, what?
It releases the lock or it executes the finally if the break or continue
would exit the block.
> 3. An extention:
>
> Add an "assert(arg)" "operator" which evaluates arg as a boolean
> expression. If it's true, nothing happens. If not, and you compile
> the class debug mode, it will throw an exception which would
> generally not be caught. "abort()" could just throw the exception,
> but that doesn't seem necessary. This would allow pre and post
> condition checks similar to C's with a simple syntax (I noticed
> that a lot of the javac code has things like if(!exp) { throw new
> InternalError; }). The compiler could warn if there's any side-effects
> in "arg", since the assertion expression need not be executed.
>
> In addition, an assert() could be an optimisation hint to the
> runtime. For example, if you have:
>
> void x(int len, int[] a)
> {
> assert(len < a.length);
>
> for(int i = 0; i < len; i++)
> dosomething(a[i]);
> }
>
> If it's clever enough, the runtime could see the assertion, and
> therefore know that i is always going to be less than the array
> length, and need not generate bounds check code for each loop
> iteration. Perhaps this isn't the best example, since the runtime
> could do the same analysis with "for(int i = 0; i < a.length; i++)",
> but an assertion may make it cheaper. The analysis would have to
> be rigorous either way, but the assertion could say whether the
> runtime should bother or not.
But how do we know that the caller of x follows the convention
and makes sure that len is less than a.length? Somewhere we need
to check. You can't eliminate the boundary check at compile time because
the byte code verifier has to be able to come to the same conclusion
before it can accept the code as legal.
Have fun,
Arthur van Hoff (avh@eng.sun.com)
http://java.sun.com/people/avh/
Sun Microsystems Inc, M/S UPAL02-301,
100 Hamilton Avenue, Palo Alto CA 94301, USA
Tel: +1 415 473 7242, Fax: +1 415 473 7104
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
