<div dir="ltr">Firstly, about SDM. The only alternative to it is rich domain model. The key difference is while entities in RDM execute business logic (and sometimes database logic) on them itself, in SDM this is done with Services and Repositories. If you have ever seen such architecture - it is a SDM essentially. Currently, JPA promotes such approach with POJOS and persitencee specifications, persistence providers along with spring expose APIs like JpaRepositories and annotations like @Service. Modern Java frameworks are harnessed to suit SDM.<div><br></div><div>About init-only fields. They usually are a compromise between legacy specs and immutability, but could also have other usages. They are pretty much like readonly fields but could be set from anywhere where setter is exposed, *only for once* (initialization i nconstructor also counts as intiialization of field). Then they become final. When it comes to persistence specifically, they help to make some fields of entities effectively immutable. Also the yare hepful if field cant be set by constructor for some reason right away, so accessor should be exposed (it is usually a bed design, but there are some exceptions like asyncronous tasks ran in the background that initialize field, while response arent dependent on it and has to be sent right away). Summarizing, its main application is in the entities, which could seem narrow, but in fact covers a significant part of commercial developers workflow.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 24 апр. 2024 г. в 17:25, - <<a href="mailto:liangchenblue@gmail.com">liangchenblue@gmail.com</a>>:<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 dir="ltr">If a bad practice is common, it doesn't mean we should go along that path.<div><br><div>> Nevertheless, the fact nowadays is that a simple domain model conquered the world, and it requires accessors as it is essentially procedural programming.</div><div><br></div><div>I don't know how you've reached that conclusion, but almost no Java core library code after Java 5 exhibits such patterns. There are getters to immutable properties, which are fine, but most setters are replaced by builders or factory methods instead. Setters are bad for JVM's JIT compilations too.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 9:21 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<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 dir="ltr">Also what I have to say on accessors is that getters and setters of any kind have been GRASP antipatterns since the first day of their existence. They breach encapsulation and information expert. Nevertheless, the fact nowadays is that a simple domain model conquered the world, and it requires accessors as it is essentially procedural programming. Fighting accessors is like fighting windmills: we could either accept and acknowledge their existence and adapt to actual environment or just try to pretend like some day ther will be a clear OOP in the world and in this fabulous world assessors will not be used at all</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 24 апр. 2024 г. в 17:13, ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" target="_blank">rotan.olexandr@gmail.com</a>>:<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 dir="ltr">> 

First, I don’t agree that properties have become an industry standard. Not all languages, even those newer than Java have them. .... 

The two languages with similar or higher popularity to Java’s have fewer features than Java, not more.<div><br></div><div>I have to agree with the point that JS, and Python (as I reckon that's the ones you are referring to) have less features then Java. However, what I would like to say is that, in my opinion, they are popular despite, not due to it. Less features and simple syntax obviously make them easier for learners, but that mostly comes from their interpreted nature, which comes at the cost of dramatical performance differences. Still, what the market currently indicates (I am not an analyst of any kind, this is just my observations), is that most popular languages, especially for product companies, are the ones that help *write* code faster at cost of support terms. I agree with Java prioritizing second over first, but language paradigms, as for me, should shift along with the market at least to some extent. So to conclude, while most popular languages *do* have fewer features, they still provide better developer experience due to their interpreted nature, and their popularity is caused by better developer experience, not by the amount of features in them.</div><div><br></div><div><div>> While setters remain inevitable, if the need for them drops, the problem of writing them more easily becomes smaller, and a smaller problem doesn’t justify a language feature as much as a bigger problem. It makes the cost in complexity of the feature higher with respect to its benefit.</div><div><br></div><div>While it makes setters a lesser problem, does it make it that small for pros to not outweigh cons? In modern applications, 99% of the time concurrency is handled by controller pattern, while the processing environment is single-threaded, and all possible problems are covered by things like entity managers. Data mutations are non-concurrent in the majority of situations, if we exclude race conditions at the database level.</div><div><br></div><div>> I don’t agree that properties have become an industry standard.</div><div><br></div><div>I did some research on that. Let's consider only backend languages here so we judge popularity across similar languages: I will use PYPL rankings as it gives, as I think, the most accurate top 15. (Let's not refer to TIOBE here for obvious reasons)</div><div><br></div></div><div>Out of 15 most popular programming languages, there are 6 languages that are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.</div><div>Languages that have properties: TS, C#, Kotlin.</div><div>Languages that don't: Python, Go (and Java).<br></div><div><br></div><div>Each of the languages that doesn't have properties has its reason to it: python essentially doesn't have any encapsulation, Go just dont have classes, only structs (same for Rust by the way). All languages that were designed for OOP and server side (which essentially implies a simple domain model), have properties. There aren't many languages to have comprehensive statistics, but even now (especially if we weigh these languages with their popularity), properties are much more popular then no properties. Also judging by popularity now isn't the best way of doing measurements: best languages now will be most popular in a decade at least. For example, I have done more deep research for my country (Ukraine). With the start of war, the market significantly shifted towards product companies from outsource, and now, when it comes to building apps from scratch, C# is the most popular choice. Concluding, while I might have really put too much into saying it is an industry standard, this is clearly a popular choice.</div><div><br></div><div>Also, what I always point out is that developer experience is tightly linked to measurements like TTM and errors per line of code in languages, and while dropping into users demand completely like python or js do is obviously not the best choice, In my opinion, optimal point is somewhere closer to where C# currently is, not where Java is. (Although some features of C# like arrays pattern matching are obviously redundant, so not that close to C# :) )<br></div><div><br></div><div>Appreciate Andrew`s comment, I haven't looked at it from this perspective, but when it comes to syntaxic sugar and not root features, I think that is not really applicable as it is transformed to recognizable for JIT syntax during compilation.</div><div><br></div><div>PS: I think I am not in a position to say what is right and wrong in approach of many experienced developers that guide Java`s development, but I think that when you are coming into discussion with mindset of trying to find the reasoning why not to introduce something, it might be harder to actually evaluate all pros and cons. As I understand, even if pros outweigh cons, but not significantly enough, features are discarded. As for me, that`s not the best way to go with requests that are popular in the community.</div><div><br></div><div>PPS: I would appreciate any feedback on this. And also about init-only fields, is there some thoughts regarding them in the community? I feel like it aligns pretty well with where jdk developers are heading currently</div><table cellpadding="0" style="border-collapse:collapse;margin-top:0px;width:auto;font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px;display:block"></table></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 24 апр. 2024 г. в 16:25, ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" target="_blank">rotan.olexandr@gmail.com</a>>:<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 dir="ltr">No, I am sorry, I had to write the last message from my phone and didn't notice the error. Thanks for letting me know</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 24 апр. 2024 г. в 16:11, - <<a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a>>:<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 dir="ltr"><div>Is this intended to go to the mailing list or just to me?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 8:04 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<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 dir="auto"><div dir="auto"></div>Also, what I always point out is that developer experience is tightly linked to measurements like TTM and errors per line of code in languages, and while dropping into users demand completely like python or js do is obviously not the best choice, In my opinion, optimal point is somewhere closer to where C# currently is, not where Java is<div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024, 15:54 ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" rel="noreferrer" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<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 dir="auto">Well as a compromise between mutable and immutable objects there could be init only fields. What is regarding to property mutations being antipattern, it may have as many downsides as possible, but still is inevitable in production, and, moreover, is one of the most popular tasks to perform. Entities are mutable by specification, and there is nothing we can really do about that.<div dir="auto"><br></div><div dir="auto">I also appreciate Ron Pressler's clarifications, this makes everything a lot more understandible for me. </div><div dir="auto"><br></div><div dir="auto">What I would like to say on this topic is that while immutability is understandible trend nowadays, when we are talking about production, the major part of the work is working with entities, which are inheritandably mutable (and in many cases at least some of their properties should remain that way). </div><div dir="auto"><br></div><div dir="auto">Current workarounds that exist to avoid undesired mutations is to expose public constructor with required fields while making no-args constructor protected, along with ommiting setters for such fields.</div><div dir="auto"><br></div><div dir="auto">Init only fields would probably be fix to problems of mutability, I may also do some research on them, but what I would like to say is that some properties are just mutable by their nature (like email fields, or amount of attempts left), and this is still a very widely encountered case and will surely remain so.</div><div dir="auto"><br></div><div dir="auto">Also, that's all discussion about set accessors. What about get accessors, I don't really see downsides of them, and it would be a neat addition that could freshen up a language</div><div dir="auto"><br></div><div dir="auto">Edit: Ron, I saw your last message just now, so I will reply to some of the points here.</div><div dir="auto"><br></div><div dir="auto">Firstly, I have already addressed that setters are effectively inevitable, init only fields could do the trick you are trying to do by disencouraging setters (which is a great by the way, I also think that even for mutable objects immutability should be preserved where possible).</div><div dir="auto"><br></div><div dir="auto">About language complication, I get this point, concise syntax of Java is why I fell in love with it in the first place. But as the time moves, it becomes clear that some features just become industry standard: properties, previously discarded extensions, object deconstruction etc. While I agree that language should not just blindly accept every possible feature, wide usage of some may indicate (and indicates) there is a demand for those. I understand the desire to make language better by omitting the road that once tricked languages like c++, but I think sometimes, when demand is high enough, we should let users have what they want. At the end of the day, trere isn't a problem in more flexible approaches, but some of the most common problems, in my opinion, should be addressed specifically. This way we could have a perfect balance between user experience and code quality.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024, 15:30 - <<a href="mailto:liangchenblue@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">liangchenblue@gmail.com</a>> wrote:<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 dir="ltr">No, field modification is an antipattern and should be avoided at best, so both of the direct setfield instruction or a setter call are antipatterns, as these can be made from other threads and cause unpredictable memory effects. For entity mutations, it's recommended that they are only accessed single threaded to avoid incorrect programs. However, you probably still don't want setters, as this implies the fields are not related to each other and all cartesian products of all fields are possible, which is rarely the case and such usages are still better covered by records.<div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 7:22 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<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 dir="auto">I am not fully getting it. So things like foo.prop = val is antipattern while foo.setProp(val) is not? What about objects like entities, where constant data mutations are inevitable and classes are mutable by spec?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024, 15:18 - <<a href="mailto:liangchenblue@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">liangchenblue@gmail.com</a>> wrote:<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 dir="ltr">Hi Oleksandr,<div>Such properties are an antipattern in Java nowadays. We should prefer immutable objects and records/builders instead. Mutations should happen on the stack as much as possible for thread safety. And record components already accomplish the "property" feature in an immutable sense.</div><div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 4:24 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<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 dir="ltr">As I see extension methods haven't been accepted as gladly as expected, I decided to put them in stash for now and work on some other features that I think Java lacks for now.<div><br></div><div>I think properties (seamless access to them to be precise) would be a great addition, but having my previous experience, I want to ask were there any discussions about that previously.</div><div><br></div><div>Also, if there wasn't, or at least properties were not rejected, I have a few questions regarding implementation that I want to know community opinion about. </div><div>Firstly, I think, having all the codebase populated with get and set accessors, the best way to add such thing would be to treat getX as a get accessor to property X and setX correspondingly.</div><div>Secondly, unlike C# for example, I think that absence of property accessor should just imply direct access instead of forbidding it (in C#, int a {get;} implies a is effectively immutable)</div><div>Lastly, for the sake of backward compatibility, I guess if a variable is directly visible in scope, I think that it should be modified directly rather than through an assessor. While that severely damages data integrity, this will not introduce any source code incompatibilities (bytecode incompatibilities isn't a thing here if properties will be desugared in compile-time)</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>