[Classpath] Re: Informative throws

[Eric Blake]

> >
> > > 2) I think that if statement adds some bytecodes. As you end up with
path
> > > for message exception anyway, you just add something around 10-15
bytes
> > > for nothing.
> >
> > the compiler should optimize these bytecodes away if the ./configure
> > option is not given.  so this is not a valid objection either -- unless
> > someone can show that the compiler does *not* in fact do this
> > optimization?
>
>  Ok, you are right here - it seems that final booleans are inlined. This
> seems quite bad for me (as java is suppose to resolve things at runtime
> not at compile time), but it is like you say - compiler optimizes out the
> dead code at compile time. So proposal is valid as far as technical
> reasons are concerned - now it is a question of readibility and maintance.
>
> Artur

The JLS (particularly chapter 13) requires that all compile-time constants
be inlined, rather than resolved at runtime.  The definition of compile-time
constant is found in JLS 15.28.  Read the examples in JLS 13.4.8 for
clarification, and Sun's reasoning on defining the language in this way.  In
short, if you change the value of a compile-time constant in one class, you
MUST recompile other classes for that change to propagate (hence, the reason
jikes has a +U option to do full dependency checks, rather than relying on
classfile timestamps alone).

As for readability/maintainence, Tom's idea of pre-processing sources to
remove arguments is a nice thought, but what about cases where the argument
is multiline, or includes method calls? Pre-processing might be error-prone.
(I don't know if this example is actaully in Classpath, but it demonstrates
my point):

throw new AbstractMethodError(method.getName() + " is abstract in " +
                              clazz.getName());
--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
address@hidden   tel:+44(0)117 917 5611