5 ms·

What a strong ad for Java

dehrmann 2y ago
Java's maintained almost perfect backward compatibility. If you want code you wrote today to run in 10 more years, Java is probably the best choice. Most other languages have too much of a history of breaking changes, or if you pick C/C++, you'll have issues linking against an old UI library.
- worthless-trash 2y ago
  There are many other languages with a better lindy effect rating ( https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect), common lisp, erlang, fortran and more. I won't doubt how java doing well, but other languages have it beat.
  - dehrmann 2y ago
    > common lisp, erlang, fortran That's a pretty esoteric list. Javascript would have been a better choice because of widespread deployment by multiple vendors and heavy legacy.
    - worthless-trash 2y ago
      Javascript is still pretty young (comparatively) however I do believe you'd be right in saying that its likely to be around for a very long time.
      - itronitron 2y ago
        Interestingly, Javascript is just as old as Java, and Python is older.
        worthless-trash 2y ago
        Python kinda dies each major release though, there is no backwards compatability goals.
  - EdwardDiego 2y ago
    Except they're not in widespread usage, so aren't relevant. No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?" And as for Common Lisp, which implementation? They can't even be compatible amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just work.
    - worthless-trash 2y ago
      > And as for Common Lisp, which implementation? They can't even be compatible > amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just > work. For a bit more solid example: https://web.archive.org/web/20150217111426/http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html https://web.archive.org/web/20150217111426/http://www.inform... This too will likely end up being downvoted for talking against the hivemind here.
    - worthless-trash 2y ago
      > Except they're not in widespread usage, so aren't relevant. I don't know any java programmers either. Apparently people use java, I just dont know any that do it willingly. I'm sure they -must- use it, but erlang/fortran/etc as mythical to you as java is to me. > No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?" Fresh grads don't know better, they take whatever pays. Businesses choose the cheapest (not the best) option and grads don't have the experience to choose better. Grads choices are not a measure of quality or desirability. > And as for Common Lisp, which implementation? They can't even be compatible > amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just > work. My SBCL from 2010ish works, I've patched it up and improved it over time, but I haven't tried to run the original, it probably does. Its been through svn to git so I've lost the history, all of this is as anecdotal as anything else. Previous lisp code that I wrote was trivial and ran out of the box on SBCL, however the code is very self contained and not 'networked' or 'modern'. My erlang code however has been running in a cluster since the early 2000's, it has also been through several releases for additional features, however I no longer have access to that code so I can't validate what has been done to it for the last decade. I like your arguments, I just dont think we're coming from the same historical viewpoint.
  - stavros 2y ago
    The Lindy effect assumes you have no other information about the thing you're estimating. Obviously if I know the thing is on its deathbed, I can't invoke the Lindy effect. Similarly, a hundred-year-old language one person uses any more isn't likely to last another hundred years. Given the relative sizes, I wouldn't bet on Common Lisp outlasting Java just because it's older.
    - worthless-trash 2y ago
      Its likely we will both be dead before either of them are no longer being maintained.
  - lmm 2y ago
    Yeah have you tried actually running a common lisp program from decades ago on a different implementation from the one it was developed on?
palad1n 2y ago
Seriously. Remember applets? My first real Java app was a small 3D Pong game using AWT, and it still works using appletviewer on my M1 MacBook Pro. I mean, it's circa 1998.
- twic 2y ago
  I found an old applet of mine from the late '90s, and tried running it. Crashed with a NullPointerException from deep inside AWT. My guess is that there is now some setup that needs to be done that didn't at the time.
vbezhenar 2y ago
2011 for Java is nothing. I've used JDBC driver written for Java 1.4 (2002) in Java 17 and I absolutely sure that it'll work with Java 21 just as well. Java backwards compatibility is real and it works absolutely fine unless you do bad things.
- xxs 2y ago
  Personally I consider 1.4.2 the point where java got stable, and had a true IO (java.nio), along with a decent JIT (hotspot)
  - _the_inflator 2y ago
    Phew, that was around the internet Java applets phase, if I recall it correctly?
    - xxs 2y ago
      That much it was all about JSP/XML and stuff; J2EE too. JDO came soon after too. The applets did exist and (javax.)swing was a thing - but it was far from the focus... and of course Java was still considered slow.
- robertlagrant 2y ago
  I think the last breaking change I remember was enumerations being added, which broke any code that used the class name as a variable name. But I could be wrong; it was almost 20 years ago.
  - v-erne 2y ago
    Maybe not a part of language per se but they throw out corba in java 11 and this decimated some very old libraries that used is as dependency.
  - matsemann 2y ago
    With Java 11 they hid a lot of internal functions that people had used in their code, so breaking things. But that was never really part of the public API, so strictly not a breaking change. I remember moving to Java8 changed the iteration order of hashmaps etc, which also broke some stuff for us. But again, that was mostly our fault for relying on unspecified behavior.
_ZeD_ 2y ago
that should be the norm. the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season
- cqqxo4zV46cp 2y ago
  Not really. Not automatically, anyway. Realistically, code lasting forever is, the majority of the time, some engineer’s nerdy wet dream almost completely devoid from any real-world requirements. “This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack. In the vast majority of cases, the processes that the software seeks to automate will have been thrown out LONG before then. The business went bust and the only surviving copy is on some developer’s personal computer. Darlene from accounting left and her replacement likes to do things differently, so all this custom stuff was replaced with something off-the-shelf. Your $40B unicorn dating network very unceremoniously fell from the charts after Gen Z decided to throw their phones away and connect in person like we used to. After all that, you’re left there holding a perfectly functional(?) solution to a problem nobody is asking to be solved anymore. Let’s be clear: I know that banks run on COBOL. Everyone knows that. Please don’t say it. I can name 5-10 other industries off the top of my head where this sort of longevity matters. But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.
  - The_Colonel 2y ago
    Longevity is very important in enterprise apps. Companies are full of small services / utilities which were developed many years ago, work for the most part just fine and need to be touched only rarely to fix a bug which just started manifesting, add a small feature or enable some integration.
  - v-erne 2y ago
    >> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time. Not my experience at all. I am literally at this moment releasing new version of private app framework that was created by few people (including me) about 18 year ago for few clients on long forgotten platform because some client (who is still paying support fees!) found some obscure bug building new application using this framework. The previous version was released about 8 years ago.
xxs 2y ago
stuff written for java 0.9 (1996), even with the default package (no namespaces), still runs normally. 2011 is past java 7.
- guenthert 2y ago
  compile once -- run forever! Seriously though, this seems to be due to happenstance (well, commercial interest motivating great continuous engineering effort), rather than by design (forward-thinking) though; unlike, say, IBM's Technology Independent Machine Interface of AS/400.
  - davidalayachew 2y ago
    It's ABSOLUTELY by design. On the Java Mailing Lists, the creators/stewards of Java are constantly fighting back so many feature requests BECAUSE those features would threaten backwards compatibility. And that mailing list has been going on for a long time now. You can see feature requests (and their subsequent rejections) going as far back as the late 90's lol
  - jjav 2y ago
    > rather than by design Remember, Java came from Sun. Backward compatibility was an absolute requirement at Sun for nearly everything. Compatibility is hard-baked-in to the culture. Oracle plays more loose, but a lot of the people are still around. Definitely by design.
  - xxs 2y ago
    bit late on "by design" party - java 'binary' (not source, which is easier) compatibility is an exceptionally important feature. E.g. changing method signature like void x(int val) to void x(long val) does break the binary compatibility and it means the original method has to be preserved, potentially as something like void x(int val){x((long) val);} - which just calls the new method by casting val. It some cases the original method might be marked as deprecated. There are countless examples of such a behavior.
contrarian1234 2y ago
Except now a days you're not encouraged to run a system-wide JVM! You can still download a JVM for Java 21, but it's from weird third parties like Adoptium
- EdwardDiego 2y ago
  Adoptium is a JVM from the Eclipse Foundation. They're hardly weird, even if the branding is. It's basically "people into JVMs not controlled or licenced by Oracle that work good". https://www.eclipse.org/membership/explore-membership/ https://www.eclipse.org/membership/explore-membership/
  - contrarian1234 2y ago
    I never realized it was from Eclipse! They've cleaned up the webpage where it's a bit more clear now. I always figured it was a weird consultancy or something like Gluon - where there was a paid product when you dig a little Thanks for clearing it up. Hope they rebrand and drop the Adoptium name eventually
    - arjvik 2y ago
      It used to be called AdoptOpenJDK, and was a project that essentially just provided prebuilt binaries of OpenJDK. But post several Oracle changes that I admittedly have not kept up with, they have grown in scope and also been forced to remove OpenJDK from their name. They went with Adoptium, to keep the Adopt part that got them famous.
  - pjmlp 2y ago
    Almost correct, except the part that it is a bit like saying Red-Hat is a Linux not controlled by Linus. https://devclass.com/2023/03/22/despite-openjdk-70-of-java-fixes-and-features-come-from-oracle-big-red-says/ https://devclass.com/2023/03/22/despite-openjdk-70-of-java-f...
- brabel 2y ago
  That's bullshit. Here are the JDK distributions supported by SDKMAN, a really good JVM-oriented package manager: https://sdkman.io/jdks https://sdkman.io/jdks There's a couple of dozen vendors in there , including very weird ones like IBM, Microsoft, AWS, Azul, Eclipse, SAP, Redd Hat, and even... Oracle!

Java's maintained almost perfect backward compatibility. If you want code you wrote today to run in 10 more years, Java is probably the best choice. Most other languages have too much of a history of breaking changes, or if you pick C/C++, you'll have issues linking against an old UI library.

worthless-trash 2y ago
There are many other languages with a better lindy effect rating ( https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect), common lisp, erlang, fortran and more. I won't doubt how java doing well, but other languages have it beat.
- dehrmann 2y ago
  > common lisp, erlang, fortran That's a pretty esoteric list. Javascript would have been a better choice because of widespread deployment by multiple vendors and heavy legacy.
  - worthless-trash 2y ago
    Javascript is still pretty young (comparatively) however I do believe you'd be right in saying that its likely to be around for a very long time.
    - itronitron 2y ago
      Interestingly, Javascript is just as old as Java, and Python is older.
      - worthless-trash 2y ago
        Python kinda dies each major release though, there is no backwards compatability goals.
- EdwardDiego 2y ago
  Except they're not in widespread usage, so aren't relevant. No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?" And as for Common Lisp, which implementation? They can't even be compatible amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just work.
  - worthless-trash 2y ago
    > And as for Common Lisp, which implementation? They can't even be compatible > amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just > work. For a bit more solid example: https://web.archive.org/web/20150217111426/http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html https://web.archive.org/web/20150217111426/http://www.inform... This too will likely end up being downvoted for talking against the hivemind here.
  - worthless-trash 2y ago
    > Except they're not in widespread usage, so aren't relevant. I don't know any java programmers either. Apparently people use java, I just dont know any that do it willingly. I'm sure they -must- use it, but erlang/fortran/etc as mythical to you as java is to me. > No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?" Fresh grads don't know better, they take whatever pays. Businesses choose the cheapest (not the best) option and grads don't have the experience to choose better. Grads choices are not a measure of quality or desirability. > And as for Common Lisp, which implementation? They can't even be compatible > amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just > work. My SBCL from 2010ish works, I've patched it up and improved it over time, but I haven't tried to run the original, it probably does. Its been through svn to git so I've lost the history, all of this is as anecdotal as anything else. Previous lisp code that I wrote was trivial and ran out of the box on SBCL, however the code is very self contained and not 'networked' or 'modern'. My erlang code however has been running in a cluster since the early 2000's, it has also been through several releases for additional features, however I no longer have access to that code so I can't validate what has been done to it for the last decade. I like your arguments, I just dont think we're coming from the same historical viewpoint.
- stavros 2y ago
  The Lindy effect assumes you have no other information about the thing you're estimating. Obviously if I know the thing is on its deathbed, I can't invoke the Lindy effect. Similarly, a hundred-year-old language one person uses any more isn't likely to last another hundred years. Given the relative sizes, I wouldn't bet on Common Lisp outlasting Java just because it's older.
  - worthless-trash 2y ago
    Its likely we will both be dead before either of them are no longer being maintained.
- lmm 2y ago
  Yeah have you tried actually running a common lisp program from decades ago on a different implementation from the one it was developed on?

palad1n 2y ago

Seriously. Remember applets? My first real Java app was a small 3D Pong game using AWT, and it still works using appletviewer on my M1 MacBook Pro. I mean, it's circa 1998.

twic 2y ago
I found an old applet of mine from the late '90s, and tried running it. Crashed with a NullPointerException from deep inside AWT. My guess is that there is now some setup that needs to be done that didn't at the time.

vbezhenar 2y ago

2011 for Java is nothing. I've used JDBC driver written for Java 1.4 (2002) in Java 17 and I absolutely sure that it'll work with Java 21 just as well. Java backwards compatibility is real and it works absolutely fine unless you do bad things.

xxs 2y ago
Personally I consider 1.4.2 the point where java got stable, and had a true IO (java.nio), along with a decent JIT (hotspot)
- _the_inflator 2y ago
  Phew, that was around the internet Java applets phase, if I recall it correctly?
  - xxs 2y ago
    That much it was all about JSP/XML and stuff; J2EE too. JDO came soon after too. The applets did exist and (javax.)swing was a thing - but it was far from the focus... and of course Java was still considered slow.
robertlagrant 2y ago
I think the last breaking change I remember was enumerations being added, which broke any code that used the class name as a variable name. But I could be wrong; it was almost 20 years ago.
- v-erne 2y ago
  Maybe not a part of language per se but they throw out corba in java 11 and this decimated some very old libraries that used is as dependency.
- matsemann 2y ago
  With Java 11 they hid a lot of internal functions that people had used in their code, so breaking things. But that was never really part of the public API, so strictly not a breaking change. I remember moving to Java8 changed the iteration order of hashmaps etc, which also broke some stuff for us. But again, that was mostly our fault for relying on unspecified behavior.

_ZeD_ 2y ago

that should be the norm. the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season

cqqxo4zV46cp 2y ago
Not really. Not automatically, anyway. Realistically, code lasting forever is, the majority of the time, some engineer’s nerdy wet dream almost completely devoid from any real-world requirements. “This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack. In the vast majority of cases, the processes that the software seeks to automate will have been thrown out LONG before then. The business went bust and the only surviving copy is on some developer’s personal computer. Darlene from accounting left and her replacement likes to do things differently, so all this custom stuff was replaced with something off-the-shelf. Your $40B unicorn dating network very unceremoniously fell from the charts after Gen Z decided to throw their phones away and connect in person like we used to. After all that, you’re left there holding a perfectly functional(?) solution to a problem nobody is asking to be solved anymore. Let’s be clear: I know that banks run on COBOL. Everyone knows that. Please don’t say it. I can name 5-10 other industries off the top of my head where this sort of longevity matters. But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.
- The_Colonel 2y ago
  Longevity is very important in enterprise apps. Companies are full of small services / utilities which were developed many years ago, work for the most part just fine and need to be touched only rarely to fix a bug which just started manifesting, add a small feature or enable some integration.
- v-erne 2y ago
  >> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time. Not my experience at all. I am literally at this moment releasing new version of private app framework that was created by few people (including me) about 18 year ago for few clients on long forgotten platform because some client (who is still paying support fees!) found some obscure bug building new application using this framework. The previous version was released about 8 years ago.

xxs 2y ago

stuff written for java 0.9 (1996), even with the default package (no namespaces), still runs normally. 2011 is past java 7.

guenthert 2y ago
compile once -- run forever! Seriously though, this seems to be due to happenstance (well, commercial interest motivating great continuous engineering effort), rather than by design (forward-thinking) though; unlike, say, IBM's Technology Independent Machine Interface of AS/400.
- davidalayachew 2y ago
  It's ABSOLUTELY by design. On the Java Mailing Lists, the creators/stewards of Java are constantly fighting back so many feature requests BECAUSE those features would threaten backwards compatibility. And that mailing list has been going on for a long time now. You can see feature requests (and their subsequent rejections) going as far back as the late 90's lol
- jjav 2y ago
  > rather than by design Remember, Java came from Sun. Backward compatibility was an absolute requirement at Sun for nearly everything. Compatibility is hard-baked-in to the culture. Oracle plays more loose, but a lot of the people are still around. Definitely by design.
- xxs 2y ago
  bit late on "by design" party - java 'binary' (not source, which is easier) compatibility is an exceptionally important feature. E.g. changing method signature like void x(int val) to void x(long val) does break the binary compatibility and it means the original method has to be preserved, potentially as something like void x(int val){x((long) val);} - which just calls the new method by casting val. It some cases the original method might be marked as deprecated. There are countless examples of such a behavior.

contrarian1234 2y ago

Except now a days you're not encouraged to run a system-wide JVM! You can still download a JVM for Java 21, but it's from weird third parties like Adoptium

EdwardDiego 2y ago
Adoptium is a JVM from the Eclipse Foundation. They're hardly weird, even if the branding is. It's basically "people into JVMs not controlled or licenced by Oracle that work good". https://www.eclipse.org/membership/explore-membership/ https://www.eclipse.org/membership/explore-membership/
- contrarian1234 2y ago
  I never realized it was from Eclipse! They've cleaned up the webpage where it's a bit more clear now. I always figured it was a weird consultancy or something like Gluon - where there was a paid product when you dig a little Thanks for clearing it up. Hope they rebrand and drop the Adoptium name eventually
  - arjvik 2y ago
    It used to be called AdoptOpenJDK, and was a project that essentially just provided prebuilt binaries of OpenJDK. But post several Oracle changes that I admittedly have not kept up with, they have grown in scope and also been forced to remove OpenJDK from their name. They went with Adoptium, to keep the Adopt part that got them famous.
- pjmlp 2y ago
  Almost correct, except the part that it is a bit like saying Red-Hat is a Linux not controlled by Linus. https://devclass.com/2023/03/22/despite-openjdk-70-of-java-fixes-and-features-come-from-oracle-big-red-says/ https://devclass.com/2023/03/22/despite-openjdk-70-of-java-f...
brabel 2y ago
That's bullshit. Here are the JDK distributions supported by SDKMAN, a really good JVM-oriented package manager: https://sdkman.io/jdks https://sdkman.io/jdks There's a couple of dozen vendors in there , including very weird ones like IBM, Microsoft, AWS, Azul, Eclipse, SAP, Redd Hat, and even... Oracle!