Comment by kaba0
3 years ago
While I do love Rust-style resource management, Java’s try-with-resources blocks plus cleaners are not particularly worse.
3 years ago
While I do love Rust-style resource management, Java’s try-with-resources blocks plus cleaners are not particularly worse.
Try-with-resources is tied to a lexical scope. C++/Rust RAII is not, you can move the resource e.g to another thread after initialization, and that thread can outlive the scope that created the resource. Also C++/Rust allows shared ownership through recounted references, something try-with-resources can't do.
Cleaners aren't deterministic, so that's meaningfully worse than rust's resource mgt. Java's try with resources cleanup only works if the resource is freed up before the callstack is unwound. Currently that's only viable for the most trivial of scenarios. Loom will make that applicable in more places but still not as widely applicable as a borrow checker/rc based deterministic resource management.
What about if you want your resource to be longer lived, but still safely disposed of in a timely manner when it goes out of scope, for example a port in a webserver class? Do you have to keep the stack alive here to keep the resource, or can you put it into an object somewhere to get a more RAII style resource management?
Could a Java version of the future maybe also manage memory with a try-with-resources block ?
Your wish is granted :D
https://openjdk.org/jeps/424
Though there was nothing inherent to ever block you from doing it (just create an object that implements Closeable, and malloc in the constructor, free in the close method), this new API makes it quite great. The basic API gives you a SegmentScope which denotes a lifetime, and MemorySegments that point to a memory region (pointer+size+layout+scope). MemorySegments have both spatial and temporal safety, so accessing memory out of boundary will only throw an exception instead of corrupting memory, while any access outside the lifetime of the scope is forbidden. Oh, and they are also thread-safe, only optionally being shared between threads.
So in practice it you can write something like
That's a nice improvement over sun.misc.Unsafe .
Nice. Thank you for pointing that out.
Java and the JVM has a garbage collector, and will likely always have, and GC makes memory management a lot simpler and safer, so while you could use try-with-resources for some kind of memory related resource, it likely would not be to make things safer, but to make things less safe and faster, and if you start doing that you will have significantly reduced safety compared to rust I think.