/**A Term represents a word from text.  This is the unit of search.  It iscomposed of two elements, the text of the word, as a string, and the name ofthe field that the text occurred in.Note that terms may represent more than words from text fields, but alsothings like dates, email addresses, urls, etc.  */

/*** Expert: directly create a field for a document.  Most* users should use one of the sugar subclasses: * <ul>*    <li>{@link TextField}: {@link Reader} or {@link String} indexed for full-text search*    <li>{@link StringField}: {@link String} indexed verbatim as a single token*    <li>{@link IntPoint}: {@code int} indexed for exact/range queries.*    <li>{@link LongPoint}: {@code long} indexed for exact/range queries.*    <li>{@link FloatPoint}: {@code float} indexed for exact/range queries.*    <li>{@link DoublePoint}: {@code double} indexed for exact/range queries.*    <li>{@link SortedDocValuesField}: {@code byte[]} indexed column-wise for sorting/faceting*    <li>{@link SortedSetDocValuesField}: {@code SortedSet<byte[]>} indexed column-wise for sorting/faceting*    <li>{@link NumericDocValuesField}: {@code long} indexed column-wise for sorting/faceting*    <li>{@link SortedNumericDocValuesField}: {@code SortedSet<long>} indexed column-wise for sorting/faceting*    <li>{@link StoredField}: Stored-only value for retrieving in summary results* </ul>** <p> A field is a section of a Document. Each field has three* parts: name, type and value. Values may be text* (String, Reader or pre-analyzed TokenStream), binary* (byte[]), or numeric (a Number).  Fields are optionally stored in the* index, so that they may be returned with hits on the document.** <p>* NOTE: the field type is an {@link IndexableFieldType}.  Making changes* to the state of the IndexableFieldType will impact any* Field it is used in.  It is strongly recommended that no* changes be made after Field instantiation.*/

/** Documents are the unit of indexing and search.** A Document is a set of fields.  Each field has a name and a textual value.* A field may be {@link org.apache.lucene.index.IndexableFieldType#stored() stored} with the document, in which* case it is returned with search hits on the document.  Thus each document* should typically contain one or more stored fields which uniquely identify* it.** <p>Note that fields which are <i>not</i> {@link org.apache.lucene.index.IndexableFieldType#stored() stored} are* <i>not</i> available in documents retrieved from the index, e.g. with {@link* ScoreDoc#doc} or {@link IndexReader#document(int)}.*/

/*** Information about a segment such as its name, directory, and files related* to the segment.** @lucene.experimental*/

/*** Base class for Directory implementations that store index* files in the file system.  * <a name="subclasses"></a>* There are currently three core* subclasses:** <ul>**  <li>{@link SimpleFSDirectory} is a straightforward*       implementation using Files.newByteChannel.*       However, it has poor concurrent performance*       (multiple threads will bottleneck) as it*       synchronizes when multiple threads read from the*       same file.**  <li>{@link NIOFSDirectory} uses java.nio's*       FileChannel's positional io when reading to avoid*       synchronization when reading from the same file.*       Unfortunately, due to a Windows-only <a*       href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734">Sun*       JRE bug</a> this is a poor choice for Windows, but*       on all other platforms this is the preferred*       choice. Applications using {@link Thread#interrupt()} or*       {@link Future#cancel(boolean)} should use*       {@code RAFDirectory} instead. See {@link NIOFSDirectory} java doc*       for details.*        *  <li>{@link MMapDirectory} uses memory-mapped IO when*       reading. This is a good choice if you have plenty*       of virtual memory relative to your index size, eg*       if you are running on a 64 bit JRE, or you are*       running on a 32 bit JRE but your index sizes are*       small enough to fit into the virtual memory space.*       Java has currently the limitation of not being able to*       unmap files from user code. The files are unmapped, when GC*       releases the byte buffers. Due to*       <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038">*       this bug</a> in Sun's JRE, MMapDirectory's {@link IndexInput#close}*       is unable to close the underlying OS file handle. Only when*       GC finally collects the underlying objects, which could be*       quite some time later, will the file handle be closed.*       This will consume additional transient disk usage: on Windows,*       attempts to delete or overwrite the files will result in an*       exception; on other platforms, which typically have a &quot;delete on*       last close&quot; semantics, while such operations will succeed, the bytes
 *       are still consuming space on disk.  For many applications this*       limitation is not a problem (e.g. if you have plenty of disk space,*       and you don't rely on overwriting files on Windows) but it's still*       an important limitation to be aware of. This class supplies a*       (possibly dangerous) workaround mentioned in the bug report,*       which may fail on non-Sun JVMs.* </ul>** <p>Unfortunately, because of system peculiarities, there is* no single overall best implementation.  Therefore, we've* added the {@link #open} method, to allow Lucene to choose* the best FSDirectory implementation given your* environment, and the known limitations of each* implementation.  For users who have no reason to prefer a* specific implementation, it's best to simply use {@link* #open}.  For all others, you should instantiate the* desired implementation directly.** <p><b>NOTE:</b> Accessing one of the above subclasses either directly or* indirectly from a thread while it's interrupted can close the* underlying channel immediately if at the same time the thread is* blocked on IO. The channel will remain closed and subsequent access* to the index will throw a {@link ClosedChannelException}.* Applications using {@link Thread#interrupt()} or* {@link Future#cancel(boolean)} should use the slower legacy* {@code RAFDirectory} from the {@code misc} Lucene module instead.** <p>The locking implementation is by default {@link* NativeFSLockFactory}, but can be changed by* passing in a custom {@link LockFactory} instance.** @see Directory*/

    Analyzer analyzer = new StandardAnalyzer();// Store the index in memory:Directory directory = new RAMDirectory();// To store an index on disk, use this instead://Directory directory = FSDirectory.open("/tmp/testindex");IndexWriterConfig config = new IndexWriterConfig(analyzer);IndexWriter iwriter = new IndexWriter(directory, config);Document doc = new Document();String text = "This is the text to be indexed.";doc.add(new Field("fieldname", text, TextField.TYPE_STORED));iwriter.addDocument(doc);iwriter.close();// Now search the index:DirectoryReader ireader = DirectoryReader.open(directory);IndexSearcher isearcher = new IndexSearcher(ireader);// Parse a simple query that searches for "text":QueryParser parser = new QueryParser("fieldname", analyzer);Query query = parser.parse("text");ScoreDoc[] hits = isearcher.search(query, null, 1000).scoreDocs;assertEquals(1, hits.length);// Iterate through the results:for (int i = 0; i < hits.length; i++) {Document hitDoc = isearcher.doc(hits[i].doc);assertEquals("This is the text to be indexed.", hitDoc.get("fieldname"));}ireader.close();directory.close();