the biggest things to change java have been type inference, lambdas, records, streams (functional ops on collections), and pattern matching. these are all must-have features for any modern programming language. at this point any language without these features will feel old and legacy. it’s impressive java was able to add them all on decades after release, but you do feel it sometimes
Rating 26 years of Java changes
31–40 of 327 posts
Re: Rating 26 years of Java changes
#32Can someone explain why developers like var?
It's called type inference and it's the way things should be. You get the same types but you don't have to spell them out everywhere. Java doesn't even go all the way, check OCaml to see full program inference.
Re: Rating 26 years of Java changes
#33Earlier quoted context omitted.
Well, it was annoying until autoboxing came in. // Before autoboxing list.add(new Integer(42)); // After autoboxing list.add(42); Mostly it's a non-issue now. If you're desperately cycle/memory constrained you're likely not using Java anyway.
You can get pretty good performance out of Java these days, so long as you know to avoid stuff like boxed primitives and the streams api, as they generally have god-awful memory locality, and generally don't vectorize well.
Yeah, I know there are even oddballs using it for HFT and the like - I like Java a lot, but even I find that a bit peculiar.
Edit: actually, if someone here is using it for something like that I'd love to hear the rationale...?
Re: Rating 26 years of Java changes
#34Re: Rating 26 years of Java changes
#35It appears that most of the good changes are imported from C#.
Or Scala. Or Kotlin. Or any of the other languages that had most of these features years if not decades before Java. ;)
Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful.
It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in the last 17 releases.
Re: Rating 26 years of Java changes
#36For my part, returning to Java a couple years back after 15+ years away, streams + var/val were my favorite discoveries.
Re: Rating 26 years of Java changes
#37Autoboxing's evil twin, auto-unboxing should knock the score down a few points.
Integer a = null;
int b = 42;
if (a == b) {} // throws NullPointerExceptionRe: Rating 26 years of Java changes
#38Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
It's seriously puzzling. I just don't get how it's possible to look at what so many others have done better, and somehow design something worse. For what reason? Consistency with the rest of the language, possibly? But is that really so important. Do they just not want to tackle certain parts of the compiler?
Some of the weirder choices have been the result of a desire to avoid making breaking changes to JVM bytecode.
Also there was a long period when changes were very lumpy - it could be multiple years for a feature to make it into the release, and anything that might screw up other features got a lot of pushback. Then other conventions/tools emerged that reduced the urgency (e.g. the Lombok stuff)
Edit: I should add that it's now on a fixed 6-monthly release cycle which IMO works much better.
Re: Rating 26 years of Java changes
#39Can someone explain why developers like var?
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate.
Generally, you save some keystrokes to let other people (or future you) figure it out when reading. It seems like bad practice altogether for non trivial projects.
Re: Rating 26 years of Java changes
#40Interesting; I actually have grown pretty fond of NIO.
I will acknowledge that the interface is a bit weird, but I feel like despite that it has consistently been a "Just Works" tool for me. I get decent performance, the API is well documented, and since so many of my coworkers have historically been bad at it and used regular Java IO, it has felt like a superpower for me since it makes it comparatively easy to write performant code.
Granted, I think a part of me is always comparing it to writing raw epoll stuff in C, so maybe it's just better in comparison :)