Just because your drop saw burns out in 10 years that doesn't automatically make my code obsolete in 10 years.
I can make a same counter argument using the same logic. I have a car that runs fine well past 10 year mark. Why can't I expect a software do the same?
You did not depend on the manufacturer to do that maintenance. The manufacturer could have even gone out of business and you could still fix or find someone to fix your car.
You however depend on the original developer to click that build button because proprietary software. If it was FLOSS, you could.
But don't worry, thanks to DRMed parts you won't be able to fix anything on your car either (or phone, or any other smart device) without the involvement of the original manufacturer. Ain't property wonderful when the manufacturers intelectual property has precedence over your physical property?
I think you misunderstood the analogy - the app is the car, not the parts. Once you correct that it’s easy to understand why the rest of your message doesn’t make sense.
Java docs are great because they document:
* technical details and algorithms used
* side effects
* runtime and memory usage
* inputs that result in undefined behavior
* causes of exceptions
* behavior when accessed concurrently
* thoroughly hyperlinked
It's been this way for decades and the presentstion has remained largely consistent the whole time.
Second this. The core SDK and many common libraries are very well served by javadoc. I believe this is a key aspect of the success of Java. Javadoc serves so well that it compels Java developers to use it and you can tell if you're dealing with 'good' work or not by the thoroughness of the javadoc work.
Spring has often frustrated me in this regard. Spring's website is thorough and nearly everything you might need can be found there with enough wading, but Spring's javadoc is often lacking. You frequently run into placeholder entries and some of the key Spring packages and classes lack sufficient overview javadoc. Spring's indifference to javadoc is deeply stupid. I can think of several cases where Spring users have written suboptimal programs where they fail to utilize the platform properly, and I'm certain this happens in-part because Spring's javadoc fails to guide them.
One case I ran into in the last little while is a system that implements a configuration file template system; Spring properties substituted into templates used to generate multiple complex (not 'context') configuration files. Unless you read the walls of Spring website documentation you won't know that Spring already provides exactly that capability and so the coders involved wrote their own half-baked one.
I don't know which game implements it but the Nintendo Switch's system license lists FSR as one of the libraries that it uses. So I guess even Nintendo Switch supports it.
I can make a same counter argument using the same logic. I have a car that runs fine well past 10 year mark. Why can't I expect a software do the same?