Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking java.lang.String

wouter.coekaerts.be

Post reply on HN
Print view View original

71–80 of 206 posts

Re: Breaking java.lang.String

#71

Post by layer8 »

cogman10 wrote: post #2

This 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…

This doesn’t help when the parameter is one of the collection interfaces, or CharSequence, or the like. You always need to defensively copy their contents first to “freeze“ their values.

Re: Breaking java.lang.String

#72

Post by tialaramex »

thfuran wrote: post #15
malfist wrote: post #5

Earlier quoted context omitted.

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

That's instantiating a List, not an array.

As you would expect in a vaguely modern language, Java's "List" interface is typically backed by a growable array as the type ArrayList. Only people who have no idea about caches would think List should necessarily be some sort of Linked List type.

You would use Collections.unmodifiableList to make it unmodifiable.

Re: Breaking java.lang.String

#73

Post by tialaramex »

kaba0 wrote: post #60
thfuran wrote: post #16

Earlier quoted context omitted.

Java definitely does "you wrote thread dangerous code, so it's your fault" for APIs not marked as being thread safe.

For what it's worth, Java does at least give some guarantees in case of data races -- the observed value will always be one that was explicitly set by one thread. This is different from most other languages, e.g. in C,C++, unsafe Rust it is UB. Of course it can and still will result in invalid states.

> Of course it can and still will result in invalid states.

While of course they can't stop you from creating "invalid" states of your own types, whether through a data race or just bad coding - Java's own types should not have invalid states which can come into existence this way.

For example, suppose we've got a Goose type, and it can be Happy or Sad, and when it's Sad it has a Reason, when it is Happy there's no Reason. We, as Java, should not design this type so that it's possible for it to get flipped from Happy to Sad without choosing a Reason. As a result, after a race the Goose might be Happy when you expected Sad, or vice versa, but it can't enter the invalid state where it's Sad but for no Reason.

Re: Breaking java.lang.String

#74

Post by layer8 »

josephcsible wrote: post #3

This 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".

Arguably, C++ arguably already solved that specific problem with const safety. I was flabbergasted back in 1995 that Java had dropped that notion.

Re: Breaking java.lang.String

#75

Post by coekie »

gizmo686 wrote: post #14

Is this actually a bug? The default assumption in Java is that types are not thread-safe unless otherwise specified. Attempting to use types in a way that exceeds their documented thread safety has always been allowed to leave your program in an inconsistent state.

Author of the blog here. Yes, this is a bug. While the javadoc doesn't state it explicitly, immutable classes in the core library are expected to be thread safe. Java tries to be and mostly succeeds at being a safe language, where (by default) the guarantees of its internals cannot be broken no matter what user code does. The JVM preserves its own integrity.

There are some other deliberate holes in that safety, such as using reflection to access private members, and instrumentation, where it is clear you are stepping outside the safety zone, but even that is getting locked down now with the "Integrity and Strong Encapsulation" effort https://openjdk.org/jeps/8305968 .

In general, most code we write would not (and should not) try to protect against such abuse, but classes in the core platform play by different rules.

Btw, this has been accepted into the bug database now: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-831190... . I expect this to be fixed in a future release.

Re: Breaking java.lang.String

#76

Post by tialaramex »

kaba0 wrote: post #69
tialaramex wrote: post #64

Earlier quoted context omitted.

> how one might implement an optimization library in Rust where you have uninitiated elements The correct way to do this is use the MaybeUninit type. Then you're responsible for correctly initializing a T before you call MaybeUninit ::assume_init() to get a T.

And that MaybeUninit type uses an unsafe call under the hood as an escape hatch from the "draconian" compiler's rules. Every practical language has these. (nonetheless, thanks for mentioning the MaybeUninit, that was what I was thinking of, but didn't remember the name -- I haven't programmed in Rust for a long time)

MaybeUninit::assume_init() is the unsafe call. The promise that this is actually a T and not just a T-sized blob of uninitialized memory is made by that unsafe call, and since it's unsafe it's your responsibility as the programmer to obey the constraint, that this is, in fact, an initialized T.

Depending on how long "a long time" is, you might well not actually have been thinking of MaybeUninit. The prior solution (until mid-2019) was as you describe, and it was in fact unsound.

Re: Breaking java.lang.String

#77

Post by kaba0 »

tialaramex wrote: post #76
kaba0 wrote: post #69

Earlier quoted context omitted.

And that MaybeUninit type uses an unsafe call under the hood as an escape hatch from the "draconian" compiler's rules. Every practical language has these. (nonetheless, thanks for mentioning the MaybeUninit, that was what I was thinking of, but didn't remember the name -- I haven't programmed in Rust for a long time)

MaybeUninit ::assume_init() is the unsafe call. The promise that this is actually a T and not just a T-sized blob of uninitialized memory is made by that unsafe call, and since it's unsafe it's your responsibility as the programmer to obey the constraint, that this is, in fact, an initialized T. Depending on how long "a long time" is, you might well not actually have been thinking of MaybeUninit. The prior solution (…

The point I was trying to convey (badly) with this example is that in both the assign to raw generic and assume_init case, the developer overrides the compiler's knowledge for his/her, demonstrating that most languages have similar escape hatches, because they are sometimes simply needed.

Re: Breaking java.lang.String

#78

Post by [deleted] »

kaba0 wrote: post #45
gizmo686 wrote: post #25

Earlier quoted context omitted.

As the article points out, the only thing the Javadoc guarantees is the subsequent modifications of the character array have no effect. It says nothing about concurrent modifications. The type whose thread safety is in question here is not actually String, but char[]. I'm not going to say it is always wrong to share char[] between threads (as a primitive array of something other than double and long, the Java Spec do…

While you are technically right in all your points, I think you exaggerate the problems regarding Java’s type system. Arrays are indeed a pain point from different times (the mistake of their covariance even “infected” C#), but generics are not problematic at all. In fact, code that compiles without warning is guaranteed to never get a ClassCastException. Every language’s type system gives you escape hatches, so that…

[deleted]

Re: Breaking java.lang.String

#79

Post by cowsandmilk »

tialaramex wrote: post #72
thfuran wrote: post #15

Earlier quoted context omitted.

That's instantiating a List, not an array.

As you would expect in a vaguely modern language, Java's "List" interface is typically backed by a growable array as the type ArrayList. Only people who have no idea about caches would think List should necessarily be some sort of Linked List type. You would use Collections.unmodifiableList to make it unmodifiable.

Collections.unmodifiableList doesn’t prevent anyone who has a reference to the original List (or the array behind it) from modifying the List. Calling that in the constructor would not help.

Re: Breaking java.lang.String

#80

Post by erik_seaberg »

gene91 wrote: post #67
pulse7 wrote: post #49

Earlier quoted context omitted.

I remember a bug in Visual/Digitalk Smalltalk: conversion from integer to string (method printString) was not thread safe, because it used global buffer for better performance. Very rarely - when we used a progress indicator in another thread (called Process in Visual Smalltalk) - this global buffer was overriden by another integer to string conversion... It took a year to find out the reason why our code sometimes g…

I don’t know the terminology for it. But the behavior that you just described isn’t just “not thread safe”. It’s violating basic assumptions. I’d call that hostile or a trap.

A function that can’t be called while it’s already running is “non-reentrant.” strtok used to work this way (before thread-locals), and some languages predating C that used globals instead of stack frames.
Post reply on HN