Re:Which version of JDK should I use?
by chrisseaton on Sunday October 10, 2021 @06:33PM
(#28822583)
> involving some pretty scary reflection stuff for some unexplained reason
This is where it always seems to end up. Why do people bend over so far backwards doing reflection that isn't specified?
Because Java, particularly pre-8 Java, sucks so bad if you try to actually write your whole application in it.
(I always found this really frustrating when making the argument for Scala. Yes, Scala-the-language is more complex than Java-the-language. But it's not more complex than the pile of reflection magic that anyone who tries to write a nontrivial system in Java actually ends up using).
Re:Which version of JDK should I use?
by chrisseaton on Monday October 11, 2021 @05:16AM
(#28826356)
I try to do everything in plain-old Java, and my code just keeps running release to release.
From what I've seen: to add automagic functionality, syntactic sugar and wrapper methods for libraries. The JVM/Java language doesn't seem to have the tooling necessary to accomplish this natively, so it's the only reliable way to do it without relying on annotation processors having properly run (which still require some reflection magic, depending on the use case).
Reflection and class loader shenanigans to shoot them selves in the foot.
This silently broke a bunch of scripts and callbacks because of class cast exceptions and such. The solution was to rewrite the scripts in such a way to import the Java Long class and use that directly to express large integers.
The most important breaking issues I've found were not necessarily in our code base, but in dependencies. Libraries that include libraries that include libraries, all doing their own thing, a lot of the time involving some pretty scary reflection stuff for some unexplained reason. Blindly upgrading libraries only gets you so far, sometimes a dependency gets abandoned and you need to find a replacement and rewrite your code to call the APIs in the right manner to be backwards compatible enough.