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:saturnism gmail.com]
Sent: Thursday, June 22, 2006 3:22 PM
To: java-devlucene.apache.org; simon.willnauergmail.com
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 <simon.willnauergooglemail.com> wrote:
> On 6/22/06, DM Smith <nessto555gmail.com> wrote:
> > On 6/22/06, Doug Cutting <cuttingapache.org> 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: java-dev-unsubscribelucene.apache.org
> For additional commands, e-mail: java-dev-helplucene.apache.org
>
>
------------------------------------------------------------
---------
To unsubscribe, e-mail: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org
------------------------------------------------------------
---------
To unsubscribe, e-mail: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org
|