3 ms·

Yes: https://news.ycombinator.com/item?id=9862556 https://news.ycombinator.com/item?id=9862556

vardump 11y ago
That's a bit scary. Some of older Java code relies a bit too much on substring not copying. I think most devs understood it pins the original String char[] buffer until all references are gone.
- pjmlp 11y ago
  That was always a JVM specific behavior. Like C, any dev that makes language assumptions based on the installed compiler, is bound to get burned.
  - joosters 11y ago
    Really? Does java offer no cost guarantees for library functions? If a given method might be O(1) or O(n) at the whim of the JVM, programmers are doomed to failure.
    - pjmlp 11y ago
      Everything not mentioned here is implementation specific: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/
    - jerven 11y ago
      Even worse, with partial evaluation or escape analysis it might still be non allocating to use a substring call today. So the thing about advanced compilers in the java world is that they use defined behaviour(results) to do optimisations. And the best optimisations are about not doing work you can avoid. i.e. if you can avoid doing an allocation at all because the (sub)string you just created is only used locally, the object might not be allocated at all (heap|stack) but just registers are reassigned with temporary values needed to calculate the function. So its already common to have O(n) semantics turn into O(1) or even better O(0) ;). In the java world results are specced, not how you need to get them. (Exceptions to this rule exist).
  - Dylan16807 11y ago
    The implementation being completely rewritten is fine. Nobody should rely on internal fields or details of function calls. The implementation changing to be asymptotically worse is not fine. Also they could have changed the garbage collector to make both cases perform well. Edit: And the comments you linked have a good point made in them, if you don't assume some bounds on how long a function is going to take, you can't call it ever. substr is not a function that's supposed to be forbidden.
    - lmm 11y ago
      Asymptotics aren't a practical bound on anything - a function documented as being O(1) could still take ten thousand years. In practice outside of hard realtime systems all functions are best-effort and we confirm acceptable performance empirically rather than having any explicit guarantees. I do think a language that made it explicit exactly how long any given function would take would be a good thing, but that would be a much bigger undertaking than Rust's borrow checker.

That's a bit scary. Some of older Java code relies a bit too much on substring not copying. I think most devs understood it pins the original String char[] buffer until all references are gone.

pjmlp 11y ago
That was always a JVM specific behavior. Like C, any dev that makes language assumptions based on the installed compiler, is bound to get burned.
- joosters 11y ago
  Really? Does java offer no cost guarantees for library functions? If a given method might be O(1) or O(n) at the whim of the JVM, programmers are doomed to failure.
  - pjmlp 11y ago
    Everything not mentioned here is implementation specific: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/
  - jerven 11y ago
    Even worse, with partial evaluation or escape analysis it might still be non allocating to use a substring call today. So the thing about advanced compilers in the java world is that they use defined behaviour(results) to do optimisations. And the best optimisations are about not doing work you can avoid. i.e. if you can avoid doing an allocation at all because the (sub)string you just created is only used locally, the object might not be allocated at all (heap|stack) but just registers are reassigned with temporary values needed to calculate the function. So its already common to have O(n) semantics turn into O(1) or even better O(0) ;). In the java world results are specced, not how you need to get them. (Exceptions to this rule exist).
- Dylan16807 11y ago
  The implementation being completely rewritten is fine. Nobody should rely on internal fields or details of function calls. The implementation changing to be asymptotically worse is not fine. Also they could have changed the garbage collector to make both cases perform well. Edit: And the comments you linked have a good point made in them, if you don't assume some bounds on how long a function is going to take, you can't call it ever. substr is not a function that's supposed to be forbidden.
  - lmm 11y ago
    Asymptotics aren't a practical bound on anything - a function documented as being O(1) could still take ten thousand years. In practice outside of hard realtime systems all functions are best-effort and we confirm acceptable performance empirically rather than having any explicit guarantees. I do think a language that made it explicit exactly how long any given function would take would be a good thing, but that would be a much bigger undertaking than Rust's borrow checker.