Return-Path: X-Original-To: apmail-lucene-java-user-archive@www.apache.org Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F0839D7BF for ; Wed, 29 Aug 2012 19:29:34 +0000 (UTC) Received: (qmail 11267 invoked by uid 500); 29 Aug 2012 19:29:32 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 11199 invoked by uid 500); 29 Aug 2012 19:29:32 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 11055 invoked by uid 99); 29 Aug 2012 19:29:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 19:29:32 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of benson@basistech.com designates 209.85.212.48 as permitted sender) Received: from [209.85.212.48] (HELO mail-vb0-f48.google.com) (209.85.212.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 19:29:24 +0000 Received: by vbme21 with SMTP id e21so1264026vbm.35 for ; Wed, 29 Aug 2012 12:29:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=s4ojFF8UZojDJsBl08KsUKHylgno23XO+N+JE8JltIA=; b=fpEO98xJDlw9TZJ9noXkt4gxpjP+mkLhe8eDBYwzVO7bc29oINpygA/jyj5FiY6pRZ D1kMJKcLr26RT9r9Egs412oSUzc+Vomc6R6dpe8uy2M5u5pULEbUDDMT3KXjLtlSDAtC fZlWmkQIghyevaEaud211LvbfpEzfn6UbPiUsLI+FaHYVdlzlyYAk0Z3I9DN1ycO7B6B zi5xy0ONihpHq/IRouYqnC7DLl7bVmp8p0VJ3MYtiJpmq91TAgPuKDcnJ+eYpQDiSaJi DcSjC1cE1GJAFcPPcX2EZMQePSNhsqrIG25LIjKcVTHN2MpGlPwN98aXeJhTaCIcMTWP o4Nw== MIME-Version: 1.0 Received: by 10.58.12.41 with SMTP id v9mr1806289veb.17.1346268543454; Wed, 29 Aug 2012 12:29:03 -0700 (PDT) Received: by 10.58.211.194 with HTTP; Wed, 29 Aug 2012 12:29:03 -0700 (PDT) Date: Wed, 29 Aug 2012 15:29:03 -0400 Message-ID: Subject: reset versus setReader on TokenStream From: Benson Margulies To: java-user@lucene.apache.org Content-Type: multipart/alternative; boundary=047d7b417dd74e0c9304c86c92cb X-Gm-Message-State: ALoCoQkfKIX+GYKRUpK3ri2gL0tu9WZxEr/RrNZmD62BjRg8vGI+tyLH8ZpU5pgJDM0LUxPG5Nnl --047d7b417dd74e0c9304c86c92cb Content-Type: text/plain; charset=UTF-8 I've read the javadoc through a few times, but I confess that I'm still feeling dense. Are all tokenizers responsible for implementing some way of retaining the contents of their reader, so that a call to reset without a call to setReader rewinds? I note that CharTokenizer doesn't implement #reset, which leads me to suspect that I'm not responsible for the rewind behavior. --047d7b417dd74e0c9304c86c92cb--