lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available
Date Mon, 02 Oct 2017 13:14:01 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187994#comment-16187994
] 

Uwe Schindler commented on LUCENE-7966:
---------------------------------------

bq. I had a closer look at the branch and like the patching approach. Should we modify the
smoke tester at the same time to enforce that both Java 8 and 9 are tested?

I think so - that was my plan! In general the testing is automatically done. As soon as you
start Lucene Demo or Solr with Java 9 it will test the JAR file. But a separate test might
be good (like the Exception test I posted before), to see if stack trace looks as expected.

I will work soon on changing the patching mechanism to be globally (not only in root module).
I would also like to remove the {{@Deprecated}} from the Future classes (because at this time,
they are the only way) and instead add {{@lucene.internal}}. We should add a separate issue
about renoving Future classes, once we swicth to Java 9.

Are there any other tests we should do. I talked with Robert - we both don't understand Mike's
findings. I don't trust them unless we have a reproducible benchmark using BytesRefHash and
similar. The improvements in LZ4 are phantastic, I would have expected the same from BytesRefHash.

> build mr-jar and use some java 9 methods if available
> -----------------------------------------------------
>
>                 Key: LUCENE-7966
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7966
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/other, general/build
>            Reporter: Robert Muir
>              Labels: Java9
>         Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch,
LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking methods in
java 9 for example, without waiting for lucene 10 or something. If we build an MR-jar, we
can start migrating our code to use java 9 methods right now, it will use optimized methods
from java 9 when thats available, otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java methods. This
way, we can simply directly replace call sites with java 9 methods when java 9 is a minimum.
Simple 1-1 mappings mean also that we only have to worry about testing that our java 8 fallback
methods work.
> I found that many of the current byte array methods today are willy-nilly and very lenient
for example, passing invalid offsets at times and relying on compare methods not throwing
exceptions, etc. I fixed all the instances in core/codecs but have not looked at the problems
with AnalyzingSuggester. Also SimpleText still uses a silly method in ArrayUtil in similar
crazy way, have not removed that one yet.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message