[switch] Status of implementation of switch expression
Brian Goetz
brian.goetz at oracle.com
Tue Feb 27 21:30:21 UTC 2018
> On 27.2.2018 21:24, Brian Goetz wrote:
>>
>>> -enhanced exhaustiveness check for enums (if all existing constants
>>> are covered, the "default" clause may be omitted, and javac will
>>> generate it automatically. The automatically generated one will throw
>>> an exception, although the form of the exception may need some
>>> improvements). This is for switch expressions only.
>>
>> What is the form of the exception currently?
>
> Only:
> throw new IncompatibleClassChangeError();
Heh, that could be improved :)
I think reusing ICCE here is a little strong; its not that an
incompatible change was made, but instead that the client is asserting
that "these are all the enums there are", and the assertion is failing.
So one possibility is:
throw new AssertionError(String.format("Unexpected enum constant
%s.%s found"), enumClass.canonicalName(), enumConstant);
(Some have questioned whether inserting the throwing default
automatically is wise, but I like the fact that it amounts to an
assertion that "these are all the enum constants in type E", and getting
an exception when that assumption is seen to be violated.)
However, some may not like the user of AssertionError; perhaps we need
to invent a new exception type. Bikeshed away....
>
> I incline to dropping the changes to the non-indy translation (keeping
> only the translations needed for the old --target values) and rely on
> the indy translation for most of the new features.
Yes. The old translation is really only needed for bootstrapping
purposes (where classes that are loaded very early in java.base need to
use switch on strings, and it's too early to load the indy runtime.)
There should be a small number of these in java.base only, and java.base
code already accepts restrictions aimed at avoiding bootstrap cycles.
No one else should have to worry about this.
More information about the amber-dev
mailing list