well implement public close(), nobody's gonna
see this method from outside anyway.
> Make all classes that have a close() methods instanceof Closeable (Java 1.5)
>
>
> Key: LUCENE-1945
all classes that have a close() methods instanceof Closeable (Java 1.5)
>
>
> Key: LUCENE-1945
> URL: https://issues.apache.org/jira/browse/LUCENE-1945
> Proj
-classes that define
close(). Package-private classes inside oal.index are not changed (as they
often only define package-private close())
Will commit soon.
> Make all classes that have a close() methods instanceof Closeable (Java
Make all classes that have a close() methods instanceof Closeable (Java 1.5)
Key: LUCENE-1945
URL: https://issues.apache.org/jira/browse/LUCENE-1945
Project: Lucene - Java
ious comment on LUCENE-1936 really was just me wanting to stay out of
your way, not the other way around :)
> When we move to java 1.5 in 3.0 we should replace all Interger, Long, etc
> construction wit
ging caused by this!
Pfff - so many good merge tools out there today, lets not let that get in the
way of this sweet rapid movement to java 1.5!
If anyone is annoyed, I'd be happy to merge any patch for them.
> When we move to java 1.5 in 3.0 we should replace all Interger, Long, etc
&g
caused by this!
> When we move to java 1.5 in 3.0 we should replace all Interger, Long, etc
> construction with .valueOf
>
>
> Key: LUCENE-1833
>
parts with "Number.valueOf(" (changed
using find/sed). All tests pass.
I want to commit this as soon as possible, because it affects lots of files and
I do not want to get this patch outdated. The StringBuffer from previous
comment is in another issue.
> When we move to java 1.5 in 3.
[
https://issues.apache.org/jira/browse/LUCENE-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reassigned LUCENE-1833:
-
Assignee: Uwe Schindler
> When we move to java 1.5 in 3.0 we should replace
we move to java 1.5 in 3.0 we should replace all Interger, Long, etc
> construction with .valueOf
>
>
> Key: LUCENE-1833
> URL: https://issues.apache.
When we move to java 1.5 in 3.0 we should replace all Interger, Long, etc
construction with .valueOf
Key: LUCENE-1833
URL: https://issues.apache.org/jira/browse
1.5 JDK
Only those with 1.5, all other contribs together with core. So add something
-Djavac.target to ant, that specifies what to compile and test. If it is 1.4,
all 1.5 contribs are left out.
In my opinion, this is too late to change. After 2.9 will come 3.0 with Java
1.5 support. As noted in
I guess hudson lets you define
this quite flexible.
simon
> Analysis package calls Java 1.5 API
> ---
>
> Key: LUCENE-1724
> URL: https://issues.apache.org/jira/browse/LUCENE-1724
> Project: Luc
-718.
> Analysis package calls Java 1.5 API
> ---
>
> Key: LUCENE-1724
> URL: https://issues.apache.org/jira/browse/LUCENE-1724
> Project: Lucene - Java
> Issue Type: Improvement
>
if a
*method/class* is available in 1.4, as it only knows his own rt.jar (normally
it could e.g. use the @since javadoc tag, but this is not includedin the rt.jar
and an annotation is not available). This is a well known problem to all java
developers.
> Analysis package calls Java
does still not catch this. Who is the hudson
admin? We should change the JVM to a 1.4 VM on hudson if possible. If we need
to send a request to infrastructure I could do so.
simon
> Analysis package calls Java 1.5 API
> ---
>
>
to
CharacterCache to remind us to move to the 1.5 APIs, and replaced the <= 127
with < cache.length.
> Analysis package calls Java 1.5 API
> ---
>
> Key: LUCENE-1724
> URL: https://issues.apache.org/ji
[
https://issues.apache.org/jira/browse/LUCENE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1724:
--
Assignee: Michael McCandless
> Analysis package calls Java 1.5
[
https://issues.apache.org/jira/browse/LUCENE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-1724:
Attachment: CharacterCache.patch
> Analysis package calls Java 1.5
Analysis package calls Java 1.5 API
---
Key: LUCENE-1724
URL: https://issues.apache.org/jira/browse/LUCENE-1724
Project: Lucene - Java
Issue Type: Improvement
Components: Analysis
at 7:00 PM, Uwe Schindler wrote:
Because Hudson compiles with Java 1.5 or even 1.6. Setting -source
and
-target to 1.4 in javac does not help, if you are using methods/
classes. The
java compiler only checks syntax and creates 1.4 classes. But for
compiling
and checking it uses the builtin r
The solution could we easier. Hudson has the possibility to define a
specific VM for each different bulid job. If can configure the build
job you can define the used VM.
Simon
On Fri, Jun 12, 2009 at 7:00 PM, Uwe Schindler wrote:
> Because Hudson compiles with Java 1.5 or even 1.6. Sett
x all core, contrib, tests to not use those APIs, release, and
>>>> immediately begin accepting 1.5 patches.
>>>>
>>>
>>> personally, I wonder if anyone but me is interested in correcting the
>>> issue that unicode character no longer fits in java 'char&#
Because Hudson compiles with Java 1.5 or even 1.6. Setting -source and
-target to 1.4 in javac does not help, if you are using methods/classes. The
java compiler only checks syntax and creates 1.4 classes. But for compiling
and checking it uses the builtin rt.jar (which is newer).
If you want
correcting the
>> issue that unicode character no longer fits in java 'char' in java 1.5
>> :)
>>
>> maybe I am the only one, but i still think its correctness issue...,
>> and will require changing some apis, even if its just char->int
>
> I think
More importantly, why is Hudson not catching it?
On Jun 12, 2009, at 11:28 AM, Michael McCandless wrote:
Sigh. I'll fix. I should just leave my world on 1.4 until we get
3.0 out...
Mike
On Fri, Jun 12, 2009 at 11:14 AM, Grant
Ingersoll wrote:
It seems JDK 1.5+ is the de facto for darn
> personally, I wonder if anyone but me is interested in correcting the
> issue that unicode character no longer fits in java 'char' in java 1.5
> :)
>
> maybe I am the only one, but i still think its correctness issue...,
> and will require changing some apis, even if its
Sigh. I'll fix. I should just leave my world on 1.4 until we get 3.0 out...
Mike
On Fri, Jun 12, 2009 at 11:14 AM, Grant Ingersoll wrote:
> It seems JDK 1.5+ is the de facto for darn near everyone...
>
> ant compile-test with JDK 1.4 yields:
>
> common.compile-test:
> [javac] Compiling 82 so
It seems JDK 1.5+ is the de facto for darn near everyone...
ant compile-test with JDK 1.4 yields:
common.compile-test:
[javac] Compiling 82 source files to .../lucene/java/clean/build/
classes/test
[javac] /Users/grantingersoll/projects/lucene/java/clean/src/test/
org/apache/lucene/sea
that unicode character no longer fits in java 'char' in java 1.5
:)
maybe I am the only one, but i still think its correctness issue...,
and will require changing some apis, even if its just char->int
--
Robert Muir
rcm...@gmail.com
--
Thanks guys!
On Fri, Jun 12, 2009 at 2:10 PM, Grant Ingersoll wrote:
>
> On Jun 12, 2009, at 3:50 AM, Simon Willnauer wrote:
>
>> hey there,
>> I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
>> I guess enums, generics etc) and discussions about
On Jun 12, 2009, at 3:50 AM, Simon Willnauer wrote:
hey there,
I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
I guess enums, generics etc) and discussions about back-compat policy.
I'm curious if there is a kind of a roadmap or a document where I can
get up-to-date
g. Eclipse.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Friday, June 12, 2009 12:33 PM
> To: java-dev@lucene.apache.org; simon.willna...@gmail.com
> Subject: Re: 3.0,
On Fri, Jun 12, 2009 at 3:50 AM, Simon
Willnauer wrote:
> I'm curious if there is a kind of a roadmap or a document where I can
> get up-to-date with all those targets and especially what we want to
> achieve in 3.0.
I don't think we have such a doc...
I think "the plan" at this point is quite s
hey there,
I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
I guess enums, generics etc) and discussions about back-compat policy.
I'm curious if there is a kind of a roadmap or a document where I can
get up-to-date with all those targets and especially what we wa
On Mon, Dec 15, 2008 at 07:04:08AM -0500, Michael McCandless wrote:
> These are good points: it may be exposing too much if we fully expose
> SegmentReader now, since some components (deletion tombstones) may
> want to skip that API and operate directly on lower level files.
After thinking things
Sounds good. I often wondered about using IntelliJ's "Generify"
refactor, too, but haven't tried it.
On Dec 17, 2008, at 3:35 AM, Paul Cowan wrote:
Just for the record, to pick up this point of Grant's:
Grant Ingersoll wrote:
IIRC, we also agreed that we didn't feel any compelling reason to
Just for the record, to pick up this point of Grant's:
Grant Ingersoll wrote:
IIRC, we also agreed that we didn't feel any compelling reason to make a
sweeping change to generics, but would likely just add them as we see
'em, unless of course someone wants to do a wholesale patch.
I'll go o
Marvin Humphrey wrote:
I have a bunch of file format changes to push through, and I'm
hoping to
implement them using pluggable modules. For instance, I'd like to
be able to
swap out bit-vector-based deletions for tombstone-based deletions,
just by
overriding a method or two.
I think Lu
> For return parameters, I think you should return the most specific interface
> you can give to the user (without fixing to something you may change in
> future versions). Maybe a user wants to use the return value of getFields()
> as List? If it's only Iterable, he cannot e.g. access the list dir
s. But this would not be backwards compatible.
>
> Or even Iterable, which is new to Java 1.5 and usually makes more sense in
> a read-only context.
> Iterable could have also been used instead of List as a return value in
> method like Document.getFields() and so on, but again, this wou
On Sun, Dec 14, 2008, Uwe Schindler wrote about "RE: 2.9/3.0 plan & Java 1.5":
> A side note: there are some parts in Lucene's API that are not so good: very
> old constructors of Analyzer use e.g. Hashtable/HashMap/ArrayList/Vector/...
> as parameter etc. For clean co
velopment effort, in my opinion. I'd be much happier to
> rewrite half of my code each major release than limp along with some
> ugly stuff just for the sake of someone dropping in a new lucene jar
> into their mess and exclaiming - "Wow! It still works!"
:-)
> > Another
lease than limp along with some
ugly stuff just for the sake of someone dropping in a new lucene jar
into their mess and exclaiming - "Wow! It still works!"
But excuse me, I wasn't going to stir up old arguments.
> Another step to Java 1.5 would be the use of Enum instead of Pa
dd(vacancy.getEmployerCategory(), EMPLOYER_CATEGORY);
> Query it:
> return FilterTerm(EMPLOYER_CATEGORY, complementOf(EnumSet.of(AGENCY)));
>
> any field access is type-checked at compile time and happily
> autocompletes in IDE
You are right, too, but this change needs modifications in the Luc
.de
>> eMail: u...@thetaphi.de
>>
>>> -Original Message-
>>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>>> Sent: Sunday, December 14, 2008 12:31 PM
>>> To: java-dev@lucene.apache.org
>>> Subject: Re: 2.9/3.0 plan &a
2.9/3.0 plan & Java 1.5
Uwe Schindler wrote:
EG I haven't yet tested for JAR drop-in compatibility, eg if in 3.1
we
wanted to swap in more generics, would a 3.0 app be able to drop in
the 3.1 Lucene jar w/o problems?
It should, because in the compiled JVM code, generics do simply not
-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Sunday, December 14, 2008 12:31 PM
> To: java-dev@lucene.apache.org
> Subject: Re: 2.9/3.0 plan & Java 1.5
>
&g
Uwe Schindler wrote:
EG I haven't yet tested for JAR drop-in compatibility, eg if in 3.1
we
wanted to swap in more generics, would a 3.0 app be able to drop in
the 3.1 Lucene jar w/o problems?
It should, because in the compiled JVM code, generics do simply not
appear.
A, right. So
-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Yonik Seeley [mailto:ysee...@gmail.com]
> Sent: Saturday, December 13, 2008 11:16 PM
> To: java-dev@lucene.apache.org
> Subject: Re: 2.9/3.0 plan & Java 1.5
>
> Parame
run a very old java class file using the
collection API with generics in Java 1.5 or 6. So you see, the best example
is Java itself.
Old programs e.g. link to ArrayList, but Java 1.5 has ArrayList.
The program will simply run, there changed nothing in the code semantics,
only in compile time semant
Parametrization of return types should be fully back compatible.
Parameterization of input parameters would be run-time compatible (due
to type erasure), but not compile-time compatible.
-Yonik
On Sat, Dec 13, 2008 at 5:07 PM, Michael McCandless
wrote:
>
> Grant Ingersoll wrote:
>
>> IIRC, we al
Grant Ingersoll wrote:
IIRC, we also agreed that we didn't feel any compelling reason to
make a sweeping change to generics, but would likely just add them
as we see 'em, unless of course someone wants to do a wholesale patch.
I like that approach.
In the case of generics, I see no reason
Doug Cutting:
> Folks are discussing whether generics are a special case for
> back-compatibility. This is an important discussion, since major
> releases are defined by their back-compatibility. This discussion thus
> should have priority over the discussion of new 3.0 features.
Okeedoke.
Jason Rutherglen wrote:
Decoupling IndexReader would for 3.0 would be great. This includes
making public SegmentReader, MultiSegmentReader.
A constructor like new SegmentReader(TermsDictionary termDictionary,
TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
Where
ecate what will be changed in 2.9.
>>
>> I could easily be confused on this... but I thought 3.0 is the first
>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>
>> Meaning, we could in theory intro APIs with generics with 3.0,
>> deprecat
I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics with 3.0,
deprecating the non-generics versions, and then 4.0 (sounds insanely
far away!) would be the first release that could remove the
deprecat
3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics with 3.0,
deprecating the non-generics versions, and then 4.0 (sounds insanely
far away!) would be the first release that could remove the
deprecated
ess mabye that won't end up happening, if it was going
to, it
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in
eems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics with 3.0,
deprecating the non-generics ve
e API to java
>>> > 5 for the 3.0 release, cause I thought back compat was less restricted
>>> > 2-3. I guess mabye that won't end up happening, if it was going to, it
>>> > seems we'd want to deprecate what will be changed in 2.9.
>>>
>>&
s less
restricted
> 2-3. I guess mabye that won't end up happening, if it was going
to, it
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg gener
ess mabye that won't end up happening, if it was going
to, it
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we coul
ppening, if it was going to, it
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics wi
t
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics with 3.0,
deprecating the non-
t 11:31 AM, Karl Wettin wrote:
I have problems getting this build.xml of mine to accept java 1.5
in tests. I compiles the source with generics and all that just
fine, but the tests fail with the error javac -source 1.4 is set.
Well..
Extended spell checker with phrase support and ada
tting this build.xml of mine to accept java 1.5
in tests. I compiles the source with generics and all that just
fine, but the tests fail with the error javac -source 1.4 is set.
Well..
Extended spell checker with phrase support and adaptive user
session analysis.
What
I have problems getting this build.xml of mine to accept java 1.5 in
tests. I compiles the source with generics and all that just fine,
but the tests fail with the error javac -source 1.4 is set. Well..
Extended spell checker with phrase support and adaptive user
session analysis
Chuck Williams wrote:
I think the last discussion ended with the main counter-argument being
lack of support by gjc. Current top of GJC News:
*June 6, 2006* RMS approved the plan to use the Eclipse compiler as
the new gcj front end. Work is being done on the |gcj-eclipse| branch;
it can alread
On Tue, 11 Jul 2006, robert engels wrote:
It's been years and GCJ still doesn't have anywhere near full 1.4 classpath
libraries.
So now if we want to write code for Lucene we have to know what libraries are
available for GCJ?
GCJ is a joke.
It looks like classpath is quite close to 100%
It's been years and GCJ still doesn't have anywhere near full 1.4
classpath libraries.
So now if we want to write code for Lucene we have to know what
libraries are available for GCJ?
GCJ is a joke.
On Jul 11, 2006, at 8:54 AM, Andi Vajda wrote:
On Tue, 11 Jul 2006, DM Smith wrote:
Ec
On Tue, 11 Jul 2006, DM Smith wrote:
Eclipse has a built in compiler called ecj and it can compile Java 1.6 code
today. However, unless classes are provided at runtime for linking, one will
get build errors.
It looks like ecj is going to replace the gcj java front-end compiler thereby
makin
On Tue, 11 Jul 2006, Doug Cutting wrote:
Probably this would get fixed more quickly if someone contributed a patch to
JavaCC. Even it were not committed, we could build our own version of
JavaCC. Any intrepid volunteers?
For patches that seem too kludgy to make it into Lucene's sources (fo
On Jul 11, 2006, at 3:51 AM, Doug Cutting wrote:
Andi Vajda wrote:
I'd be interested in doing this but what is it that we're after in
'supporting gcj' actually ?
I think it would sufficient to:
1. Compile only .jar and .class with gcj (not .java).
2. Pass all unit tests on a single platfor
believe that the most important classes that
are wanted are the concurrency ones. (At least that is how I have
read the posts here.)
I think the measure of readiness is not that it compiles today with
gcj, but that the Java 1.5 classes and features that are likely to be
used by lucene are
Andi Vajda wrote:
Just last week, a PyLucene user got it to work on Solaris. I have no
access to a Solaris machine to validate this. If I had my choice of
platform, I'd pick one of (in order of preference):
- Mac OS X (Intel or PPC)
- a recent Red Hat Linux since this is the one most gcj de
On Tue, 11 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
I'd be interested in doing this but what is it that we're after in
'supporting gcj' actually ?
I think it would sufficient to:
1. Compile only .jar and .class with gcj (not .java).
2. Pass all unit tests on a single platform.
Just
Andi Vajda wrote:
I'd be interested in doing this but what is it that we're after in
'supporting gcj' actually ?
I think it would sufficient to:
1. Compile only .jar and .class with gcj (not .java).
2. Pass all unit tests on a single platform.
This would provide an existence proof that Lucene
Vic Bancroft wrote:
>> On Jul 10, 2006, at 11:17 PM, Daniel John Debrunner wrote:
>>
>>> Doug Cutting wrote:
>>>
Since GCJ is effectively available on all platforms, we could say that
we will start accepting 1.5 features when a GCJ release supports those
features. Does that seem
robert engels wrote:
Seems silly to support 1.5 and not do it this way.
Sometimes a little silliness is some serious fun! Just give me a rubber
nose, since I am just clowning around trying to build Andi's kewly
contrib/db using gcj on the slightly stylish db-4.4.20 and je-3.0.12 . . .
O
Agreed. I think those that are reliant on GCJ should plan on
expending the effort to do whatever backporting is needed to make
Lucene work on it. It should also be a GCJ branch or version. Seems
silly to support 1.5 and not do it this way.
On Jul 10, 2006, at 11:17 PM, Daniel John Debrunne
Doug Cutting wrote:
> Since GCJ is effectively available on all platforms, we could say that
> we will start accepting 1.5 features when a GCJ release supports those
> features. Does that seem reasonable?
Seems potentially a little strange to me. Does this mean Lucene would be
limited to the set
Andi Vajda wrote:
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say
that we will start accepting 1.5 features when a GCJ release
supports those features. Does that seem reaso
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that we
will start accepting 1.5 features when a GCJ release supports those
features. Does that seem reasonable?
+1
If we u
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that
we will start accepting 1.5 features when a GCJ release supports those
features. Does that seem reasonable?
+1
If we use this criteria, then we should probably of
On Jul 8, 2006, at 12:56 PM, Chuck Williams wrote:
I prefer to contribute to Lucene, but my workload simply
does not allow time to be spent on backporting.
I'll stand by my offer to do the backporting when it is possible and
does not do violence to the implementation.
I'd prefer to wait
Doug Cutting wrote on 07/08/2006 09:41 AM:
> Chuck Williams wrote:
>> I only work in 1.5 and use its features extensively. I don't think
>> about 1.4 at all, and so have no idea how heavily dependent the code in
>> question is on 1.5.
>>
>> Unfortunately, I won't be able to contribute anything sub
think it
is going to come in 2 parts:
1) It supports all the new language features of Java 1.5.
2) It has an implementation of all the new classes and methods that
Lucene uses.
For me the test is that it is released for MacOSX.
With these three things, I'd be happy :)
DM Smith, sti
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that we
will start accepting 1.5 features when a GCJ release supports those features.
Does that seem reasonable?
+1
Andi..
-
Chuck Williams wrote:
I doubt any single contribution will change anyone's mind. I would like
to have clarity on the 1.5 decision before deciding whether or not to
contribute this and other things. My ParallelWriter contribution, which
also requires 1.5, is already sitting in jira.
Sitting in
Daniel John Debrunner wrote:
I'm new to Lucene but not Apache, this is not how Apache projects are
meant to work. All decisions must be on the mailing lists and decisions
are made by the community via "consensus gathering", not a sub-set of
folks off the list. Or am I reading too much into this c
DM Smith wrote:
> However, I think you have identified that the core people need to
> make a decision and the rest of us need to go with it. So, I suggest
> that Doug convene such a meeting of the minds and communicate the
> decision to the rest of us.
I'm new to Lucene but not Apache, thi
DM Smith wrote on 07/07/2006 07:07 PM:
> Otis,
> First let me say, I don't want to rehash the arguments for or
> against Java 1.5.
This is an emotional issue for people on both sides.
> However, I think you have identified that the core people need to
> make a deci
Otis,
First let me say, I don't want to rehash the arguments for or
against Java 1.5. We can all go back and read the last two major
threads on the issue. I don't think there is anything new to say.
However, I think statements like:
"no strong argu
Hi Chuck,
I think bulk update would be good (although I'm not sure how it would be
different from batching deletes and adds, but I'm sure there is a difference,
or else you wouldn't have done it).
Java 1.5 - no conclusion, but personally I felt:
- no strong arguments for 1.4, on
AM
Subject: Re: Java 1.5 was [jira] Updated: (LUCENE-600) ParallelWriter companion
to ParallelReader
+1
Do you want to post it on the user list? It might also be good to put
it up on the main website.
Otis Gospodnetic wrote:
> Grant: how to poll users? How about this:
> http://www.quim
ng for one...
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, June 13, 2006 5:01:30 PM
Subject: Re: Java 1.5 was [jira] Updated: (LUCENE-600) ParallelWriter companion
to ParallelReader
In addition to performance,
I agree and completely understand Chuck. I'm waiting for my employer to sign
and fax the CCLA for some search benchmarking code I wrote, and it uses Java
1.5 stuff. It would only be a contrib piece, not core, so it's less of a
problem, but...
Grant: how to poll users? How about t
ing valued community members behind is important.
I think the pmc / committers just need to make a decision which will
impact one group or the other.
Chuck
Grant Ingersoll wrote on 06/13/2006 03:35 AM:
Well, we have our first Java 1.5 patch... Now that we have had a week
or two to digest the com
ind is important.
I think the pmc / committers just need to make a decision which will
impact one group or the other.
Chuck
Grant Ingersoll wrote on 06/13/2006 03:35 AM:
> Well, we have our first Java 1.5 patch... Now that we have had a week
> or two to digest the comments, do we wan
1 - 100 of 181 matches
Mail list logo
