Lucene 2.9 erklärt einige altbekannte Klassen und Methoden des Frameworks als "deprecated" und stellt die nun bevorzugten neuen Werkzeuge daneben (siehe Lucene Change Log [2]). In dem geplanten Release 3.0 werden dann einige Funktionen nur noch in neuer Form zur Verfügung stehen. Das aktuelle Release präsentiert ein API im Übergang [3]. An mehreren Stellen treten abstrakte Oberklassen auf den Plan, wo vorher Interfaces oder nicht-abstrakte Implementierungen vorlagen.
Empfohlene Route
Ausdrücklich wird empfohlen, nicht einfach die alten JARs gegen die der 2.9 Version auszutauschen, sondern auf jeden Fall das eigene Projekt zu re-kompilieren und neu gegen Lucene 2.9 zu "linken". Es steht zu erwarten, dass nicht wenige "deprecated"-Warnungen erscheinen, wie ein kurzer Praxistest zeigt. Nutzt man Subclassing von Lucene-Klassen oder implementiert selber Lucene Interfaces kann man so herausfinden, wo sich die Lucene-Klassenhierarchie inkompatibel geändert hat.Dies wird ein gutes Gefühl dafür geben, welche Arbeit mit Erscheinen von Version 3.0 unerlässlich werden wird, will man die enthaltenen Verbesserungen nutzen.
Deprecated
Ein IndexReader wird über die statische open()-Factory-Methode erzeugt, von denen es in 2.4 ganze neun verschiedene gab. Fünf davon sind nun deprecated. In 2.9 sind es jetzt insgesamt 14 überladene open-Varianten, wobei aber acht davon deprecated sind. Das bedeutet, es sind sogar welche hinzugekommen, die unmittelbar mit Einführung als deprecated gekennzeichnet worden sind - verwirrend.Die Konstruktor-Deprecation-Orgie geht beim StandardAnalyzer, einer der zentralen Klassen beim Indizieren und Abfragen, weiter. Diese Klasse hat nun keinen Argumenten-losen Konstruktor mehr, was vielleicht einige Downstream-Libraries zum Stolpern bringen könnte, die ihren Analyzer über eine Property, welche den Klassennamen enthält, dynamisch instanziieren. Stattdessen muss ein Version-Objekt mitgegeben werden, um sich für Kompatibilität zu 2.4 oder 2.9 festzulegen. Sowohl der VERSION_24- als auch der VERSION_29-Parameter sind aber ihrerseits deprecated - sehr verwirrend! VERSION_CURRENT ist damit die einzige sichere Investition in die Zukunft, ein Wert, dem man durchaus auch als Vorbelegung in einem Zero-Argument-Konstruktor Vertrauen geschenkt hätte.
Zum Schreiben eines Indexes braucht es eine IndexWriter-Instanz. Auch hier sind die meisten der 19 möglichen Konstruktoren kurz davor, aufs Altenteil gelegt zu werden.
Ähnliches gilt für FSDirectory, eine wichtige Klasse, um Lucene zu sagen, wo es den Index finden kann. Außerdem wird FSDirectory mit Lucene 3.0 eine abstrakte Klasse werden, die konkrete Implementierung ist neuerdings SimpleFSDirectory (neben den sonstigen Varianten, die es weiterhin gibt).
