Re: Are there real use cases with the Java access modes?

Brian, you are saying what I feel.  The issue is simply that non-volatile compiler optimization behavior breaks a simple construct that requires adding volatile declaration to fix.  We can discuss how much is missing from the Swing/AWT multi-threading support.  Many people have engineered something using SwingWorkerThread and shared data structure exchanges.  That works from a trivial level of knowledge, because you can read about it.

The use of volatile as a solution to simple one reader and one writer exchanges, as you say, is not really a solution, but rather a wrenching into the system to disable a problem that occurs in logic, broken by inaction by the developer.

Everything else involving data sharing happens through frameworks and APIs with JavaDoc, examples online, and books even!  I am just one voice calling this out.  I was the one voice first demanding that Java 9 not be released with introspection disabled.  It took quite some time for server only developers to understand how separate Java jar file software releases from Java version management for desktop users.  There is never a combined release of anything in the desktop environment for most users that I interact with. Forever forward compatibility is what you have to do, to develop Java for the Desktop, and that is impossible, but the best thing to aim for.

Oracles change in licensing is now pushing many companies to openJDK and that push compatibility requirements back to JDK 1.8 and the risk is that there’s now no path forward with modularity “always”.  Thus means two releases if not code bases and that implies that Java is no longer write once, run everywhere.  Microsoft is eliminating barriers and python is sucking inexperienced service developers into a non-scalable platform down the road.

The Java community needs to be heavily focused on all barriers to entry and first experiences and inexperienced developers have to be part of that audience.  Sun showed Java’s target audience as the 1,000,000 and up developers, not the 10,000 experts in big tech.  It would appear that Java is carving itself into a very vertical market space instead of being the write once run anywhere software system that was changing software for the better.  

The JVM has been heavily leveraged!  We need Java to continue to be a beneficial software system, or what have the past 25years of work been about?

Gregg Wonderly

> On Jul 18, 2021, at 4:48 PM, Brian S O'Neill via Concurrency-interest <[email protected]> wrote:
> 
> Consider for a moment if Java was originally designed with the current memory model, and that all fields were effectively volatile by default. This would mean that the loop problem that you identified would never surface, which is a good thing.
> 
> One problem is now solved, but perhaps new problems would emerge? The first problem that I can think of is that this doesn't magically make code thread-safe. The cost is performance, and there's no real benefit except in a few cases. The bigger problem is "premature optimization".
> 
> As soon as someone discovers that declaring fields as non-volatile offers performance benefits, then this ends up becoming best practice, and new thread safety issues emerge that never should have.
> 
> The best practice these days is for most programmers to never declare volatile fields in the first place, because it implies that they're doing magic stuff with threads and they might not do it correctly. Unlike Java 1.0, there's plenty of frameworks that take care of thread safety nicely without having to declare fields as volatile or make methods synchronized. Work queues fall into this category, for example.
> 
> Your concern seems to be with regard to Java desktop apps, and this is fair. The Java desktop API (AWT/Swing) was designed without proper consideration for threads, and it's quite a mess as a result. A lot has been learned since then, and the desktop API is in need of a major refresh. That is, it needs to be completely redesigned to incorporate the lessons learned over the past 25 years. If a new design requires that fields need to always be volatile, then it's a failure too.
> 
> By the way, I suspect that most people on this mailing list (including me) usually write server-side code, and so we don't have a proper understanding of how the desktop API can sometimes be a burden. So when we hear someone suggesting that fields behave as volatile by default, we wonder if this would solve any of the problems we've ever encountered. I can't really think of any, but then this is probably because the server-side has a richer set of frameworks to use.
> 
> 
>> On 2021-07-18 10:54 AM, Gregg Wonderly via Concurrency-interest wrote:
>> Good software design always includes the notion of least surprise.  In which ot

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest