All deprecated methods and fields have been removed, except DateField, which will still be supported for some time so Lucene can read its date fields from old indexesNote that Lucene 2.0 is not necessarily source-compatible with older versions; this may or may not be a good thing. (As the index page says: "Any code that compiles against Lucene 1.9.1 without deprecation warnings should work without further changes with any 2.x release.")
News: Lucene 2.0, search library, released
Lucene 2.0 has been released. The change from Lucene 1.9 is relatively small, with mostly bug fixes being applied; however, the deprecated methods and classes have been removed with one exception. From the changelog:
- Posted by: Joseph Ottinger
- Posted on: May 30 2006 09:18 EDT
- Re: Lucene 2.0, search library, released by Stephane Vaucher on May 30 2006 09:37 EDT
- congrats by ahmet a on May 30 2006 10:34 EDT
- Re: congrats by Guido Anzuoni on May 30 2006 11:31 EDT
- Ignoring backward-compatibility = Unrealistic programming by Hue Cheng on May 31 2006 05:26 EDT
- Re: Ignoring backward-compatibility = Unrealistic programming by Martijn Dashorst on June 01 2006 12:59 EDT
I love that library, it works like a charm. I'll have to try the newest version. cheers, Stephane Vaucher p.s. I would hope it's not fully compatible, it is after all a new **major** version.
Good news from Lucene , now have to update Red-Piranha which is based on it ...
Thanks for the release. Lucene is great. However, i wished it would use-require Java 5 instead. previous versions are good enough for old-timers. :P
Thanks for the release. Lucene is great. However, i wished it would use-require Java 5 instead. previous versions are good enough for old-timers. :PWhy ? What prevent you from using it in Java 5 env. Why should Lucene use Annotations or unreadable generic constructs ? Just to force happy Java 1.4.x users to move to Java 5 ? Strange world. Guido.
maybe a little misunderstanding here. of course it can be used in Java 5 apps. What i meant was to use it in the developement of the Lucene. i dont think Java5 is only about annotations and generic constructs. Besides, in my opinion usage of Generics in the public API's makes things better on users perspective. it provides better understanding of the API. Now instead of arrays, i can use collection objects on the return types easily witohut need for reading documentation. Of course it may give some difficulty on the API desginers, but i am assuming someoone who is designing a library API should be advanced enough to understand the issues.
However, if you do feel inclined to use annotations, check out Searchable (which will work with Lucene 2.0 in the next release, as well as incorporate some locking/performance optimizations).
Just want to say, many "old-timers" (like me) have to deal with applications that run on JDK 1.3, 1.4. All those using J2EE 1.3 containers, all those using WebSphere 5.x, all those using Tomcat 4.x,... That means if an enhancement of a common API cannot take backward-compatibility into an account, it just cut its user base off. (Only those new-timers/college-boy can make use of it.) Doesn't make sense at all. JDK 1.5 is nice. It is a pretty big milestone for Java. But we need to understand that the industry has to take time, do changes, and face business impacts when welcoming this milestone. When do so, backward-compatibility is a must.
At what point should the industry move forward then? If no library moves to Java 5, then what will be the incentive to start using Java5 on a server platform? Java 5 has been with us for almost 2 years. That some vendor is very late with its own version of Java 5 is very unfortunate and has held the industry back. Java 5 has many improvements other than the annotations and generics, such as much better performance. At some point we have to move forward. Preferrably before mustang ships.