12 ms·

Wow. This is a pretty big bug. The official bug report: https://bugs.openjdk.java.net/browse/JDK-8204322 https://bugs.openjdk.java.net/browse/JDK-8204322 as Stu

Wow. This is a pretty big bug. The official bug report: https://bugs.openjdk.java.net/browse/JDK-8204322 https://bugs.openjdk.java.net/browse/JDK-8204322 as Stuart Marks, a jvm architect, posted. I'm surprised it stayed uncaught for so long. For the unfamiliar, the way string concatenation is compiled changed with invokedynamic. Previously, it would compile to either Sting.concat calls or transform into a StringBuilder, but with invoke dynamic we can leave it to the runtime to optimize when it first runs.

lern_too_spel 8y ago
Is it really surprising? Nobody is running production workloads on Java 9 pr 10 because neither of them are LTS releases.
- dionian 8y ago
  Does this only apply to shops that cannot easily upgrade to 12 once it's out? Or are there other support-related problems with adopting 9/10 for production for server-side apps?
  - IloveHN84 8y ago
    We are using it in production. Even if it isn't LTS, does it make sense to.stay on the 8, which will be end of life soon anyway? At least, programming using modules makes the codebase ready for Java 11. The only thing that I don't like is the removal of javapackager without substituting it (jlink cannot produce bundles with applications, only a light redistributed image)
    - haglin 8y ago
      I believe there is a JEP to fix that, but it doesn't say if it will make JDK 11. http://openjdk.java.net/jeps/8200758 http://openjdk.java.net/jeps/8200758
  - mabn 8y ago
    If you upgrade to 9 and then to 12 then you'll need to do this dance twice..
- twic 8y ago
  I am, and i know other people who are. I'll be interested to see how the LTS situation shakes out for people not paying for Oracle support. I know some people who aren't bothering with LTSs, and are planning to upgrade every six months.
dtech 8y ago
> I'm surprised it stayed uncaught for so long. I'm not surprised. Java 9 has minor adoption, and having side effects on the left hand side of an assignment operation is really really bad practice. So you'd need a codebase that (1) was updated or written in a very new Java version, (2) contained the smelly code and (3) had a harmful double side-effect that got noticed. That's a pretty rare combination.
- coredog64 8y ago
  Oracle broke compression in Tomcat 7.x in 8u151/152 and didn't fix it until 171/172 [0]. That was 6 months, so nothing Oracle does surprises me. [0] Allegedly the fix was available in a non-public build of 8u162
  - dionian 8y ago
    I dunno if this is entirely Oracle's fault though... https://bugs.java.com/view_bug.do?bug_id=JDK-8189789 https://bugs.java.com/view_bug.do?bug_id=JDK-8189789
- kllrnohj 8y ago
  > having side effects on the left hand side of an assignment operation is really really bad practice. No it isn't. Something like this: data[index++] += 'a' Would easily pass any reasonable code review. It's not that smelly or unusual. It might be unusual with strings, which makes this less common, but it's not an unusual format at all. It's a non-trivial part of the reason ++ operator exists in the first place.
  - ehaliewicz2 8y ago
    It's very different when you can see the side effect right there, vs happening somewhere else entirely.
  - kazinator 8y ago
    Plus: since Java has ordered evaluation, that tends to encourage side effects in expressions, since they are well defined. (Unless, as we can see, someone doesn't know what they are doing in compiler maintenance, but I mean besides that.)
cup-of-tea 8y ago
> I'm surprised it stayed uncaught for so long. You haven't heard of the bug in binary search that existed for nine years then? https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html?m=1 https://ai.googleblog.com/2006/06/extra-extra-read-all-about...
- recursive 8y ago
  This new bug is much easier to trigger accidentally.
ballenf 8y ago
Edit: This is obviously a bug and needs to be fixed. My post is more about how the syntax "+=" is usually explained as shorthand for "x = x + 1" (https://www.tutorialspoint.com/java/java_basic_operators.htm https://www.tutorialspoint.com/java/java_basic_operators.htm), when it's not strictly true (depends on what's in "x"). "+=" is [usually explained as] shorthand for repeating the left side. Why should > foo[i++] += 1 evaluate differently than > foo[i++] = foo[i++] + 1 ? The way it currently works is the way I would expect it to work, but I'm evidently in the minority here. I also don't write Java and since this is a change from Java 8, it needs to be fixed. Let me state that again: yes, of course this bug needs to be fixed.
- lotyrin 8y ago
  I understand this point and it's true that there would be some elegance if both statements were equivalent but I see greater utility without that equivalence: Rather than a redundancy and sugar on + and = ("I do not want to type the left side twice"), it is a distinction I am making to the compiler ("I do not want you to evaluate the left side twice").
- jjnoakes 8y ago
  > The way it currently works is arguably the way it should work, irrespective of the spec. The spec is how it should work, regardless of developer's opinions. > Why should [a] evaluate differently than [b]? In my opinion (and I'm guessing in the opinion of the spec authors, though I can't be sure), saying "x += y" means "add y to x", so I'd expect the language to: 1) Figure out what "x" is once 2) Add "y" to it Your opinion seems to be that saying "x += y" means "desugar to x = x + y" and you expect the language to: 1) Figure out what "x" is as a value 2) Add "y" to the value of "x" 3) Figure out what "x" is as a location (which may differ from 1) 4) Store the result into "x" To me step 3 is very surprising, that "x" may differ, which is why I think the spec's definition is the more intuitive one (plus, it doesn't require knowledge of "desugaring" things).
  - deleted 8y ago
    [deleted]
- 8y ago
didymospl 8y ago
This is a quite embarrassing bug because it affects probably the most used class in Java. However I think using += for the Strings is not that popular among experienced developers because they want to be sure that no unnecessary Strings are created in the pool. I assume the execution times would be similar with the optimizations you mentioned, but according to Effective Java(3rd edition, published this year) using += for Strings in the loop is still 6,5 times slower than using StringBuilder. I need to check it myself.
- on_and_off 8y ago
  AFAIK the compiler already uses a builder for you. At least on Android, but I believe this optim is in javac, not in the dexer.

lern_too_spel 8y ago

Is it really surprising? Nobody is running production workloads on Java 9 pr 10 because neither of them are LTS releases.

dionian 8y ago
Does this only apply to shops that cannot easily upgrade to 12 once it's out? Or are there other support-related problems with adopting 9/10 for production for server-side apps?
- IloveHN84 8y ago
  We are using it in production. Even if it isn't LTS, does it make sense to.stay on the 8, which will be end of life soon anyway? At least, programming using modules makes the codebase ready for Java 11. The only thing that I don't like is the removal of javapackager without substituting it (jlink cannot produce bundles with applications, only a light redistributed image)
  - haglin 8y ago
    I believe there is a JEP to fix that, but it doesn't say if it will make JDK 11. http://openjdk.java.net/jeps/8200758 http://openjdk.java.net/jeps/8200758
- mabn 8y ago
  If you upgrade to 9 and then to 12 then you'll need to do this dance twice..
twic 8y ago
I am, and i know other people who are. I'll be interested to see how the LTS situation shakes out for people not paying for Oracle support. I know some people who aren't bothering with LTSs, and are planning to upgrade every six months.

dtech 8y ago

> I'm surprised it stayed uncaught for so long. I'm not surprised. Java 9 has minor adoption, and having side effects on the left hand side of an assignment operation is really really bad practice. So you'd need a codebase that (1) was updated or written in a very new Java version, (2) contained the smelly code and (3) had a harmful double side-effect that got noticed. That's a pretty rare combination.

coredog64 8y ago
Oracle broke compression in Tomcat 7.x in 8u151/152 and didn't fix it until 171/172 [0]. That was 6 months, so nothing Oracle does surprises me. [0] Allegedly the fix was available in a non-public build of 8u162
- dionian 8y ago
  I dunno if this is entirely Oracle's fault though... https://bugs.java.com/view_bug.do?bug_id=JDK-8189789 https://bugs.java.com/view_bug.do?bug_id=JDK-8189789
kllrnohj 8y ago
> having side effects on the left hand side of an assignment operation is really really bad practice. No it isn't. Something like this: data[index++] += 'a' Would easily pass any reasonable code review. It's not that smelly or unusual. It might be unusual with strings, which makes this less common, but it's not an unusual format at all. It's a non-trivial part of the reason ++ operator exists in the first place.
- ehaliewicz2 8y ago
  It's very different when you can see the side effect right there, vs happening somewhere else entirely.
- kazinator 8y ago
  Plus: since Java has ordered evaluation, that tends to encourage side effects in expressions, since they are well defined. (Unless, as we can see, someone doesn't know what they are doing in compiler maintenance, but I mean besides that.)

cup-of-tea 8y ago

> I'm surprised it stayed uncaught for so long. You haven't heard of the bug in binary search that existed for nine years then? https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html?m=1 https://ai.googleblog.com/2006/06/extra-extra-read-all-about...

recursive 8y ago
This new bug is much easier to trigger accidentally.

ballenf 8y ago

Edit: This is obviously a bug and needs to be fixed. My post is more about how the syntax "+=" is usually explained as shorthand for "x = x + 1" (https://www.tutorialspoint.com/java/java_basic_operators.htm https://www.tutorialspoint.com/java/java_basic_operators.htm), when it's not strictly true (depends on what's in "x"). "+=" is [usually explained as] shorthand for repeating the left side. Why should > foo[i++] += 1 evaluate differently than > foo[i++] = foo[i++] + 1 ? The way it currently works is the way I would expect it to work, but I'm evidently in the minority here. I also don't write Java and since this is a change from Java 8, it needs to be fixed. Let me state that again: yes, of course this bug needs to be fixed.

lotyrin 8y ago
I understand this point and it's true that there would be some elegance if both statements were equivalent but I see greater utility without that equivalence: Rather than a redundancy and sugar on + and = ("I do not want to type the left side twice"), it is a distinction I am making to the compiler ("I do not want you to evaluate the left side twice").
jjnoakes 8y ago
> The way it currently works is arguably the way it should work, irrespective of the spec. The spec is how it should work, regardless of developer's opinions. > Why should [a] evaluate differently than [b]? In my opinion (and I'm guessing in the opinion of the spec authors, though I can't be sure), saying "x += y" means "add y to x", so I'd expect the language to: 1) Figure out what "x" is once 2) Add "y" to it Your opinion seems to be that saying "x += y" means "desugar to x = x + y" and you expect the language to: 1) Figure out what "x" is as a value 2) Add "y" to the value of "x" 3) Figure out what "x" is as a location (which may differ from 1) 4) Store the result into "x" To me step 3 is very surprising, that "x" may differ, which is why I think the spec's definition is the more intuitive one (plus, it doesn't require knowledge of "desugaring" things).
- deleted 8y ago
  [deleted]
8y ago

didymospl 8y ago

This is a quite embarrassing bug because it affects probably the most used class in Java. However I think using += for the Strings is not that popular among experienced developers because they want to be sure that no unnecessary Strings are created in the pool. I assume the execution times would be similar with the optimizations you mentioned, but according to Effective Java(3rd edition, published this year) using += for Strings in the loop is still 6,5 times slower than using StringBuilder. I need to check it myself.

on_and_off 8y ago
AFAIK the compiler already uses a builder for you. At least on Android, but I believe this optim is in javac, not in the dexer.