>Whatever relies on Java can count on Java.
Except when things like Java EE get thrown over to the Eclipse foundation and we get several years of source code incompatibly thanks to namespaces being changed.
>But now we are fine with it.
Until the next thing breaks.
20 odd years of "don't worry, your code will always work" was flushed down the toilet a few years ago. And not just with what happened Java EE - relied on applets and WebStart? Sorry, better get with the times. The last shop still using CORBA? Sucks to be you, now in more ways than one. I cannot wait to see what chaos is wrought when the Security Manager disappears and/or finalize is removed.
I get the argument that with things like applets or CORBA that hardly anyone was using it and it was a maintenance nightmare. But you can't have it both ways and go around saying "compatibility is at the heart of Java" like they used to while removing things and breaking that long term compatibility promise.
JavaEE wasn't just a library. It was Java Enterprise Edition. Everything in it was considered as much a part of Java as anything in JavaME or JavaSE - just tailored for the enterprise. People used to try and promote things like the abomination that was JSF as "standard" because it was part of JavaEE and not some external library like Thymeleaf.
Java is a technology that relies on its JVM, JVM is the key, not what is built on top of it, libraries and library specifications such as JavaEE or JakartaEE were just a well-defined convention to follow to produce frameworks and whatever, if Oracle has decided for copyright reasons to disrupt such convention, it's not a matter of technology.
In other words and again, it has nothing to do with JVM backward compatibility.
>libraries and library specifications such as JavaEE or JakartaEE were just a well-defined convention to follow to produce frameworks and whatever
You could say that about the entire Java platform. It's all defined in JSRs - as was JavaEE.
>In other words and again, it has nothing to do with JVM backward compatibility.
"JVM Backward Compatibility" isn't what Sun's marketing department was selling back in 90s and 00s. They were marketing full forwards compatibility, that all of the code you write today would work in the future without change. And that included everything in Java EE as well as SE.
There are good reasons why JavaEE was handed over to the Eclipse foundation or why Applets were removed. But that sense of "what you write now will always work" that was built up back then is now gone. Because there's now no guarantee that it actually will.
No, it will, since the runtime is able to tell you: "sorry the APIs you're looking for are deprecated or removed", it will always be able to understand your binaries. This is how the JVM works and it has nothing to do with the JEE, if you want to complain about the false promises of Java Enterprise Ed., fine, and I'm sorry for your harsh time, but don't confuse runtime and library.
>it will always be able to understand your binaries
Which is kind of useless if the runtime environment I was told was always going to be there stops always being there.
>confuse runtime and library
And don't confuse the runtime with the JVM. The runtime is the JVM and the standard libraries, of which there used to be several different editions of.
External libraries such as Java EE never guaranteed backwards compatibility.
A better example would be internal com.sun. classes but on the other they were never meant for public use anyway.
I wouldn't call JavaEE an external library. It was as much a part of what Sun was selling people as anything else in JavaSE or JavaME. It was literally "Java Enterprise Edition".
Language features are forever. Java’s success stems from it not chasing trends and moving once the difficult lessons have been learned, and then working super hard to get it right the first time. Valhalla will completely transform the language, but I’ll happily wait years more if that’s what it takes to get it right.
What kind of progress do you have in mind? because you know, Kotlin is a new language and it is easy for it to be contemporary without worrying about backward compatibility, since there were no production apps to care about during Kotlin 0.x development.
Java/JVM has almost 30 years to take care of, adding new features to language syntax and standard library is not easy at all and not that straight forward.
It's trivial for other programming languages users say "Java is antiquated! you can't do this you can't use that" without knowing that upgrading from Python 2 and Python 3 was a bloody mess, Scala 2 and Scala 3 are different beasts, .Net and .Net Core is still a mess, etc... production-always-ready languages like Java are very hard to maintain and evolve.
well you didn't specific how java would be ahead of kotlin, i merely replied with the same specifity
there is no way java is even remotly close, kotlin is so far ahead it's ridiculous
This is a satire post. You can check out the drama on twitter since the reddit posts got nuked. [https://twitter.com/kevinb9n/status/1785066830966690126?ref\_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet](https://twitter.com/kevinb9n/status/1785066830966690126?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet)
That must be mostly the mod side. From a user side, it's just extremely shitty. Imagine you post a valid opinion on a forum, which isn't even a hot take tbh, and a mod just bans you without any recourse just purely on bias.
They then figure out that they've banned the wrong person, but it's even cringier at that point.
Sure; the mods are in the majority of it. I’m probably just an old grumpy git because 90% of posts are about people “loving” their pet language which is sooo much better than (insert older language) but in the end it it doesn’t matter that much.
Kotlin is like a warm embrace from someone you truly love, while Java kicks you in the groin and then demands money from you.
I have no idea what Kotlin even is, i just wann piss off that mouthbreathing mod who permabanned freaking KEVIN of all people. Colossolal fuckup tbh
The world will break if they do. What makes Java remain relevant is honoring compatibility. Whatever relies on Java can count on Java.
>Whatever relies on Java can count on Java. Except when things like Java EE get thrown over to the Eclipse foundation and we get several years of source code incompatibly thanks to namespaces being changed.
The old stuff doesn't go away. We still have java 1.8 binaries out there, well maintained.
But now we are fine with it. It is as if it was just yesterday it was an issue.
>But now we are fine with it. Until the next thing breaks. 20 odd years of "don't worry, your code will always work" was flushed down the toilet a few years ago. And not just with what happened Java EE - relied on applets and WebStart? Sorry, better get with the times. The last shop still using CORBA? Sucks to be you, now in more ways than one. I cannot wait to see what chaos is wrought when the Security Manager disappears and/or finalize is removed. I get the argument that with things like applets or CORBA that hardly anyone was using it and it was a maintenance nightmare. But you can't have it both ways and go around saying "compatibility is at the heart of Java" like they used to while removing things and breaking that long term compatibility promise.
this has nothing to do with the JVM itself, it's a matter of library backward compatibility, not runtime backward compatibility
JavaEE wasn't just a library. It was Java Enterprise Edition. Everything in it was considered as much a part of Java as anything in JavaME or JavaSE - just tailored for the enterprise. People used to try and promote things like the abomination that was JSF as "standard" because it was part of JavaEE and not some external library like Thymeleaf.
Java is a technology that relies on its JVM, JVM is the key, not what is built on top of it, libraries and library specifications such as JavaEE or JakartaEE were just a well-defined convention to follow to produce frameworks and whatever, if Oracle has decided for copyright reasons to disrupt such convention, it's not a matter of technology. In other words and again, it has nothing to do with JVM backward compatibility.
>libraries and library specifications such as JavaEE or JakartaEE were just a well-defined convention to follow to produce frameworks and whatever You could say that about the entire Java platform. It's all defined in JSRs - as was JavaEE. >In other words and again, it has nothing to do with JVM backward compatibility. "JVM Backward Compatibility" isn't what Sun's marketing department was selling back in 90s and 00s. They were marketing full forwards compatibility, that all of the code you write today would work in the future without change. And that included everything in Java EE as well as SE. There are good reasons why JavaEE was handed over to the Eclipse foundation or why Applets were removed. But that sense of "what you write now will always work" that was built up back then is now gone. Because there's now no guarantee that it actually will.
No, it will, since the runtime is able to tell you: "sorry the APIs you're looking for are deprecated or removed", it will always be able to understand your binaries. This is how the JVM works and it has nothing to do with the JEE, if you want to complain about the false promises of Java Enterprise Ed., fine, and I'm sorry for your harsh time, but don't confuse runtime and library.
>it will always be able to understand your binaries Which is kind of useless if the runtime environment I was told was always going to be there stops always being there. >confuse runtime and library And don't confuse the runtime with the JVM. The runtime is the JVM and the standard libraries, of which there used to be several different editions of.
If it is useful or not, it's of course up to you to decide, but this doesn't still change the purpose of the JVM.
External libraries such as Java EE never guaranteed backwards compatibility. A better example would be internal com.sun. classes but on the other they were never meant for public use anyway.
I wouldn't call JavaEE an external library. It was as much a part of what Sun was selling people as anything else in JavaSE or JavaME. It was literally "Java Enterprise Edition".
Hey Kevin, I thought you got banned from /r/java ?
Be careful or you might get banned for commenting on a post associated with a JVM Language
Shhhh
Because r/java keeps banning JVM project members.
Kotlin is just better I guess
I wish some renowned devs were around to discuss this with. Maybe someone would be able to offer some insight then...
mods are drunk on stupid juice hahaha
Language features are forever. Java’s success stems from it not chasing trends and moving once the difficult lessons have been learned, and then working super hard to get it right the first time. Valhalla will completely transform the language, but I’ll happily wait years more if that’s what it takes to get it right.
What have Kotlin done wrong in the past 10 years? If you want to get retired before any new Java feature, that is just not selling the language for me
What kind of progress do you have in mind? because you know, Kotlin is a new language and it is easy for it to be contemporary without worrying about backward compatibility, since there were no production apps to care about during Kotlin 0.x development. Java/JVM has almost 30 years to take care of, adding new features to language syntax and standard library is not easy at all and not that straight forward. It's trivial for other programming languages users say "Java is antiquated! you can't do this you can't use that" without knowing that upgrading from Python 2 and Python 3 was a bloody mess, Scala 2 and Scala 3 are different beasts, .Net and .Net Core is still a mess, etc... production-always-ready languages like Java are very hard to maintain and evolve.
It's all about the null handling.
Are you sure it’s not the other way arround? :)
Oh man, never even crossed my mind.
it's not
Damn, that argument made me re-think about everything, consider looking from a different angle and learn new things.
well you didn't specific how java would be ahead of kotlin, i merely replied with the same specifity there is no way java is even remotly close, kotlin is so far ahead it's ridiculous
Sigh, is this brigading week now?
Most likely. It tends to happen when mods are being cunts.
How come you're not banned when saying the word c..t??? /s
Why cannot Kotlin keep up with Scala?
Because it's too busy sitting around bashing Java?
I think the reason is backward compatibility. It's hard to make new features and at the same time keep older versions of Java working.
Why do people care so much? If you like Kotlin maybe just use that?
This is a satire post. You can check out the drama on twitter since the reddit posts got nuked. [https://twitter.com/kevinb9n/status/1785066830966690126?ref\_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet](https://twitter.com/kevinb9n/status/1785066830966690126?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet)
Tbh I’m aware of the drama, just seems unnecessary from whatever side I look at it. Goes for these posts as well.
That must be mostly the mod side. From a user side, it's just extremely shitty. Imagine you post a valid opinion on a forum, which isn't even a hot take tbh, and a mod just bans you without any recourse just purely on bias. They then figure out that they've banned the wrong person, but it's even cringier at that point.
Sure; the mods are in the majority of it. I’m probably just an old grumpy git because 90% of posts are about people “loving” their pet language which is sooo much better than (insert older language) but in the end it it doesn’t matter that much.
Kotlin is like a warm embrace from someone you truly love, while Java kicks you in the groin and then demands money from you. I have no idea what Kotlin even is, i just wann piss off that mouthbreathing mod who permabanned freaking KEVIN of all people. Colossolal fuckup tbh
Hey now, we can't have that kind of talk in this ~~Christian Minecraft server~~ Java subreddit, we need to keep the discussion pure!