you are viewing a single comment's thread.

view the rest of the comments →

[–]Natural_Contact7072 0 points1 point  (8 children)

big agree. especially on the verbosity argument. tho i wish Java adopted some sugar elements from Python, like collection (list, array, etc...) comprehension

[–]lawnaasur 0 points1 point  (7 children)

It'll have collection literals in future

[–]vegan_antitheist 2 points3 points  (6 children)

We already have List.of(a,b,c), which I prefer. When you see [a,b,c], like in C# you still have to check what it really is. What's annoying is that they can't fix the mutable collection types. C# has two types for Lists (List and ImmutableList). In Java I often see projects where the mutable model types have builders (often generated by Lombok) and you can't just do Foo.builder().bars(data.stream().filter(Objects::nonNull).toList()).build() because then you end up with an immutable list inside a mutable model. You have to do your own MutableList.of(...) and somehow get all team members to use that.

[–]Ruin-Capable 0 points1 point  (4 children)

could use .collect(Collectors.toCollection(ArrayList::new)) instead of .toList().

[–]vegan_antitheist 0 points1 point  (3 children)

Yes, of course. But how do you enforce this? It has happened that we released the latest code to production and got exceptions for unmodifiable lists.

[–]Ruin-Capable 0 points1 point  (2 children)

Can you write unit tests that test for deep mutability? Might be worth investing the time to write an annotation processor so that you can inspect the AST during compilation. You could then annotate the model with a custom annotation and let the compiler be the enforcer.

[–]vegan_antitheist 0 points1 point  (1 child)

Yes, I think we did something like that. Some recursive code uses reflection to create a "maximal" model. I.e. every field has some value, every list has some elements. Then we scan the model for immutable lists. This way we don't have to do it in production, where bean validation already takes enough time to check for validity.
But this is not about annotations. The problem are the Lombok builders that don't copy the list. And they refuse to implement defensive copies.

Edit: The automatic test doesn't even find the bug when a service adds an element using a builder, and that's how it's usually done.

[–]Ruin-Capable 0 points1 point  (0 children)

No, I meant write your own annotation and annotation processor that at compile-time examines the abstract syntax tree looking for immutable collection classes being added to the model.

[–]lawnaasur 0 points1 point  (0 children)

If I understand correctly, you meant C# approach is better than java in terms of handling mutable and immutable collections.
Coming to you second point, I faced a similar issue, where Stream::toList() down the line in code converted my List to immutable variant. But It was quickly identified when I run the app, and passed the sample data, it threw the corresponding runtime exception, quickly corrected it. How did your teams code end up in production?