Extend switch .. case statement for all types and simple expressions

Ulf Zibis Ulf.Zibis at gmx.de
Wed May 27 01:10:44 PDT 2009

Am 27.05.2009 09:15, Daniel Cheng schrieb:
> On Sun, May 24, 2009 at 11:31 PM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
>> Am 02.04.2009 11:34, Daniel Cheng schrieb:
>>> On Wed, Apr 1, 2009 at 5:17 PM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
>>>> I would like to add, that the MAJOR ADVANTAGE of my proposal is,
>>>> that the numerous grades/levels of this proposal could be implemented
>>>> step by step, depending on the complexity of changes, which could be
>>>> done for JDK 7.
>>>> More sophisticated grades/levels could be seamlessly added later.
>>>> This would be impossible, if the concurring syntax of "Strings in
>>>> switch", which only compares for equality, comes to account.
>>>> Also Multiple switch expressions and case ranges
>>>> <http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000213.html>
>>>> could seamlessly be integrated in my proposal.
>>>> As I argued more detailed before, default semantic of "switch..case"
>>>> should stay on determining the cases by IDENTITY.
>>>> Strings, which are equal, could simply be made identical by
>>>> String#intern().
>>> Except, using some combination of gc options, intern'ed String won't be
>>> gc'ed.
>> Literals are always intern'd, so the wouldn't gc'ed either.
> What if your "myStringFromElsewere" does not matches anything ?
> In the "miss" case, new string is intern'ed.
Your heap space would be ~20 bytes smaller. ;-)

In other words, if your program deals with millions of 
strings-from-elsewhere, your should...
- use the gc options
- use if..else construct instead
- wait for integration of "Extend switch .. case statement for all types 
and simple expressions" proposal, so you can use "switch 


More information about the coin-dev mailing list