Breaking java.lang.String
wouter.coekaerts.be
Breaking java.lang.String
1–10 of 206 posts
Re: Breaking java.lang.String
#2This is exactly why java needs frozen arrays [1].
The safe thing to do is freeze the array before doing anything with it. Then, you can rely on COW to copy to the array if someone is modifying it concurrently with you reading it. In the general case, you'd have fast string creation and in the tricky case you simply pay the clone cost as a penalty for being dumb.
[1] https://openjdk.org/jeps/8261007#:~:text=How%20do%20I%20use%...
Re: Breaking java.lang.String
#3This is the exact kind of bug that Rust solves with its borrowing system. The problem is that Java has no way to express the concept of "something that nothing else can modify while I'm looking at it".
Re: Breaking java.lang.String
#4This is the exact kind of bug that Rust solves with its borrowing system. The problem is that Java has no way to express the concept of "something that nothing else can modify while I'm looking at it".
Mutexes etc ... exist in Java.
Re: Breaking java.lang.String
#5This is exactly why java needs frozen arrays [1]. The safe thing to do is freeze the array before doing anything with it. Then, you can rely on COW to copy to the array if someone is modifying it concurrently with you reading it. In the general case, you'd have fast string creation and in the tricky case you simply pay the clone cost as a penalty for being dumb. [1] https://openjdk.org/jeps/8261007#:~:text=How%20do%2…
Java does have immutable collections. It's just not an explicit type.
Lots of common ways to instantiate arrays (i.e. Arrays.asList) generate immutable lists
Re: Breaking java.lang.String
#6This is the exact kind of bug that Rust solves with its borrowing system. The problem is that Java has no way to express the concept of "something that nothing else can modify while I'm looking at it".
Mutexes etc ... exist in Java.
Right, but in rust, not using one is a compile time error. In Java (as you can see by the article), not using one is a silent bug at runtime.
Re: Breaking java.lang.String
#7Every time, without fail, somebody shows a bug about a piece of code that we take for granted (In this case, the String class) the bug is related to concurrent modifications.
Concurrency is so hard that even OpenJDK developers can't prevent these kind of bugs
Re: Breaking java.lang.String
#8This is the exact kind of bug that Rust solves with its borrowing system. The problem is that Java has no way to express the concept of "something that nothing else can modify while I'm looking at it".
Mutexes etc ... exist in Java.
Yes, but Java will happily accept code that doesn't use them where it needs to, leading to bugs like this one. Rust catches that mistake at compile time instead.
Re: Breaking java.lang.String
#9Earlier quoted context omitted.
Mutexes etc ... exist in Java.
Right, but in rust, not using one is a compile time error. In Java (as you can see by the article), not using one is a silent bug at runtime.
This is a heavily optimized system library - you don’t use mutexes here. Rust wouldn’t help here, if mutexes would be fine, they would have been used. Especially that this is the result of C++ and Java code simultaneously.
Hell, it’s probably one area where rust’s benefits are a “hard sell” — you would have to constantly be in unsafe rust manipulating pointers manually as the compiler can’t reason statically about what a layer built on top does without a huge runtime cost (huge, as in you really don’t want to lock/unlock, or even refcount in these hot paths).
Re: Breaking java.lang.String
#10Earlier quoted context omitted.
Right, but in rust, not using one is a compile time error. In Java (as you can see by the article), not using one is a silent bug at runtime.
This is a heavily optimized system library - you don’t use mutexes here. Rust wouldn’t help here, if mutexes would be fine, they would have been used. Especially that this is the result of C++ and Java code simultaneously. Hell, it’s probably one area where rust’s benefits are a “hard sell” — you would have to constantly be in unsafe rust manipulating pointers manually as the compiler can’t reason statically about wh…
Huh? This is exactly where Rust would help. In Rust the caller of the constructor would either have to add mutex if they needed concurrency, or just use the constructor without mutex overhead if they did not.