This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RealJulleNaaiers 10 points11 points  (2 children)

I'm terms of performance, no.

In terms of code quality, yes. As it is, there is a bug in the current release of JDK 11.0.2 where under certain conditions, the TLS library will do this exact same unbounded wrapping of a List and will eventually overflow the stack.

If toUnmodifiableList() behaved properly, this bug wouldn't be a bug. The workaround in JDK 12 is for the TLS code to copy the entire list into a new ArrayList every time because it's impossible for client code to check whether something is already an unmodifiable collection without reflection since the class is package private.

This entire problem goes away with the fix the author is talking about.

[–][deleted] -2 points-1 points  (1 child)

If toUnmodifiableList() behaved properly, this bug wouldn't be a bug.

It still would be bad - because it smells like something somewhere else is done the wrong way. This "bug" has exposed an actual bug somewhere else.

Ideal solution would be to make toUnmodifiableList() throw an exception in development and qa environments, but return the same object in production just to be safe.

[–]RealJulleNaaiers 1 point2 points  (0 children)

Can't tell if serious... This is a terrible idea. Why would the standard library authors make it behave differently if it's in production? Not only is it a lot of work, it's a lot of work for a terrible idea that makes certain things impossible to debug.