Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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


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


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


Why does it break the implementation, other than performance?


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: