[ https://issues.apache.org/jira/browse/LUCENE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345192#comment-16345192 ]
Uwe Schindler edited comment on LUCENE-7966 at 1/31/18 10:16 AM: ----------------------------------------------------------------- I worked today and made the branch on github up to date: * It now applies the classfile patching to all modules, Solr was disabled (not needed there) * It runs tests in Java 9 with a modified classpath (it puts the patched classes before the main classes), so we can actually also test the patched stuff on Java 9. This "hack" just emulates a MR JAR file. It is a really dirty hack, because it only applies this to the main classes. Of course, the tests for our own implementations of {{Objects/Arrays}} classes is done in Java 8 and Java 9 using Lucene's code, the hack just enables our unit tests that use the Lucene API to use the native Java 9 classes behind the scenes when executed in Java 9, so our production code is thoroughly tested. There is a new system property of the test framework to ({{tests.withJava9Patches}}, defaults to {{true}}), so you can disable this and only test our own {{Objects/Arrays}} implementations, also on Java 9. To fully fix the classpath complexity we should think about using the JAR files for testing and not build a classpath with raw class files. But that's time for another issue. I will now do some tests with Mike's luceneutils benchmarking tool. I just have to fix it to use the JAR files instead of using plain class files. was (Author: thetaphi): I worked today and made the branch on github up to date: * It now applies the classfile patching to all modules, Solr was disabled (not needed there) * It runs tests in Java 9 with a modified classpath (it puts the patched classes before the main classes), so we can actually also test the patched stuff on Java 9. This "hack" just emulates a MR JAR file. It is a really dirty hack, because it only applies this to the main classes. Of course, the tests for our own implementations of Objects/Arrays classes is done in Java 8 and Java 9 using Lucene's code, the hack just enables our uint tests using the Lucene API to use the native Java 9 classes when executed in Java 9. To fully fix the classpath complexity we should think about using the JAR files for testing and not build a classpath with raw class files. But that's time for another issue. I will now do some tests with Mike's luceneutils benchmarking tool. I just have to fix it to use the JAR files instead of using plain class files. > 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 > Priority: Major > 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org