On 6/22/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
DM Smith wrote: > In an earlier note, I suggested that there needs to be guidance as to how > Java 5 constructs are to be incorporated into code, contrib and core. > (Sooner or later, core will change to Java 5) Or does anything go? Once we decide to accept Java 5 code, we should of course encourage new contributions to use new language features that improve, e.g., type safety and maintainability. If someone wishes to upgrade existing code to use new language features, these should be done as separate contributions. We could state a goal of upgrading all existing code, but that won't make it happen. I prefer not to make ambitious roadmaps, but rather have things driven bottom-up, by contributors. So my bottom-up-oriented guideline is that I would not reject contributions that do nothing but upgrade existing code to use new language features. Is that the sort of guidance you seek, or do you think we need something more specific, with feature-by-feature guidelines? Developing such guidelines collaboratively might be difficult.
One of the things I liked about 2.0 was that 1.9 was a bridge to it from 1.4.3 via deprecations. It made migration fairly straightforward. I would like to see this going forward to 2.1. If so there needs to be some thought to how and whether the existing API will be deprecated in the same fashion as Java 5 is introduced. I was thinking more specific, feature-by-feature guidelines. There are not that many new language features, so I don't think that it would be too onerous. Since the committers are ultimately the ones to accept or reject a contribution, I think they can decide. For example (my opinions), Static Import Try to avoid. It tends to make code unreadable. Autoboxing/unboxing Use sparingly, and if used, provide test cases showing that performance sensitive code is not adversely affected. Varargs Don't use as a substitute for overloading. Use as a replacement for an array of objects. e.g. void f(T[] t) becomes void f(T... t). Enhanced for loops: Use whenever possible. When modifying existing code to add one, change all others, if possible. Typesafe Enum Use wherever possible, internally. Associate behavior with the enumerations when it makes sense. Replace existing enumerations that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Generics Use for all internal collections. When changing a class, ensure that the class is self consistent in its usage of generics. Enhance existing collections that are exposed via the API cautiously, maintaining compatibility with 2.0 as was done with 1.9's deprecations. Annotations: ??
