4 ms·

Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandator

Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandatory as per spec, I'm not sure how it'd change the outcome of evaluation.

maverwa 3y ago
yeah, I'd assume as much. If it indeed falls back to a by-value comparison it would be slower, but should work.
- xxs 3y ago
  nope - it'd be plain wrong. Literals must be equal by reference, comparing them by value would just break JLS, as they would be equal to any other composed string by reference as well.
robertlagrant 3y ago
Yes - that is a performance optimisation. I don't think comparing everything by value makes or breaks the implementation.
- xxs 3y ago
  >I don't think comparing everything by value makes or breaks the implementation. Nothing much to think -- distinct objects must have distinct references [e.g. new String("a")!=new String("a')], literals must have the same references for the same values [e.g. "a"=="a"].
  - robertlagrant 3y ago
    Why does it break the implementation, other than performance?
thfuran 3y ago
It affects the result of ==, which is only a reference comparison.
simiones 3y ago
The problem is that, per the spec, the following must hold: if("abc" == "abc") { System.out.println("correct"); } if(new String("abc") != new String("abc")) { System.out.println("correct"); } So, not having proper string interning support means that you mis-execute certain programs.
- kelnos 3y ago
  Sure, but also consider that this JVM (intentionally) lacks support for other things that all but the most trivial programs would use. I don't think it's expected by the author that you can throw any random program at it. It's really there just to run your own programs that you've written specifically for it in order to play around with things. And since you know you're writing for this particular JVM, you should know not to do anything that depends on string interning, among other things.

maverwa 3y ago

yeah, I'd assume as much. If it indeed falls back to a by-value comparison it would be slower, but should work.

xxs 3y ago
nope - it'd be plain wrong. Literals must be equal by reference, comparing them by value would just break JLS, as they would be equal to any other composed string by reference as well.

robertlagrant 3y ago

Yes - that is a performance optimisation. I don't think comparing everything by value makes or breaks the implementation.

xxs 3y ago
>I don't think comparing everything by value makes or breaks the implementation. Nothing much to think -- distinct objects must have distinct references [e.g. new String("a")!=new String("a')], literals must have the same references for the same values [e.g. "a"=="a"].
- robertlagrant 3y ago
  Why does it break the implementation, other than performance?

thfuran 3y ago

It affects the result of ==, which is only a reference comparison.

simiones 3y ago

The problem is that, per the spec, the following must hold: if("abc" == "abc") { System.out.println("correct"); } if(new String("abc") != new String("abc")) { System.out.println("correct"); } So, not having proper string interning support means that you mis-execute certain programs.

kelnos 3y ago
Sure, but also consider that this JVM (intentionally) lacks support for other things that all but the most trivial programs would use. I don't think it's expected by the author that you can throw any random program at it. It's really there just to run your own programs that you've written specifically for it in order to play around with things. And since you know you're writing for this particular JVM, you should know not to do anything that depends on string interning, among other things.