"Carl Mäsak" wrote: > ] Oh, but it gets even better: it turns out they didn't really have to > ] sneak in through native code anyway, at least as far as the JVM is > ] concerned, since the JVM treats final variables as always writable > to ] the class they're defined in! There's no special case for > ] constructors: they're just always writable. The javac compiler, on > ] the other hand, pretends that they're only assignable once, either > in ] static init code for static finals or once per constructor for > ] instance variables. It also will optimize access to finals, despite > ] the fact that it's actually unsafe to do so.
I'm pleased to note that you made my point for me. Sure, you can sneak in under the covers of the JVM and compromise the immutability of its final data. But you do have to sneak in. And when you do, and things go belly up in interesting ways, or worse continue to run but produce mysteriously wrong output, don't go running to blame either the Java spec or the JVM. Their writers made their optimisations, and the proofs of correctness of those optimisations, and proof of correctness of the entire system, based upon the specification of final. You hack it. Your problem. But, if you add *is ro* to the P6 spec and then specify a way for users to ignore or turn it off, and you render it entirely worthless. Indeed it's worse than worthless because it is extra complication for no benefit. If it doesn't allow the compiler writeres to make any extra assumptions, it's just tying up space in symbol tables, consuming cycles in the parser, and most damningly, mindspace in the spec and users. If you add it to the spec. Mean it. If you don't mean it, don't add it. If you mean it, but it doesn't initially get implemented that's fine. Someday it might and someday we might benefit from it. Add it to the spec whilst offering a way to ignore it and you've wasted everyones time. b. --
