Strings in Switch

[Tom Ball]

On Wed, Dec 9, 2009 at 7:37 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

>
> On 9 Dec 2009, at 10:53, Reinier Zwitserloot wrote:
>
> > As I understand it, switch-in-strings is handled during the "lower" phase
> of
> > javac, which must desugar the string switch into legal java code.
>
> Hmm, that's not quite how I understand it.
>
> I picture the "lower" phase as a bridge between the side of javac which is
> concerned with the Java Language spec (parsing, flow analysis etc), and the
> side which deals with the VM spec (ie. bytecode generation).  Its existence
> means that neither side need be unnecessarily complicated by details of the
> other.
>
> So, its input is syntax trees which are valid as far as the language spec
> is concerned, and its output is a simpler set of trees which can be used by
> the "gen" phase to produce valid JVM classes - but that 'simpler' set is not
> necessarily an exact subset of the trees used by earlier phases; ie. the
> output need not be directly representable as valid Java *language* code
> (synthetics and some uses of "let" expressions for example).
>

That's exactly right.  It's common when drafting language change specs to
show the JVM output as simplified Java, but that's because the writer and
reviewers generally know Java much better than JVM byte-code and can thus
more easily spot mistakes.  It's never been a JVM requirement, however.

Josh and I ran into this with the ARM spec, where he was wrestling with what
sort of synthetic super type might be needed for some corner cases.  It
turns out that no new types were needed, as the previous compiler phases had
already verified the code was typesafe.  So all the code needed to do (from
the JVM requirements) was to directly use the resource variable, without it
needing to be recast or incur any risk of a runtime type exception.

Tom