lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-1257) Port to Java5
Date Wed, 11 Nov 2009 00:37:51 GMT
this was the similar to the discussion we had at apachecon, where i wanted
to create a jira issue as Uwe Schindler<some invisible unicode space> and
suggest a patch to reformat all of contrib!

(would never attribute such a thing to my name but this formatting issue
consistently gets in my way)

On Tue, Nov 10, 2009 at 7:29 PM, Uwe Schindler <uwe@thetaphi.de> wrote:

>  Yes this one is new, but it is almost the default Java 1.5 style with
> tabs=2chars and the modified generics formatting.
>
>
>
> I know about the reformatting method in Eclipse, but that would break more
> patches now L (a lot of are already broken).
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>   ------------------------------
>
> *From:* Erick Erickson [mailto:erickerickson@gmail.com]
> *Sent:* Wednesday, November 11, 2009 1:27 AM
> *To:* java-dev@lucene.apache.org
> *Subject:* Re: [jira] Commented: (LUCENE-1257) Port to Java5
>
>
>
> About formatting. I know the "how to contribute" section of the Wiki warns
> against gratuitous reformatting, but if *someone* with commit privileges
> wanted to, they could  format an entire tree in Eclipse from the context
> menu of, say, the contrib directory. It'd have to be coordinated for a
> moment when not too many others were editing the code...
>
> I mention this since we're doing a bunch of non-functional changes for the
> 3.0 release, and it might be a reasonable thing to do so future commits were
> easier to compare, at least after the reformatting was done. As long as
> we're all using the same formatting, it might be worthwhile.
>
> Somebody mentioned uploading a new codestyle.xml for Eclipse. Were there
> any changes or is this just getting the one from SOLR up there? Because I'm
> using IntelliJ....
>
> Erick
>
> On Tue, Nov 10, 2009 at 7:08 PM, Uwe Schindler (JIRA) <jira@apache.org>
> wrote:
>
>
>    [
> https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776184#action_12776184]
>
>
> Uwe Schindler commented on LUCENE-1257:
> ---------------------------------------
>
> Kay Kay: We only have SuppressWarnings at some places in core, marked with
> a big TODO (will be done when flex indeixng comes). The "wanted"
> @SuppressWarnings are only at places, where generic Arrays are created.
> There is no way to fix this (see Sun Generics Howto).
>
>
> > Port to Java5
> > -------------
> >
> >                 Key: LUCENE-1257
> >                 URL: https://issues.apache.org/jira/browse/LUCENE-1257
> >             Project: Lucene - Java
> >          Issue Type: Improvement
> >          Components: Analysis, Examples, Index, Other, Query/Scoring,
> QueryParser, Search, Store, Term Vectors
> >    Affects Versions: 3.0
> >            Reporter: C├ędric Champeau
> >            Assignee: Uwe Schindler
> >            Priority: Minor
> >             Fix For: 3.0
> >
> >         Attachments: instantiated_fieldable.patch,
> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch,
> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch,
> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CloseableThreadLocal.patch,
> LUCENE-1257-CompoundFileReaderWriter.patch,
> LUCENE-1257-ConcurrentMergeScheduler.patch,
> LUCENE-1257-DirectoryReader.patch,
> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch,
> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
> LUCENE-1257-FieldCacheImpl.patch, LUCENE-1257-FieldCacheRangeFilter.patch,
> LUCENE-1257-IndexDeleter.patch,
> LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch,
> LUCENE-1257-iw.patch, LUCENE-1257-MTQWF.patch,
> LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-SegmentInfos.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-TopDocsCollector.patch, LUCENE-1257-WordListLoader.patch,
> LUCENE-1257_analysis.patch, LUCENE-1257_BooleanFilter_Generics.patch,
> LUCENE-1257_contrib_benchmark.patch, LUCENE-1257_contrib_benchmark_2.patch,
> LUCENE-1257_contrib_highlighting.patch, LUCENE-1257_contrib_memory.patch,
> LUCENE-1257_contrib_misc.patch, LUCENE-1257_contrib_smartcn.patch,
> LUCENE-1257_javacc_upgrade.patch, LUCENE-1257_lucil.patch,
> LUCENE-1257_lucli.patch, LUCENE-1257_messages.patch,
> LUCENE-1257_more_unnecessary_casts.patch,
> LUCENE-1257_MultiFieldQueryParser.patch,
> LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch,
> LUCENE-1257_o_a_l_demo.patch, LUCENE-1257_o_a_l_index_test.patch,
> LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch,
> LUCENE-1257_o_a_l_search_spans.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_precendence_parser.patch, LUCENE-1257_queryParser_jj.patch,
> LUCENE-1257_swing_wikipedia_wordnet_xmlqp.patch,
> LUCENE-1257_unnecessary_casts.patch, LUCENE-1257_unnnecessary_casts_2.patch,
> lucene1257surround1.patch, lucene1257surround1.patch,
> shinglematrixfilter_generified.patch
> >
> >
> > For my needs I've updated Lucene so that it uses Java 5 constructs. I
> know Java 5 migration had been planned for 2.1 someday in the past, but
> don't know when it is planned now. This patch against the trunk includes :
> > - most obvious generics usage (there are tons of usages of sets, ...
> Those which are commonly used have been generified)
> > - PriorityQueue generification
> > - replacement of indexed for loops with for each constructs
> > - removal of unnececessary unboxing
> > The code is to my opinion much more readable with those features (you
> actually *know* what is stored in collections reading the code, without the
> need to lookup for field definitions everytime) and it simplifies many
> algorithms.
> > Note that this patch also includes an interface for the Query class. This
> has been done for my company's needs for building custom Query classes which
> add some behaviour to the base Lucene queries. It prevents multiple
> unnnecessary casts. I know this introduction is not wanted by the team, but
> it really makes our developments easier to maintain. If you don't want to
> use this, replace all /Queriable/ calls with standard /Query/.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>



-- 
Robert Muir
rcmuir@gmail.com

Mime
View raw message