5 ms·

I have personally spent so much time fussing with runtime ClassDefNotFound and MethodNotFound errors in Java that I am no longer able to respond to assertions t

I have personally spent so much time fussing with runtime ClassDefNotFound and MethodNotFound errors in Java that I am no longer able to respond to assertions that Java is type-safe with anything but an incoherent stream of cursing and rage tears. But Scala somehow seems to take all of that and intensify it. I have heard that Scala 3 is supposed to improve this, but I don't anticipate being able to adopt Scala 3 before the heat death of the universe.

jayd16 4y ago
Not sure what you're doing with Java but that's not a common problem at all. Are you just aggressively stripping code and dealing with the fallout?
- mumblemumble 4y ago
  Working on projects that involve big frameworks with deep and ever-shifting dependency trees. So upgrading an existing dependency or taking a new one could often be a risky move. Ground zero for most of them was Guava, which I unfortunately could not avoid due to it being a transitive dependency. And, even more unfortunately, Guava types were being exposed on the direct dependency's public API, so package relocation was not an easy option.
  - erik_seaberg 4y ago
    Guava is an outlier. While they do honor semver, they’re already on version 31.1, meaning they have felt they needed to break backward compatibility dozens of times, and it’s likely your dependencies require conflicting versions just by accident of when they were written. I guess it’s because the maintainers live in a monorepo and just force any changes they need?
    - mumblemumble 4y ago
      The other interesting corollary to this is: if your package relies on one like Guava, and it is not bumping its major version number every time it updates the version of Guava it depends on, then your package does not itself honor semver.
      - erik_seaberg 4y ago
        Much like libraries that run on Scala 2.11 or 2.12, I can imagine a system where I maintain several compatible minor versions (or named forks) of a library, each patched to use a different major version of Guava, and letting a caller solve for exactly which version of everything is compatible with everything else. But the more API churn we face, the harder this is.
- dropofwill 4y ago
  Incompatible versions of transitive dependencies, incompatible libs that your web server added, this is the default in Java unless you pay close attention to your dependencies.
the_af 4y ago
That wasn't my experience with Java back in the day. What the article describes with Scala rings true, and I stopped using it (due to a job change) more than 2 years ago! So Scala was already going down this route 2 years ago.
- noisy_boy 4y ago
  > That wasn't my experience with Java back in the day It is still not a typical experience. In our team, we try _very_ hard to avoid reflection and these errors are very very rare (never in Production).
kerblang 4y ago
Those sorts of java runtime errors largely depend on programmers' insistence on doing things via reflection, and it will be the same in any programming language: Like most drugs, at first reflection seems you've opened a new door into enlightenment, until eventually you find yourself sleeping in a gutter with half your teeth missing and wondering why it didn't work out as expected. A lot of Java open source is addicted to this stuff. Scala just adds more drugs to the cocktail.
- mumblemumble 4y ago
  I don't think that this is entirely fair to Java programmers. Java's designers decided early on to lean fairly hard on reflection. Not just by giving Java strong reflective capabilities, but by sometimes deliberately choosing not to give Java great facilities for solving problems without using reflection. When I first came to Java from .NET, I was initially shocked at how heavily it was used in the Java space. (.NET arguably has even more powerful reflection facilities than Java does, but they are typically avoided at all costs.) But it didn't take me very long to realize that many of the C# language features I would have chosen to use instead of reflection simply don't have equivalents in Java. So, I don't think that it's necessarily that Java developers are addicted to this stuff, so much as that they just haven't been given any other choice.
  - seer-zig 4y ago
    Java's type system supports code gen. See projects like the Checker framework or NullAway
- marcosdumay 4y ago
  The errors are created by failures on finding dependencies.

jayd16 4y ago

Not sure what you're doing with Java but that's not a common problem at all. Are you just aggressively stripping code and dealing with the fallout?

mumblemumble 4y ago
Working on projects that involve big frameworks with deep and ever-shifting dependency trees. So upgrading an existing dependency or taking a new one could often be a risky move. Ground zero for most of them was Guava, which I unfortunately could not avoid due to it being a transitive dependency. And, even more unfortunately, Guava types were being exposed on the direct dependency's public API, so package relocation was not an easy option.
- erik_seaberg 4y ago
  Guava is an outlier. While they do honor semver, they’re already on version 31.1, meaning they have felt they needed to break backward compatibility dozens of times, and it’s likely your dependencies require conflicting versions just by accident of when they were written. I guess it’s because the maintainers live in a monorepo and just force any changes they need?
  - mumblemumble 4y ago
    The other interesting corollary to this is: if your package relies on one like Guava, and it is not bumping its major version number every time it updates the version of Guava it depends on, then your package does not itself honor semver.
    - erik_seaberg 4y ago
      Much like libraries that run on Scala 2.11 or 2.12, I can imagine a system where I maintain several compatible minor versions (or named forks) of a library, each patched to use a different major version of Guava, and letting a caller solve for exactly which version of everything is compatible with everything else. But the more API churn we face, the harder this is.
dropofwill 4y ago
Incompatible versions of transitive dependencies, incompatible libs that your web server added, this is the default in Java unless you pay close attention to your dependencies.

the_af 4y ago

That wasn't my experience with Java back in the day. What the article describes with Scala rings true, and I stopped using it (due to a job change) more than 2 years ago! So Scala was already going down this route 2 years ago.

noisy_boy 4y ago
> That wasn't my experience with Java back in the day It is still not a typical experience. In our team, we try _very_ hard to avoid reflection and these errors are very very rare (never in Production).

kerblang 4y ago

Those sorts of java runtime errors largely depend on programmers' insistence on doing things via reflection, and it will be the same in any programming language: Like most drugs, at first reflection seems you've opened a new door into enlightenment, until eventually you find yourself sleeping in a gutter with half your teeth missing and wondering why it didn't work out as expected. A lot of Java open source is addicted to this stuff. Scala just adds more drugs to the cocktail.

mumblemumble 4y ago
I don't think that this is entirely fair to Java programmers. Java's designers decided early on to lean fairly hard on reflection. Not just by giving Java strong reflective capabilities, but by sometimes deliberately choosing not to give Java great facilities for solving problems without using reflection. When I first came to Java from .NET, I was initially shocked at how heavily it was used in the Java space. (.NET arguably has even more powerful reflection facilities than Java does, but they are typically avoided at all costs.) But it didn't take me very long to realize that many of the C# language features I would have chosen to use instead of reflection simply don't have equivalents in Java. So, I don't think that it's necessarily that Java developers are addicted to this stuff, so much as that they just haven't been given any other choice.
- seer-zig 4y ago
  Java's type system supports code gen. See projects like the Checker framework or NullAway
marcosdumay 4y ago
The errors are created by failures on finding dependencies.