5 ms·

No. I am the poor programmer whose manager forced me to use a library their nephew's dog or someone wrote that does all of those. Except using finalize for clos

No. I am the poor programmer whose manager forced me to use a library their nephew's dog or someone wrote that does all of those. Except using finalize for closing pipes for subprocesses, that was by Java standard library itself. And keeping references longer than needed, that is every library that implements clever caching, ever. Regarding try-with-resources, RAII was invented for a reason. Java did not copy it, because they seemed to seriously believe that GC is a good substitute. One of the many features of Java is that it is advertised as being easy enough that any idiot can write it, and managers then hire idiots.

vips7L 5y ago
How do you expect RAII to work in any GC language? It would be non-deterministic. The point of try-with-resources is that it is deterministic and you know when something is closed out. Every GC language has implemented this.
- oriolid 5y ago
  I would say that RAII is enforced try-with-resources without the extra syntax and releasing memory when resources are released instead of having a garbage collector is a nice performance optimization. C# with "using var" is on the right track, though. Just make RAII default and explicit close/dispose the special case and add syntax for type-deduced immutable values, and I'd be happy.
cogman10 5y ago
> No. I am the poor programmer whose manager forced me to use a library their nephew's dog or someone wrote that does all of those My condolences, that sucks. I'd still suggest using the profiling tools I've suggested to find these issues and create change requests to said libs. People will think you're a wizard if you simply learn how to use Java's telemetry. It's an invaluable skill. > Except using finalize for closing pipes for subprocesses, that was by Java standard library itself Java uses finalizers as a last resort, not a first line. Finalizers are due to be removed from the language so don't count on them being around for long. > And keeping references longer than needed, that is every library that implements clever caching, ever. Sure, caching is legitimate when the cost of creating exceeds the cost of long lived objects. Have you measured to see if the caches you have are improperly sized? Have you made pull requests/change requests to said libraries to fix it if it is? > Regarding try-with-resources, RAII was invented for a reason. Java did not copy it, because they seemed to seriously believe that GC is a good substitute. RAII was, few languages have it. The languages that don't have it generally don't have it because tracking the lifetime of objects in a GCed language can be extremely difficult. Consider, for example, how java would handle a destructor for an object allocated in one thread shared with multiple other threads. Do you know how C++/Rust/D solve that problem? Through a system of reference counted smart pointers which have to be handled very delicately. Java allows such objects to be freely moved. There are pros and cons to GCs (like most language features) so instead of just defaulting to "man, GCed languages suck because the finalizers aren't called when I want them to be!" perhaps it's a better route to learn the idiomatic way of handling resources and use that?
- oriolid 5y ago
  > People will think you're a wizard if you simply learn how to use Java's telemetry. It's an invaluable skill. People who want to hire me to fix their Java app think already think I am a wizard. The problem is, they stop believing me the moment I tell that Java is not a good language completely stop listening when I say that I will not work with it as long as I have other options. > Java uses finalizers as a last resort, not a first line. At the time it was the only option. Or, reading the JDK source revealed the undocumented feature that destroy() closes the pipes too. > Have you measured to see if the caches you have are improperly sized? Have you made pull requests/change requests to said libraries to fix it if it is? Wasn't the point of using JVM and pre-made libraries that they would work out of the box? Anyway, I have found out that terrible libraries are terrible because their authors either genuinely want them to be that way or because they do not recognize good code when they see it. If you have managed an open source project you should know that pull requests out of nowhere are mostly pure nonsense and tend to be ignored. > Do you know how C++/Rust/D solve that problem? I do, thank you for asking. As far as I understand, Java does not allow moving objects any more than copying a shared pointer or moving unique one does, but it pretends that objects have no ownership. > perhaps it's a better route to learn the idiomatic way of handling resources and use that? It does not solve the problem. The actual solution would be more like "magically make the CTO's nephew and all authors of the zillion libraries the app depends on learn the idiomatic way of handling resources and then rewrite everything using those".
  - Tainnor 4y ago
    > People who want to hire me to fix their Java app think already think I am a wizard. The problem is, they stop believing me the moment I tell that Java is not a good language completely stop listening when I say that I will not work with it as long as I have other options. If people hire you to "fix their Java app" and you then subsequently bury your head in the sand and insist that this cannot be fixed (or you will not fix it) without rewriting it in another language - either you have been lying to them, or they were not listening to you. Regardless, you were probably not a good hire. It seems that you're trying to write Java as if it were C++. That will not work, so stop doing that. > "magically make the CTO's nephew and all authors of the zillion libraries the app depends on learn the idiomatic way of handling resources and then rewrite everything using those" Crap code is crap code and exists in every language. I'm not sure what your point is. Most battle-tested libraries in Java properly use try-with-resources. If you work for a crap startup that uses crappy libraries, that's not a problem of the language itself. All this criticism of "the CTO's nephew" is a deflection of any conversation about benefits of drawbacks of individual languages since you just try to measure a language by its worst users.

vips7L 5y ago

How do you expect RAII to work in any GC language? It would be non-deterministic. The point of try-with-resources is that it is deterministic and you know when something is closed out. Every GC language has implemented this.

oriolid 5y ago
I would say that RAII is enforced try-with-resources without the extra syntax and releasing memory when resources are released instead of having a garbage collector is a nice performance optimization. C# with "using var" is on the right track, though. Just make RAII default and explicit close/dispose the special case and add syntax for type-deduced immutable values, and I'd be happy.

cogman10 5y ago

> No. I am the poor programmer whose manager forced me to use a library their nephew's dog or someone wrote that does all of those My condolences, that sucks. I'd still suggest using the profiling tools I've suggested to find these issues and create change requests to said libs. People will think you're a wizard if you simply learn how to use Java's telemetry. It's an invaluable skill. > Except using finalize for closing pipes for subprocesses, that was by Java standard library itself Java uses finalizers as a last resort, not a first line. Finalizers are due to be removed from the language so don't count on them being around for long. > And keeping references longer than needed, that is every library that implements clever caching, ever. Sure, caching is legitimate when the cost of creating exceeds the cost of long lived objects. Have you measured to see if the caches you have are improperly sized? Have you made pull requests/change requests to said libraries to fix it if it is? > Regarding try-with-resources, RAII was invented for a reason. Java did not copy it, because they seemed to seriously believe that GC is a good substitute. RAII was, few languages have it. The languages that don't have it generally don't have it because tracking the lifetime of objects in a GCed language can be extremely difficult. Consider, for example, how java would handle a destructor for an object allocated in one thread shared with multiple other threads. Do you know how C++/Rust/D solve that problem? Through a system of reference counted smart pointers which have to be handled very delicately. Java allows such objects to be freely moved. There are pros and cons to GCs (like most language features) so instead of just defaulting to "man, GCed languages suck because the finalizers aren't called when I want them to be!" perhaps it's a better route to learn the idiomatic way of handling resources and use that?

oriolid 5y ago
> People will think you're a wizard if you simply learn how to use Java's telemetry. It's an invaluable skill. People who want to hire me to fix their Java app think already think I am a wizard. The problem is, they stop believing me the moment I tell that Java is not a good language completely stop listening when I say that I will not work with it as long as I have other options. > Java uses finalizers as a last resort, not a first line. At the time it was the only option. Or, reading the JDK source revealed the undocumented feature that destroy() closes the pipes too. > Have you measured to see if the caches you have are improperly sized? Have you made pull requests/change requests to said libraries to fix it if it is? Wasn't the point of using JVM and pre-made libraries that they would work out of the box? Anyway, I have found out that terrible libraries are terrible because their authors either genuinely want them to be that way or because they do not recognize good code when they see it. If you have managed an open source project you should know that pull requests out of nowhere are mostly pure nonsense and tend to be ignored. > Do you know how C++/Rust/D solve that problem? I do, thank you for asking. As far as I understand, Java does not allow moving objects any more than copying a shared pointer or moving unique one does, but it pretends that objects have no ownership. > perhaps it's a better route to learn the idiomatic way of handling resources and use that? It does not solve the problem. The actual solution would be more like "magically make the CTO's nephew and all authors of the zillion libraries the app depends on learn the idiomatic way of handling resources and then rewrite everything using those".
- Tainnor 4y ago
  > People who want to hire me to fix their Java app think already think I am a wizard. The problem is, they stop believing me the moment I tell that Java is not a good language completely stop listening when I say that I will not work with it as long as I have other options. If people hire you to "fix their Java app" and you then subsequently bury your head in the sand and insist that this cannot be fixed (or you will not fix it) without rewriting it in another language - either you have been lying to them, or they were not listening to you. Regardless, you were probably not a good hire. It seems that you're trying to write Java as if it were C++. That will not work, so stop doing that. > "magically make the CTO's nephew and all authors of the zillion libraries the app depends on learn the idiomatic way of handling resources and then rewrite everything using those" Crap code is crap code and exists in every language. I'm not sure what your point is. Most battle-tested libraries in Java properly use try-with-resources. If you work for a crap startup that uses crappy libraries, that's not a problem of the language itself. All this criticism of "the CTO's nephew" is a deflection of any conversation about benefits of drawbacks of individual languages since you just try to measure a language by its worst users.