Properties

[ІП-24 Олександр Ротань]

I agree, the initial topic has shifted significantly, so let's not pollute
this mail list. I wonder if there is a more suitable place for such
discussions in future.

Regarding stable values, I feel like it looks more like lazy getters to me,
init only property goal is to enforce effective immutability of mutable
objects in most of the cases, I don't see how it could be
accomplished using stable values.

ср, 24 апр. 2024 г. в 17:55, - <liangchenblue at gmail.com>:

> For init-only fields, Java has one upcoming JEP for that:
> https://openjdk.org/jeps/8312611
> This one exposes Java's existing @Stable annotation to users, so that
> these init-only fields can be treated as constants by the JVM. It also has
> multiple ways to set the field (via setter, lazy computation), all of which
> guards against multiple sets as well.
>
> For SDM vs RDM, I believe the core Java libraries mostly under the "RDM"
> model, that its objects are not simply carriers but contain the actual
> logic, like OOP is supposed to. The "SDM" is mainly used I believe for easy
> conversion between data like JSON, which should be done with records for
> cross-thread immutability.
>
> After all, this thread is digressing and don't belong to the java
> compilers. I hope we can move the discussion somewhere else. Also, most of
> Java's feature expansion has little to do with compilers, such as Virtual
> Threads or this Stable Values, which allows Java enhancements to actually
> benefit all JVM programming languages instead of just Java itself.
>
> On Wed, Apr 24, 2024 at 9:37 AM ІП-24 Олександр Ротань <
> rotan.olexandr at gmail.com> wrote:
>
>> 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.
>>
>> 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.
>>
>> ср, 24 апр. 2024 г. в 17:25, - <liangchenblue at gmail.com>:
>>
>>> If a bad practice is common, it doesn't mean we should go along that
>>> path.
>>>
>>> > Nevertheless, the fact nowadays is that a simple domain model
>>> conquered the world, and it requires accessors as it is essentially
>>> procedural programming.
>>>
>>> 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.
>>>
>>> On Wed, Apr 24, 2024 at 9:21 AM ІП-24 Олександр Ротань <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>> ср, 24 апр. 2024 г. в 17:13, ІП-24 Олександр Ротань <
>>>> rotan.olexandr at gmail.com>:
>>>>
>>>>> >  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.
>>>>>
>>>>> 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.
>>>>>
>>>>> > 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> > I don’t agree that properties have become an industry standard.
>>>>>
>>>>> 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)
>>>>>
>>>>> 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.
>>>>> Languages that have properties: TS, C#, Kotlin.
>>>>> Languages that don't: Python, Go (and Java).
>>>>>
>>>>> 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.
>>>>>
>>>>> 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# :) )
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> ср, 24 апр. 2024 г. в 16:25, ІП-24 Олександр Ротань <
>>>>> rotan.olexandr at gmail.com>:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> ср, 24 апр. 2024 г. в 16:11, - <liangchenblue at gmail.com>:
>>>>>>
>>>>>>> Is this intended to go to the mailing list or just to me?
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024 at 8:04 AM ІП-24 Олександр Ротань <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024, 15:54 ІП-24 Олександр Ротань <
>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> I also appreciate Ron Pressler's clarifications, this makes
>>>>>>>>> everything a lot more understandible for me.
>>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Edit: Ron, I saw your last message just now, so I will reply to
>>>>>>>>> some of the points here.
>>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 24, 2024 at 7:22 AM ІП-24 Олександр Ротань <
>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Oleksandr,
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 24, 2024 at 4:24 AM ІП-24 Олександр Ротань <
>>>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> 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)
>>>>>>>>>>>>> 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)
>>>>>>>>>>>>>
>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/f726aab3/attachment-0001.htm>