lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: [jira] Commented: (LUCENE-1257) Port to Java5
Date Wed, 11 Nov 2009 00:29:29 GMT
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 :-( (a lot of are already broken).

Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen


From: Erick Erickson [] 
Sent: Wednesday, November 11, 2009 1:27 AM
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....


On Tue, Nov 10, 2009 at 7:08 PM, Uwe Schindler (JIRA) <>

n_12776184> &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:
>             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-CheckIndex.patch, LUCENE-1257-CloseableThreadLocal.patch,
LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
LUCENE-1257-FieldCacheImpl.patch, LUCENE-1257-FieldCacheRangeFilter.patch,
LUCENE-1257-iw.patch, LUCENE-1257-MTQWF.patch,
LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.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_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_precendence_parser.patch, LUCENE-1257_queryParser_jj.patch,
LUCENE-1257_unnecessary_casts.patch, LUCENE-1257_unnnecessary_casts_2.patch,
lucene1257surround1.patch, lucene1257surround1.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
> 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:
For additional commands, e-mail:


View raw message