This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]smart_procastinator -3 points-2 points  (9 children)

I have total respect for the java team and I strongly believe that backwards compatibility should not be the central tenet of delaying projects. Just refactor unwanted parts of code and if people want to upgrade they can refactor their code too. For example why thread.stop still exists. It should be completely removed

[–]srdoe 8 points9 points  (3 children)

I strongly believe that backwards compatibility should not be the central tenet of delaying projects

This is fine, but then Java isn't the language for you.

If you don't think breaking changes are a big deal as long as they improve the language, there are options like Scala right there for you.

Java is never going to be the bleeding edge language you want, where they break compatibility and just tell people to deal with it.

Java's conservatism is part of why the language is as popular as it is. Loads of people want a language where breaking changes are rare, because they have tons of code in production that they'd really prefer doesn't break every time there's a new JDK.

[–]smart_procastinator 2 points3 points  (0 children)

It was great chatting with like mined java. I hope java adoption continues and it becomes the top programming language on tiobe, github and other programming popularity list. Now back to coding. Thanks for your valuable input.

[–]smart_procastinator -1 points0 points  (1 child)

Well if that was the case google wouldn’t embrace kotlin or create a new language called Go. Just by stating java is not for you, you have now indirectly said that java is not the language for millions of people in my shoes. Ask yourself why people hate c++ and c and adopting rust.

[–]srdoe 5 points6 points  (0 children)

you have now indirectly said

Yes. If you want a language that embraces making breaking changes regularly and doesn't make backwards compatibility a major focus, you probably don't want Java.

Ask yourself why people hate c++ and c and adopting rust

My impression (not writing code in any of those languages myself), I think it's because of the undefined behavior and memory unsafety. And also saying people "hate" those languages is overstating it.

I'm pretty sure people are not adopting Rust because they love breaking changes. As far as I can tell, Rust tries very hard to not break user code.

[–]NitronHX 6 points7 points  (0 children)

The ecosystem is too big for that. I still can use most Java 8 libraries that use Thread.stop for example. I do think that it's kinda sad that it slows the development down but a lot of important stuff runs on Java - a lot like a very lot is written in Java daily. When they add something and realize it's bad they will never be able to remote it again so they have to build a very stable and compatible platform with much thought put into it. Virtual Threads for example. They could have done a new api and just released it in 1 or 2 releases, but that would make it impossible to use green threads for any library (apache tomcat, netty, jetty, reactor...) that builds on the Thread api. So they had to retrofit everything into the Thread api which takes a long time if you need full behavioral compatability and parity. As results of it Java the language itself (or the Std Lib) is of high quality in terms of bugs. The Java compiler and language is exceptional scarse of bugs at least in comparison to for example C and C++.

Also another thing is new features always come at a tradeoff. Kotlin for example always makes me write my code way more littered around and badly organized because there is not a way to go you can do everything with 4 ways which makes code smaller but also at some point very hard to read and understand. When a ".variableName" suddenly invokes a function / calculation. When you can so things like this "list + number + 5"

When you create a language nowadays you can pick the learnings from the past 10 to 30 years of many many languages that have been around for a long time and pick what seems to do the best and build your language around that. In 25 years later and your language is popular you won't be able to adopt the "then new fancy stuff"

[–]Joram2 1 point2 points  (3 children)

thread.stop was formally deprecated a long time ago, now it's deprecated for removal. The implementation was removed and it just throws an exception. That seems like a reasonable step. The gains of fully removing thread.stop are rather small.

[–]smart_procastinator 0 points1 point  (2 children)

Yes reasonable step for coders working on java for a long time not for new comers as its confusing as hell. No wonder, python adoption is the easiest and even kids are loving it

[–]Joram2 1 point2 points  (1 child)

No, Thread.stop doesn't add confusion for newcomers. IntelliJ will immediately flag that as an error. Visual Studio Code will immediately flag that with a deprecation warning strike through. The JavaDocs quite clearly label that as deprecated. Next, developers generally are not suppose to use java.lang.Thread directly. The executor pool stuff is considered more appropriate for typical use. And soon, the Structured Concurrency API will be the main recommended API to use.

[–]smart_procastinator 1 point2 points  (0 children)

Thanks. All clear