On Thu, Sep 17, 2009 at 9:34 AM, Joshua Marinacci <jos...@marinacci.org>wrote:
> > (warning, this is long). > > > It's easier to invent a new language than improve the old one for the > same reason it's far faster and cheaper to build a brand new road then > to do minor repairs on an existing road that's *in use*. This is just > the nature of software. Once something ships and is used by customers > it instantly becomes legacy. And the more people use it the harder it > becomes to change. Over the last 30 years of software development > we've come up with lots of tricks to address this, but it's still a > very hard problem with no easy answers. > Yes, there is always a balance between stability and progress. When a platform is new, much of its value is that it is new, different, and presumably better than existing platforms in some way. As a platform gets widely used, some of the value delivered by the platform transitions to keeping the code which uses the platform working. The compatibility policies used to evolve the JDK [1] aim to keep source and class files working while also improving the capabilities of the platform. However, the wide use of the JDK does impose some behavioral compatibility constraints. Two examples from JDK 5, for a time javac switched from using "$" between the component names of local and anonymous classes to using "+". The names of local and anonymous classes are a contract the compiler keeps with itself; unlike nested member classes, local and anonymous classes can't be referred to outside of the declaring context. [2] While using "$" in this way is not specified anywhere, people came to rely on that convention over the years and numerous build systems broke with the switch to "+" so we reverted to using "$". Also in JDK 5, the private int value field in java.lang.Integer was switched to being "final" to play better with the memory model and similar changes were made to the other wrapper classes. Unfortunately, a program widely used at the time relied on being able to write these *private* fields. The addition of final was reverted for a time and reapplied later in JDK 5 after the misbehaving external program was fixed. Developers can rely on many of these accidental details of the platform implementation. One benefit of adding a module system to the platform is that more of such details can be hidden, making evolving the platform easier. -Joe [1] "JDK Release Types and Compatibility Regions"* *http://blogs.sun.com/darcy/entry/release_types_compatibility_regions [2] "Nested, Inner, Member, and Top-Level Classes" http://blogs.sun.com/darcy/entry/nested_inner_member_and_top --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
