4 ms·

A super duper universal binary? Oh you mean a .jar file

ReactiveJelly 6y ago
You can move any car by pushing it, but I wouldn't call that driving.
wolrah 6y ago
Ah yes, Java, with the promise of "write once, run anywhere"...as long as anywhere has a specific version of the JRE installed that's been EoL since 2007. Obviously that's not the case for all Java software, but has always amazed me how seemingly easy Java made it to end up like that. So many legacy Java apps that are a complete pain to support, and $deity help you if one user needs to run two different legacy apps with non-overlapping JRE requirements. And that's not even getting in to the horrors that were the Java plugin, fortunately that is entirely out of my life and gone for good.
- seanhunter 6y ago
  Agree and I am very glad I don't have to deal with this type of thing any more. Sane support for different JREs is one of the use cases where containerization would really show its worth I expect. It should be relatively easy to set up a container with the app, the right jre version and a consistent set of dependency jars, all wrapped up with a shellscript that sets the class path and adds any horrible monkey patches you need to get things working and then launches it with the right set of arguments etc. Once that's done all that nastiness would be kept in its own private hell and you could have multiple of them running simultaneously and know that they won't infect each other and upgrading any one piece and/or your system jdk isn't going to kill everything. It's not dependent on the system or user classpath or other environment variables, so should be reproducible and avoid weird "it works for me" bugs where the user is suffering something you just don't see. Safe to say that's far from what "write once, run everywhere" seems to promise.
- mikestew 6y ago
  as long as anywhere has a specific version of the JRE installed that's been EoL since 2007. I just ran into this on a new machine while trying to get Bamboo (Atlassian's CI product) running. Just download latest? phhhttt It needs a specific version: 1.8. Wait a minute, WTF? Java is at like v14 now, or something, right? Ah, because apparently there's some soft link from 1.8 to $WHATEVER_VERSION. Didn't matter because I downloaded the JRE, but needed the JDK. Or something. I've eventually got it working, and wrote it down this time. I go back so far that I've written software on punch cards. And someone suggests that we foist this on your average Mac (or for that matter, any OS) user? Fat binaries, please.
  - cesarb 6y ago
    > It needs a specific version: 1.8. Wait a minute, WTF? Java is at like v14 now, or something, right? There was a compatibility break between Java 1.8 and Java 9 (the version number also lost the prefix at the same time, Java 1.8 can be thought of as "Java 8"). It was not as big as the change from Python 2 to Python 3, but a lot of software needed changes to not break; as late as last year, I was still seeing Java libraries adding fixes for compatibility with Java 9. If your software depends on libraries which have not yet been upgraded to work with Java 9, you have to require Java 8 (that is, Java 1.8). It doesn't help that, even today, the default version of Java in some major Linux distributions is Java 1.8, so not only that's a good reason to keep compatibility with Java 8, but also it means that there's a good chance that the server already has Java 1.8 installed. (In a not so distant future, however, these major Linux distributions will probably have Java 11 as the default version; the next long-term stable Java version after Java 11 is probably going to be Java 17, so you are going to see many software require Java 11 for a while, and later Java 17.)
    - mikestew 6y ago
      Thank you for a helpful explanation from a software engineer, but one who is not steeped in Java all day. It is annoyingly opaque to those of us for whom Java is just a tool.

You can move any car by pushing it, but I wouldn't call that driving.

Ah yes, Java, with the promise of "write once, run anywhere"...as long as anywhere has a specific version of the JRE installed that's been EoL since 2007. Obviously that's not the case for all Java software, but has always amazed me how seemingly easy Java made it to end up like that. So many legacy Java apps that are a complete pain to support, and $deity help you if one user needs to run two different legacy apps with non-overlapping JRE requirements. And that's not even getting in to the horrors that were the Java plugin, fortunately that is entirely out of my life and gone for good.

seanhunter 6y ago
Agree and I am very glad I don't have to deal with this type of thing any more. Sane support for different JREs is one of the use cases where containerization would really show its worth I expect. It should be relatively easy to set up a container with the app, the right jre version and a consistent set of dependency jars, all wrapped up with a shellscript that sets the class path and adds any horrible monkey patches you need to get things working and then launches it with the right set of arguments etc. Once that's done all that nastiness would be kept in its own private hell and you could have multiple of them running simultaneously and know that they won't infect each other and upgrading any one piece and/or your system jdk isn't going to kill everything. It's not dependent on the system or user classpath or other environment variables, so should be reproducible and avoid weird "it works for me" bugs where the user is suffering something you just don't see. Safe to say that's far from what "write once, run everywhere" seems to promise.
mikestew 6y ago
as long as anywhere has a specific version of the JRE installed that's been EoL since 2007. I just ran into this on a new machine while trying to get Bamboo (Atlassian's CI product) running. Just download latest? phhhttt It needs a specific version: 1.8. Wait a minute, WTF? Java is at like v14 now, or something, right? Ah, because apparently there's some soft link from 1.8 to $WHATEVER_VERSION. Didn't matter because I downloaded the JRE, but needed the JDK. Or something. I've eventually got it working, and wrote it down this time. I go back so far that I've written software on punch cards. And someone suggests that we foist this on your average Mac (or for that matter, any OS) user? Fat binaries, please.
- cesarb 6y ago
  > It needs a specific version: 1.8. Wait a minute, WTF? Java is at like v14 now, or something, right? There was a compatibility break between Java 1.8 and Java 9 (the version number also lost the prefix at the same time, Java 1.8 can be thought of as "Java 8"). It was not as big as the change from Python 2 to Python 3, but a lot of software needed changes to not break; as late as last year, I was still seeing Java libraries adding fixes for compatibility with Java 9. If your software depends on libraries which have not yet been upgraded to work with Java 9, you have to require Java 8 (that is, Java 1.8). It doesn't help that, even today, the default version of Java in some major Linux distributions is Java 1.8, so not only that's a good reason to keep compatibility with Java 8, but also it means that there's a good chance that the server already has Java 1.8 installed. (In a not so distant future, however, these major Linux distributions will probably have Java 11 as the default version; the next long-term stable Java version after Java 11 is probably going to be Java 17, so you are going to see many software require Java 11 for a while, and later Java 17.)
  - mikestew 6y ago
    Thank you for a helpful explanation from a software engineer, but one who is not steeped in Java all day. It is annoyingly opaque to those of us for whom Java is just a tool.