Where has all the backward compatibility gone?
-
So I checked out this, somewhat outdated, Android project, to look how complicated it is, because we are planning some tech spikes that could reuse parts of it. So I set up a sandbox, based on Debian Bookworm (stable), install default-jdk in it, try to run
gradlewin the project and …Get
FAILURE: Build failed with an exception. * What went wrong: Could not determine java version from '17.0.10'.🥃🌮🦊? So I 🦆🦆 it and find
ERROR: Could not determine java version from "17.0.1"
when trying to run ./gradlew setupDecompWorkspace eclipse I get the following error: Could not detrmine java version from 17.0.1. the gradle-wrapper distributionUrl is gradle-2.7-bin.zip and my cur...
which points to
Apparently, Gradle can use
javacnewer than itself to build the sources, but it refuses to run in such java itself. Warum, kurwa? Just warum? Is the Java runtime not backward compatible‽Ock fourse, Debian currently does not have java 8 in stable. It was removed on 06 Apr 2019. Because “Package not in unstable”, which is weird, because it is in unstable.
And not long ago I had similar run-in with dotнет. Colleague upgraded the container for one dotнет-based service from 6 to 8, but forgot to also update the target in the project file. And the dotнет 8 SDK happily compiled the code targeting dotнет 6, but … the resulting binary flat out refused to run without dotнет 6 runtime being installed. 🥃🌮🦊?
-
@Bulb said in Where has all the backward compatibility gone?:
So I checked out this, somewhat outdated, Android project, to look how complicated it is, because we are planning some tech spikes that could reuse parts of it. So I set up a sandbox, based on Debian Bookworm (stable), install default-jdk in it, try to run
gradlewin the project and …Get
FAILURE: Build failed with an exception. * What went wrong: Could not determine java version from '17.0.10'.🥃🌮🦊? So I 🦆🦆 it and find
ERROR: Could not determine java version from "17.0.1"
when trying to run ./gradlew setupDecompWorkspace eclipse I get the following error: Could not detrmine java version from 17.0.1. the gradle-wrapper distributionUrl is gradle-2.7-bin.zip and my cur...
which points to
Apparently, Gradle can use
javacnewer than itself to build the sources, but it refuses to run in such java itself. Warum, kurwa? Just warum? Is the Java runtime not backward compatible‽Ock fourse, Debian currently does not have java 8 in stable. It was removed on 06 Apr 2019. Because “Package not in unstable”, which is weird, because it is in unstable.
And not long ago I had similar run-in with dotнет. Colleague upgraded the container for one dotнет-based service from 6 to 8, but forgot to also update the target in the project file. And the dotнет 8 SDK happily compiled the code targeting dotнет 6, but … the resulting binary flat out refused to run without dotнет 6 runtime being installed. 🥃🌮🦊?
Java occasionally break backward compatibility, for instance in 17 the removal of RMI.
That said, Android dev is a whole different bundle of wtf, most of which is not the fault of Java.
-
@Carnage said in Where has all the backward compatibility gone?:
Java occasionally break backward compatibility, for instance in 17 the removal of RMI.
… that's just a library, isn't it? So if someone still needs it that bad, they should be able to install it … though I don't know Java well enough to be sure it won't crash into something somewhere.
That said, Android dev is a whole different bundle of wtf, most of which is not the fault of Java.
Gradle is a generic Java tool not tied to Android though.
Otherwise, well, the point of this exercise I'm doing it for is to explore the Android … it's not so much development as platform fragmentation
… and possible workarounds.
-
@Bulb said in Where has all the backward compatibility gone?:
@Carnage said in Where has all the backward compatibility gone?:
Java occasionally break backward compatibility, for instance in 17 the removal of RMI.
… that's just a library, isn't it? So if someone still needs it that bad, they should be able to install it … though I don't know Java well enough to be sure it won't crash into something somewhere.
That said, Android dev is a whole different bundle of wtf, most of which is not the fault of Java.
Gradle is a generic Java tool not tied to Android though.
Otherwise, well, the point of this exercise I'm doing it for is to explore the Android … it's not so much development as platform fragmentation
… and possible workarounds.Well, Android is stuck on a really old java definition, so it gets a nice compound backward compatibility breakage suite when you use modern javas. I haven't used gradle in almost a decade now, so don't know why it's breaking. Maven seems to work no matter what I versions throw at it. I also haven't poked the ugly stick at Android in about as long, so there may be some compatibility mode flag you can throw at things to make them not break.
-
@Carnage said in Where has all the backward compatibility gone?:
I haven't used gradle in almost a decade now, so don't know why it's breaking.
It looks like it's being intentionally obnoxious for
. It reads the Java version and refuses to start if it does not know that version. 
@Carnage said in Where has all the backward compatibility gone?:
I also haven't poked the ugly stick at Android in about as long, so there may be some compatibility mode flag you can throw at things to make them not break.
It didn't get to anything Android-specific yet. Just pure Gradle
.
-
And modern android can use just about any Java version. I think we're using 17+ in our app.
I'm betting the problem is a very outdated gradle version in the build files.
-
@Bulb said in Where has all the backward compatibility gone?:
Debian currently does not have java 8 in stable.
Did it previously have sun java 8, or did it have openjdk 8? Compatibility between oracle and open jdk is pretty good nowadays, but that's in part because after java 8 they dropped a bunch of stuff which wasn't in openjdk.
-
@Benjamin-Hall said in Where has all the backward compatibility gone?:
And modern android can use just about any Java version. I think we're using 17+ in our app.
I'm betting the problem is a very outdated gradle version in the build files.
Well, yes, the gradle-wrapper checked in the repository is ancient. Antedilluvial, probably. 2.14.1.
That does not explain why gradle flat out refuses to run in Java newer than itself. That's still
.@PleegWat said in Where has all the backward compatibility gone?:
@Bulb said in Where has all the backward compatibility gone?:
Debian currently does not have java 8 in stable.
Did it previously have sun java 8, or did it have openjdk 8? Compatibility between oracle and open jdk is pretty good nowadays, but that's in part because after java 8 they dropped a bunch of stuff which wasn't in openjdk.
No, it did not. Debian itself never had Sun or Oracle Java, because it was never allowed to redistribute it. They had CGJ and I think Jikes before switching to OpenJDK shortly after it came to existence. It also used to have a package that would install Sun Java, in those prehistoric times even before the Sun was eaten by Oracle, but I'm not sure it even ever got upgraded to install Java 8. It basically fell into disuse somewhere around version 6.
Now the project … I didn't check the build server install instructions, so I don't know, but it probably built on Windows with Oracle Java 8.
It is a safety-critical software, so it does have exact build server installation instructions and all the packages that are to be installed there are saved in version control system, because they may need to be able to reconstruct the build environment in a decade or two if some issue is found in the field.
But while I did work for that department in the past, but I've long since lost full access and I didn't get it for this small side project, so I can't easily check.
-
@Bulb said in Where has all the backward compatibility gone?:
That does not explain why gradle flat out refuses to run in Java newer than itself. That's still .
that's not backwards compatibility issues on Java's part. That's a lack of forward compatibility on Gradle's part /I'm guessing it's not gradle, in general. It's this particular wrapper was written at a time Java 8 was being replaced by Java <later>. And that particular transition had tons of breaking changes in core places. So it's this specific gradle wrapper version that is hard-locked to Java 8. For "modern" versions, the support matrix is here:
Each version of java "comes online" at a specific version of gradle for running gradle itself. You can compile a gradle-based project with any version, you just can't do the project sync/change the gradle files. Which, to be fair, is a bit of a
. But Gradle has to do all the package management stuff, so it has to understand what core language libraries are involved (so it can properly choose dependency versions, etc). So I'd expect more version entanglement than a regular thing.And old-android, specifically, uses some really special-snowflake things and required Java 8 by itself for a long time.
Edit: I should be clear. Nothing I say here should be considered a defense or statement of support for any of the following:
- Oracle
- Java
- Gradle
- Android
- Kittens
- Puppies
- Apple Pie
- SMOD 2024
-
@Benjamin-Hall Can we defend the kittens and puppies anyway? Asking for a
pyromaniacfriend.
-
@dkf said in Where has all the backward compatibility gone?:
@Benjamin-Hall Can we defend the kittens and puppies anyway? Asking for a
pyromaniacfriend.I mean, I'm fine with them as long as they're not near me OR (not XOR) hypoallergenic. And not noisy, filthy, or otherwise unpleasant. I hold no ill-will towards even the ones I'm not fine with, just can't defend them while they're like that.
-
@Benjamin-Hall said in Where has all the backward compatibility gone?:
@dkf said in Where has all the backward compatibility gone?:
@Benjamin-Hall Can we defend the kittens and puppies anyway? Asking for a
pyromaniacfriend.I mean, I'm fine with them as long as they're not near me OR (not XOR) hypoallergenic. And not noisy, filthy, or otherwise unpleasant. I hold no ill-will towards even the ones I'm not fine with, just can't defend them while they're like that.
You find yourself able to defend them in the abstract, but the realities of fur allergies are unfortunate. Particularly as kittens tend to go 110% into purring...
-
@dkf said in Where has all the backward compatibility gone?:
@Benjamin-Hall said in Where has all the backward compatibility gone?:
@dkf said in Where has all the backward compatibility gone?:
@Benjamin-Hall Can we defend the kittens and puppies anyway? Asking for a
pyromaniacfriend.I mean, I'm fine with them as long as they're not near me OR (not XOR) hypoallergenic. And not noisy, filthy, or otherwise unpleasant. I hold no ill-will towards even the ones I'm not fine with, just can't defend them while they're like that.
You find yourself able to defend them in the abstract, but the realities of fur allergies are unfortunate. Particularly as kittens tend to go 110% into purring...
Purring I'm fine with. It's dogs barking or howling that I dislike, at least if it's constant. I've got neighbors whose dog will sometimes bark like it's being murdered for an hour straight.
