[213] in java-interest
Re: goto and switch
daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Wed Jun 7 13:49:49 1995
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
To: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Thu, 8 Jun 1995 03:12:05 +1000 (EST)
Cc: java-interest@java.Eng.Sun.COM
In-Reply-To: <9506071535.AA22939@acorn.Eng.Sun.COM> from "Arthur van Hoff" at Jun 7, 95 08:35:51 am
AVH:
> Jeremy:
> > Ah, OK. Are case statements only allowed in the block immediately
> > in the switch? What's the exact syntax? Something like:
> >[...]
> > The part of the spec about control flow is *very* brief. I think it could
> > do with some fleshing out (particularly the other uses of "break" in
> > catch and synchronized).
>
> Check out the language grammar in:
> http://java.sun.com/1.0alpha3/doc/javaspec_11.html
It doesn't really go into enough detail. It just says that case and
break statements are just statements, and are therefore allowed anywhere.
It doesn't talk about where a case is allowed in a switch block, and it
doesn't talk the meaning of "break" in any particular context.
> > My concern is that inlining the constants from
> > another class is effectively inlining part of the implementation which
> > could change between compile time and link time, and therefore
> > change the semantics without any obvious errors.
>
> Your concern is a valid concern. The avoid this somewhat the compiler
> automatically does dependency checks (it has a build in make). But you
> are right that the problems not go away completely.
Yes. The compiler has no control over what version of a class the
code it's currently compiling will eventually bind against, and
you might be compiling against a class which you have no source
for. This is probably a good reason to have enumerated types: the
compiler and class file just treat them as named values, but the
runtime can bind them to values and treat them as integers. The
problem goes away then, because the compiler's view is symbolic
all the way though, but the runtime is in the right place to turn
them into an efficient form.
> The bottom line is that, if you are really concerned about changing
> an interface in incompatible ways, then you should not use constants,
> use variables instead. We chose to inline constants for efficiency,
> this has the unfortunate side effect of making interfaces a little
> more brittle. However, it is not obvious whether the alternative would
> result in acceptable performance.
Because all the switches would become if-else trees? Or just
because there'd be lots of lookups instead of inline constants?
Surely if the compiler didn't inline another class's constants,
the runtime could when it saw a class access another class's member
which is final? Of course, to get the full effect the runtime
would have to do some local rewrites of the bytecode, but that
isn't very expensive.
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
