[
https://issues.apache.org/jira/browse/LUCENE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16169838#comment-16169838
]
Uwe Schindler edited comment on LUCENE-7966 at 9/18/17 10:27 AM:
-----------------------------------------------------------------
When thinking last night about the whole thing a bit more, I had a cool idea:
Currently we use ASM to generate the stub files to compile against (see my
Github repo). On top of these stubs we use a "wrapper class" that just
delegates all methods to the Java 9 one. IMHO, this is not nice for the
optimizer (although it can handle that). But the
oal.util.FutureObjects/FutureArrays classes just contain the same signatures as
their Java 9 variants would contain. So my idea is to use ASM to patch all
classes:
- Use a groovy script that runs on the compiler output, before building the JAR
file
- Load class with ASM and use ASM's rewriter functionality to change the
classname of all occurences of oal.util.FutureObjects/FutureArrays and replace
them by java.util.Objects/Arrays. We can use this utility out of ASM to do
this:
[http://asm.ow2.org/asm50/javadoc/user/org/objectweb/asm/commons/ClassRemapper.html].
Whenever a class file contaisn references to FutureXXX classes, we patch it
using asm and write it out to META-INF folder as Java 9 variant.
- Then package MR jar.
The good thing:
- we don't need stub files to compile with Java 8. We just need the smoke
tester to verify the patched class files actually resolves against Java 9
during the Java 9 checks
- we have no license issues, because we don't need to generate and commit the
stubs. In our source files we solely use oal.util.Objects/Arrays. Adapting to
Java 9 is done by constant pool renaming :-)
What do you think? I will try this variant a bit later today. We can use the
same approach for other Java 9 classes, too! Maybe this also helps with the
issues Mike has seen (I am not happy to have the degelator class).
was (Author: thetaphi):
When thinking last night about the whole thing a bit more, I had a cool idea:
Currently we use ASM to generate the stub files to compile against (see my
Github repo). On top of these stubs we use a "wrapper class" that just
delegates all methods to the Java 9 one. IMHO, this is not nice for the
optimizer (although it can handle that). But the
oal.util.FutureObjects/FutureArrays classes just contain the same signatures as
their Java 9 variants would contain. So my idea is to use ASM to patch all
classes:
- Use a groovy script that runs on the compiler output, before building the JAR
file
- Load class with ASM and use ASM's rewriter functionality to change the
classname of all occurences of oal.util.FutureObjects/FutureArrays and replace
them by java.util.Objects/Arrays. We can use this utility out of ASM to do
this:
[http://asm.ow2.org/asm50/javadoc/user/org/objectweb/asm/commons/ClassRemapper.html]
Whenever a class file contaisn references to FutureXXX classes, we patch it
using asm and write it out to META-INF folder as Java 9 variant.
- Then package MR jar.
The good thing:
- we don't need stub files to compile with Java 8. We just need the smoke
tester to verify the patched class files actually resolves against Java 9
during the Java 9 checks
- we have no license issues, because we don't need to generate and commit the
stubs. In our source files we solely use oal.util.Objects/Arrays. Adapting to
Java 9 is done by constant pool renaming :-)
What do you think? I will try this variant a bit later today. We can use the
same approach for other Java 9 classes, too! Maybe this also helps with the
issues Mike has seen (I am not happy to have the degelator class).
> 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: [email protected]
For additional commands, e-mail: [email protected]
