<div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Holo,<br><br>Thank you for your response!<br><br>> I don’t see how you can have parallelism without having<br>> some horrible potential bugs.<br>> Imagine the following situation:<br>> <br>> public static AtomicBoolean bl = new AtomicBoolean(true);<br>> public static void sideEffect() { <br>>     bl.set(false);<br>>     return true; <br>> }<br>> ...<br>> Integer i = 0;<br>> switch (i) {<br>>     case Integer i when bl.get() -> ...<br>>     case Integer i when sideEffect() -> ...<br>>     ...<br>> }<br>> <br>> In this example we can have:<br>> <br>>   - Enter case 1 with correct state<br>>   - Enter case 2 with correct state<br>>   - Enter case 1 with wrong state<br>> <br>> Using move variables we can create a (albeit a bit<br>> pathological) example with any number of cases that all<br>> can be entered with a wrong state (apart from maybe the<br>> default branch).<br><br>Yes, no matter what, side effects can cause all of this to fall apart. Though, I would say that that already sounds like a pretty severe code smell, if not a bug (with the exception of maybe execution counters or something like that). And that's excluding parallelism here, just plain sequential execution of the cases.<br><br>> Also, it can be dangerous when the when clause is<br>> expensive. Maybe it is possible to calculate the non-when<br>> clause in parallel fashion, but I don’t know if it worth<br>> the effort<br><br>I see what you mean. An extremely expensive when clause that should be called only when all other cases fail would cause pretty severe performance problems for no good reason. And realistically, the same could be said of the deconstruction pattern too. Now that user created deconstruction patterns are coming down the pipe, that technically means that deconstruction could be expensive too.<br><br>Furthermore, reading your comment just now made me think of a problematic example.<br><br>    final int someInt = 20;<br>    <br>    final String response = <br>        switch (someInt)<br>        {<br>        <br>            case Integer i when i >=  0  && i < 10 -> "a";<br>            case Integer i when i >= 10  && i <=20 -> "b";<br>            case Integer i when i >= 20  && i < 30 -> "c";<br>            <br>            case null, default -> <br>                throw new IllegalArgumentException("?!");<br>        <br>        };<br><br>Sequential execution will always return "b", but parallel execution might return "c", assuming no clean up effort by Java to return the "top-most case".<br><br>In short, you raised a pretty definitive point in why concurrent execution would be problematic. And Steve mentioned earlier in this thread that the overhead would be too much, so I definitely see what you mean.<br><br>And to be clear, my OP and subsequent responses are all purely with knowledge gathering intent. I want to learn more about how parallelism is used in Java. This is certainly no feature request or "feasability request".<br><br>Thank you for your insight!<br>David Alayachew</div><br></div>