4 ms·
I feel like if Java had immutability by default it would be such a better language to work with. It is so hard to determine what actually gets modified where in
by winrid 3y ago
I feel like if Java had immutability by default it would be such a better language to work with. It is so hard to determine what actually gets modified where in a large Java codebase.
- cies 3y agoToo bad immutability breaks the quite-ubiquitous-in-JVM-land Bean spec (and I wonder what one was smoking before drawing that spec). I think having proper sum-types with pattern matching would have also made it a much better language.
- cbm-vic-20 3y agoIt was designed when UML and tools like Rational Rose was being pushed hard by the big consulting firms on their clients as the One True Way to build Serious Business Software. JavaBeans was designed as a way to have a conventional interface that allows code components to be snapped into GUI applications. But someone thought it would be a great idea to use it everywhere else, too.
- cies 3y agoCan we all agree that the bean spec was not a good idea? No matter how old, or what other stupid ideas were fashionable back then. I cannot see how making things "beans" actually solves anything (besides maybe a slight reduction in boilerplate when (de)serializing bean-classes).
- za3faran 3y agoJava now has sum types (sealed types) with exhaustiveness checking, pattern matching for records, and more general destructuring in the works for classes.
- fian 3y agoJava has been around for a longish time. Around the early 2000's there was at least a perception that you should avoid creating too many objects as that carried performance overhead for construction and garbage collection. https://softwareengineering.stackexchange.com/questions/149563/should-we-avoid-object-creation-in-java https://softwareengineering.stackexchange.com/questions/1495... Immutable objects often require you to construct a new object to store an updated value and garbage collect the now unused previous object. So a lot of early Java code was written with mutable objects to avoid performance issues. The Java Bean spec was written in 1997: https://blog.joda.org/2014/11/the-javabeans-specification.html https://blog.joda.org/2014/11/the-javabeans-specification.ht...
- winrid 3y agoI didn't say make everything immutable. I just mean that if you want an object to be mutable, you need to say so.
- The_Colonel 3y agoBean spec is in no way mandatory. Plenty of existing code doesn't follow the bean spec. Immutable Java classes have been in vogue for many, many years.
- za3faran 3y agoJava's records are immutable.
- kelnos 3y agoAnd most shops likely aren't using a JVM new enough to use records, and it will be a while before they are able to upgrade. And even then, most 3rd-party libraries out there won't use records, because they want to be compatible with the JVMs their users use. Hell, most popular libraries available on Maven Central are compiled with JDK8, or, at best, JDK11. Aside from immutable instances, it would be nice if 'final' was the default, as well.
- marginalia_nu 3y agoOn the one hand sure. But if we're going to critique Java honestly, can't we stick to the language the way it looks today and not the way it looked nearly ten years ago? Modern Java is quite pleasant to work with. One by one the papercuts and footguns have been fixed.
- wanttocomment 3y agoSo it sounds like the fix is available with an update. What more do you want?
- dtech 3y agoAlso still extremely hard to use due to basic they are, e.g. there is no "with"-er method or syntax yet to modify existing values.
- za3faran 3y agoWithers syntax is being evaluated/designed as far as I'm aware. You can still get some good work done with records in the meantime.