[
https://issues.apache.org/jira/browse/LUCENE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170027#comment-16170027
]
Uwe Schindler edited comment on LUCENE-7966 at 9/18/17 3:21 PM:
----------------------------------------------------------------
Here is the class remapper: https://paste.apache.org/bAzx
Basically it rewrites all references to oal.future.FutureXxxx to the Java 9
type java.util.Xxxx. All files that contain in the Java 8 code in
{{build/classes/java}} references to our own FutureXxx classes (the remapper
sets remapped=true for those) are saved to in rewritten formto a separate
directory {{build/classes/java9}} in parallel to the original and are packaged
into the multirelease part of the JAR. All classes that have no references to
our FutureXxx backports are kept out.
This can be done as a general task and may be applied to all Lucene/Solr
modules.
I will update my branch later.
was (Author: thetaphi):
Here is the class remapper: https://paste.apache.org/NUOp
Basically it rewrites all references to oal.future.FutureXxxx to the Java 9
type java.util.Xxxx. All files that contain in the Java 8 code in
{{build/classes/java}} references to our own FutureXxx classes (the remapper
sets remapped=true for those) are saved to in rewritten formto a separate
directory {{build/classes/java9}} in parallel to the original and are packaged
into the multirelease part of the JAR. All classes that have no references to
our FutureXxx backports are kept out.
This can be done as a general task and may be applied to all Lucene/Solr
modules.
I will update my branch later.
> 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: general/build
> Reporter: Robert Muir
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
