151–160 of 356 posts
This seems like an appropriate place to post the official Java rap: https://youtu.be/b-Cr0EWwaTk
I prefer this one: Java Forever And Ever Movie (Java vs Windows .Net) https://www.youtube.com/watch?v=RnqAXuLZlaE
Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.
With all my love for .NET, why not continue Java with its new features when it fits to your developer base, existing products etc. Give it one or two more years and Java is where C# is ... also aesthetically. As did JavaScript.
As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.
Or if you mean addition of new features, then Java is very conservative on that front and it is still a very small language compared to most other mainstream ones.
Earlier quoted context omitted.
...but also thousands of other stability, performance, and security updates.
Don't worry, someone will still manage put in a bug that results in a zero day in the next 2 years.
Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.
Java is very different and much improved from when c# branched off, but many people haven’t been following along and still think it’s the same as in 2002.
Earlier quoted context omitted.
I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company th…
There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto…
Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* packages, etc.). So companies are wedged in because they made the poor decision to rely on private packages. And now, Java 11+ enforces this by default.
There are open source Java libraries today that don't run unless you "add-exports" to basically everything. google-java-format comes to mind, because it's using an internal java code parser from the JDK, for example.
And here I am still on Java 8 :/
My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type. I'd still upgrade for the new VM's better performance…
This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…
I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our ca…
Earlier quoted context omitted.
We're still developing this proposal. be patient LOL
Wow that's a proposal! I really like the idea of pattern matching, and I'm glad you're steering clear of modifying switch, but I find the sketches in the proposal pretty hard to read, especially with the combinator examples. I hope you guys take your time and stay more proud of what you leave out than what you put in.
But I definitely agree with the sentiment - every new feature is another thing that a developer needs to learn if they encounter that code. There should be a large "barrier to entry" for new features.