I agree. This is probably the first compelling argument that I would agree with the use of 1.5. IIRC, Concurrent utils were available for the 1.4 available at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html before it was accepted into official 1.5 util package. It is continuing to be maintained right now.
I'm also supportive about Doug's base-guideline. As far as annotation goes, I really don't see future uses of annotations within the internal code. It would most likley end up being used by the user to annotate a POJO for as a document maybe. ray, On 6/22/06, Simon Willnauer <[EMAIL PROTECTED]> wrote:
On 6/22/06, DM Smith <[EMAIL PROTECTED]> wrote: > 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: > ?? > > I assume that many people realize these features as new features in Java 5.0. In my opinion there is at least one more feature beside the improvements inside the jvm and the garbage collection and build in Java Management Extension. The feature I'm pointing to is rather a new library than a feature to be honest but it can improve concurrent application in performance and stability matters. The Concurrent Utils in the j2se 5.0 give you much more control of concurrent parts of you application and I guess the lucene project can gain from these new classes to synchronize writing and parallel reading where possible. I think a great deal of adding build in JMX support to the lucene core or rather as a contrib project to enable modification of configurable components like merge factors or similar things. Extensions like this should have some guidelines as Doug said feature-by-feature. Java 1.5 is much more than type save collection and a lot of "features" are quiet hidden sometimes. Replacing the use of StringBuffer with StringBuilder can also gain some performance improvements, this just as an example that improved parts of the api are quiet important and should be considered first before moving in all the "nice" compile time code sharing generics. regards Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
