On Sat, 13 Sep 2003, Luke Palmer wrote:
Also, the "standard library", however large or small that will be, will definitely be mutable at runtime. There'll be none of that Java "you can't subclass String, because we think you shouldn't" crap.
Java's standard class library is a mishmash of things that represent containers (variables) and things that represent values (and even some broken things that try to be both), with no syntactic help to distinguish them. And its syntax reserves "const" but doesn't use it for anything.
As long as we have "is rw" and its friends, we can -- with suitable care -- make sure that a subclass of a value-representing class is also a value-representing class, so there's no semantic need to say "never any subclasses" but we can still do CSE and other neat stuff at compile time.
Of course having a "no subclasses" tag means the compiler can change a method call into a direct subroutine call, but I would hope that method calling will be fast enough that it won't need to.
A strategy to actually keep that optimization, and apply it to much more code, would be that the JIT compiler could optimize for the case that there are no known subclasses, and pessimize that only if a subclass were later loaded.
I think this is one of the features Leo's been on about with respect to notifications. The class loader could fire a notification that a new subclass had been loaded. The subroutine which needs to pessimize should its assumption be violated would observe that notification, so that it could discard its compiled form and be re-JITted when next invoked. (This gets harder when the routine is running, though. Prior art: A good 2 years of infuriating instability in the 1.4.x JDK after HotSpot was introduced.)
Even better, the JIT could optimize for the case that there are no known overrides of a method, which would allow this optimization to apply to much, much more code. Or it could mix the two for reduced overhead: Observe classWasSubclassed if there are no subclasses at compile time. If there are subclasses at compile time, but no overrides of the method which was invoked, observe methodWasOverridden instead.
These strategies get the best of both dynamism and performance whenever possible, not just when the programmer felt like hamstringing himself in advance by declaring a class or method to be final.
—
Gordon Henriksen [EMAIL PROTECTED]
