Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Lenses Practical in Java

chriskiehl.com

Post reply on HN
Print view View original

51–60 of 108 posts

Re: Making Lenses Practical in Java

#51

Post by logicchains »

ivan_gammel wrote: post #37
pron wrote: post #34

Earlier quoted context omitted.

In the works: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

I hope they will find a better solution, as this proposal will break encapsulation. Let’s say you model allowed transitions via business methods and thus restrict certain state changes. You can either serialize or deserialize state or perform an allowed transition. If wither becomes a language feature, it will allow forbidden state changes that cannot be caught by validation in constructor, which will allow deseriali…

The proposal is meant for records, and records are used for "plain old data", explicitly without any encapsulation.

Re: Making Lenses Practical in Java

#52

Post by erik_seaberg »

pron wrote: post #33
Matthias247 wrote: post #30

Earlier quoted context omitted.

But they require a new JDK version, and a surprisingly high amount of Java projects are still stuck on JDK8.

JDK 8 is now a minority, and if we count only projects that are still undergoing significant development it's a significantly smaller minority. The main reason some projects are still stuck on 8 is because they use old libraries that have made breaking changes, and don't have resources to adapt their use, let alone take on new ones.

The way I heard it, Java 9 breaks Spark 2.4 badly with no good workaround to disable Jigsaw (which we otherwise don’t care about), and that’s is a problem for a lot of data pipelines in our monorepo. It sounds like other large projects also had a lot of trouble working around Jigsaw, especially for proxying and mocking, and you are blocked at least as long as any of your dependencies are blocked (which was also one reason the Python 3 migration was so slow and painful).

Re: Making Lenses Practical in Java

#53

Post by ivan_gammel »

chowells wrote: post #43
pron wrote: post #32

Earlier quoted context omitted.

> (e.g., "given a DOM node, traverse all of its children") you can use a library of transformations ... and write queries and transformations over arbitrary structures in a very compact way. But in Java you'd do that with reflection. So the question remains, how many such different queries/transformations you actually have (in the source code, where type checking is available, rather than user input) to make the effo…

Maybe you would rather do that with reflection, but I'd rather do something that isn't fundamentally the same tools that create security vulnerabilities. Every time you can not-use reflection is a win.

I think there’s some misunderstanding between the two of you. Reflection is indeed the sane and convenient solution for working with structures when type is not known at compile time (e.g. general purpose library for DI, ORM, security or serialization). It’s definitely not the way to manipulate object trees when type is known in compile type. However the point about complexity is valid: is it really worth patching strongly coupled solution violating SRP and breaking encapsulation with some design pattern for an anti-pattern (setters)?

Re: Making Lenses Practical in Java

#54

Post by ivan_gammel »

logicchains wrote: post #51
ivan_gammel wrote: post #37

Earlier quoted context omitted.

I hope they will find a better solution, as this proposal will break encapsulation. Let’s say you model allowed transitions via business methods and thus restrict certain state changes. You can either serialize or deserialize state or perform an allowed transition. If wither becomes a language feature, it will allow forbidden state changes that cannot be caught by validation in constructor, which will allow deseriali…

The proposal is meant for records, and records are used for "plain old data", explicitly without any encapsulation.

Nope. If records were structures, they would not be allowed to have methods or overloaded constructors or even default constructor. The most obvious example of encapsulation in records is validation of state.

Re: Making Lenses Practical in Java

#55

Post by yakubin »

crummy wrote: post #47
yakubin wrote: post #45

Earlier quoted context omitted.

Or they develop for Android. Not a minority.

Are most android devs still working with Java or Kotlin?

I’ve worked for 2 companies so far which maintain a bit of Android code and neither used Kotlin. GitHub search for “#android language:Java” reports 49K repositories, while “#android language:kotlin” reports 25K repositories. GitHub is biased towards greenfield projects, not legacy corporate codebases, so I’d expect the ratio of Java to Kotlin code in non-open-source software to be much higher. I wouldn’t be surprised if it’s more than 10 times higher.

Re: Making Lenses Practical in Java

#56

Post by pjmlp »

fedeb95 wrote: post #9

I don't agree on the fact that lombok has brought us out of the dark ages. We used to use it, but it has some drawbacks. One of them, it's an additional dependency. This, for a simple thing such as pojo, seems a bit overkill to me. The additional amount of time used to write some cose isn't worth the risk of additional bugs hidden in having one more dependency.

I never used it, nor do I plan to.

Re: Making Lenses Practical in Java

#57

Post by pjmlp »

yakubin wrote: post #45
pron wrote: post #33

Earlier quoted context omitted.

JDK 8 is now a minority, and if we count only projects that are still undergoing significant development it's a significantly smaller minority. The main reason some projects are still stuck on 8 is because they use old libraries that have made breaking changes, and don't have resources to adapt their use, let alone take on new ones.

Or they develop for Android. Not a minority.

At least the lucky ones having Android 12 as baseline can now make use of Java 11 subset (because as usual Google only takes the parts of standard library they care about).

Re: Making Lenses Practical in Java

#58

Post by kaba0 »

ivan_gammel wrote: post #54
logicchains wrote: post #51

Earlier quoted context omitted.

The proposal is meant for records, and records are used for "plain old data", explicitly without any encapsulation.

Nope. If records were structures, they would not be allowed to have methods or overloaded constructors or even default constructor. The most obvious example of encapsulation in records is validation of state.

They still don’t have encapsulation, all members are readable on purpose.

Withers will likely go through the same default constructor so constraints can be upheld, though.

Re: Making Lenses Practical in Java

#59

Post by ivan_gammel »

kaba0 wrote: post #58
ivan_gammel wrote: post #54

Earlier quoted context omitted.

Nope. If records were structures, they would not be allowed to have methods or overloaded constructors or even default constructor. The most obvious example of encapsulation in records is validation of state.

They still don’t have encapsulation, all members are readable on purpose. Withers will likely go through the same default constructor so constraints can be upheld, though.

>They still don’t have encapsulation, all members are readable on purpose.

Public state does not mean no encapsulation. The purpose of encapsulation is to bundle state and behavior and hide them both behind an interface, but that interface can offer read access to state. The key here is behavior.

>constraints can be upheld

My example above demonstrates a constraint that cannot be implemented in a constructor.

Re: Making Lenses Practical in Java

#60

Post by brabel »

jeroenhd wrote: post #48
javaunsafe2019 wrote: post #3

I just use Kotlin. Never looked back.

Kotlin alone won't implement these features for you. You'd end up with something like this: val order = loadOrder() val approved = order.copy( approval = order.approval.copy( confirmation = order.approval.confirmation.copy(updatedOn = Instant.now()), status = ApprovalStatus.Approved ) I think I prefer this explicit deep cloning over the automagically generated lenses in standard code, but I can see the appeal. The pr…

I like to call this "direct code". It does exactly what it looks like it does. Lenses do not, they introduce a whole abstraction around something as simple as get/set. For this reason, the Kotlin code above would be much preferred IMO.
Post reply on HN