<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">On Wed, Nov 22, 2023 at 11:13 AM Nathan Reynolds <<a href="mailto:numeralnathan@gmail.com" target="_blank">numeralnathan@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It is not only deterministic but also JIT (or an advanced version) could reduce this code to the following single line in main().<br></div><div><br></div><div>System.out.println("Total red weight = 123");</div><div><br></div><div>Since there are no assignments to the Widget fields after construction, they are effectively final.  I wouldn't be surprised if JIT assumes that they are final.  Also, there is no need to put final in the main() body since these values are effectively final.  (You can lookup effectively final.)<br></div></div></blockquote><div><br></div><div>OK I believe you that in the current implementation of the JDK, the behavior is deterministic.</div><div><br></div><div>But as a developer trying to write bug-free code, I can only assume what is published in the documented API.</div><div><br></div><div>Implementation details about the runtime I happen to be using are not relevant to proving the statement "This Java program is always deterministic".<br></div><div><br></div><div>And if I'm limited to what's published in the API for Stream, etc., how am I supposed to prove to myself that the program is deterministic?</div><div><br></div><div>To do that, I would have to assume (for example) that <span style="font-family:monospace">Stream.filter()</span> will always execute in the current thread, because otherwise the writes to the non-final fields are not guaranteed to be visible to other threads.</div><div><br></div><div>But this is not guaranteed to be true in the Stream API docs. In fact, they explicitly state that this would be an unsafe assumption:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Note also that attempting to access mutable state from behavioral parameters
 presents you with a bad choice with respect to safety and performance; if
 you do not synchronize access to that state, you have a data race and
 therefore your code is broken</div></blockquote><div><br></div><div>To make the example program correct based on the documented API, we would have to add synchronization around the construction of the Widgets and pair that with synchronization around the lambdas passed to filter() and mapToInt().<br></div><div><br></div><div>Of course in the real world nobody does that. As a result, my contention is that there is a giant universe of code out there that, just like my example, executes a Stream pipeline on data that is constructed/prepared in the current thread but not guaranteed to be safely published, and where the pipeline contains unsynchronized "behavioral parameters" that access that data.</div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">Any such code is therefore not guaranteed to be deterministic!</span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">The fact that the code works *today* is nice, but it doesn't change the fact that all of this code is just a giant ticking time bomb in case the implementation ever changes (project loom anyone?)<br></span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">Or, you might say "Well, in practice non-parallel streams are always executed in the local thread and I'm sure they'll be that way for a long time".</span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">Great! If that's our stance, then this should be made official and documented in the API: "Non-parallel streams always execute in the current thread".</span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">Right now it seems like we have the worst of both worlds...<br></span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">-Archie<br></span></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">--<br></span></div><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>