Keep in mind that if Avian had been packaged before it supported the new "every String gets its own char array" implementation, it would have needed to be updated anyway -- not just rebuilt but patched, since it previously relied on the assumption that char arrays could be shared.
There's no way in principle to provide perfect future compatibility, since future versions of OpenJDK could break any kind of assumption currently made by the VM, not just field offsets. For example, if String were to be changed to use int arrays instead of char arrays, I'm sure all existing VMs -- not just Avian -- would need to be patched and rebuilt. Finally, if a field offset changes in a core class that the VM knows about, that means a field has been added or removed. It's probably not safe from a security or stability standpoint to just assume that an old version of the VM can adapt to that field addition or removal without source code changes. I would even argue that it *should* fail loudly and immediately so as to draw attention to the possibility of a broken assumption in the source code. Do you know of any past security updates that have added or removed fields in core classes like String? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1047389 Title: java -avian sigsegv on startup if used with a different OpenJDK 7 compared to the one it got built against. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avian/+bug/1047389/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
