There are some big performance differences between the J2SE 5.0 concurrent package, and previous "outside" the JRE packages - the 1.5 JVM has some internal primitives that make the concurrent classes far more efficient.
-----Original Message----- From: Ray Tsang [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 3:22 PM To: java-dev@lucene.apache.org; [EMAIL PROTECTED] Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) 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.h tml 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
