Re: java 9 compiler issues with ByteBuffer covariant overrides
Why don't they just fail on the -source and -target options then? If they don't work at all... this is pretty ridiculous. On Mon, Mar 30, 2015 at 3:20 AM, Uwe Schindler wrote: > Hi Dawid, hi Robert, > > Exactly! We had this issue also on earlier versions of the JDK and OpenJDK > people don't want to deal about those issues. One occurrence was in Java 8 > with the isAnnotationPresent() as default method, but this was fixed, because > it also affected code compiled executed with Java 8 (here the compiler, not > the runtime faced the same issue). But covariant return types, as are > problematic here, is one similar issue we also had in the Lucene 2->3 > backwards compatibility game: We did not change the return types of all > clone() methods initially to be covariant, because it would have caused > issues like this for users of Lucene who do in-place upgrades (this is long > time back). Java is now facing the same problem. I really like those > covariant returns (allows big builder method chaining), but it is impossible > for the compiler people to take care about this, unless you compile with an > older rt.jar. > > This is the reason why since Java 7 the following message is printed when you > compile with older target, but newer version: > [javac] warning: [options] bootstrap class path not set in conjunction with > -source 1.x > (and this warning message is the reason why OpenJDK people say: it's broken, > you should compile with the version you want to release for; I am not sure > why this message in Lucene is no longer printed, but this could be because of > different warning settings). > > This just makes one statement from the Lucene Release TODO very important and > I am glad that it's tested by the smoker (looking at the META-INF/manifest of > our JAR files): "Build the code and javadocs, and run the unit tests: ant > clean javadocs test. Make sure that you are actually using the minimum > compiler version supported for the release. For example, 4.x releases are on > Java6 so make sure that you use Java6 for the release workflow." > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf >> Of Dawid Weiss >> Sent: Monday, March 30, 2015 8:47 AM >> To: dev@lucene.apache.org >> Subject: Re: java 9 compiler issues with ByteBuffer covariant overrides >> >> Hi Robert, >> >> This was discussed on core-libs at some point, but I can't find the thread >> and >> the outcome of that conversation right now (damn it). >> >> I believe the answer was that these covariant changes are forward- >> compatible so that existing code works with 1.9 and if you're compiling with >> backward compatibility in mind you should compile against the target JDK of >> your choice. >> >> Dawid >> >> On Mon, Mar 30, 2015 at 4:19 AM, Robert Muir wrote: >> > Hi, >> > >> > If I compile lucene with a java 9 compiler (using -source 1.8 -target >> > 1.8 like our build does), then the resulting jar file cannot actually >> > be used with a java 8 JVM. >> > >> > The reason is, in java 9 ByteBuffer.class got some new covariant overrides: >> > e.g. ByteBuffer.java has position(int) that returns ByteBuffer, but >> > this does not exist on java 8 (the position method is only in >> > Buffer.java returning Buffer). >> > >> > This leads to an exception like this (I am sure there are other >> > problems, its just the first one you will hit): >> > >> > Exception in thread "main" java.lang.NoSuchMethodError: >> > java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; >> > at >> org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.(Byte >> BufferIndexInput.java:414) >> > at >> org.apache.lucene.store.ByteBufferIndexInput.newInstance(ByteBufferInd >> exInput.java:55) >> > at >> org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:21 >> 6) >> > at >> org.apache.lucene.store.Directory.openChecksumInput(Directory.java:110) >> > at >> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:268 >> ) >> > at >> org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:359) >> > at >> org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:356) >> > at >> org.apache.lucene.index.S
RE: java 9 compiler issues with ByteBuffer covariant overrides
Hi Dawid, hi Robert, Exactly! We had this issue also on earlier versions of the JDK and OpenJDK people don't want to deal about those issues. One occurrence was in Java 8 with the isAnnotationPresent() as default method, but this was fixed, because it also affected code compiled executed with Java 8 (here the compiler, not the runtime faced the same issue). But covariant return types, as are problematic here, is one similar issue we also had in the Lucene 2->3 backwards compatibility game: We did not change the return types of all clone() methods initially to be covariant, because it would have caused issues like this for users of Lucene who do in-place upgrades (this is long time back). Java is now facing the same problem. I really like those covariant returns (allows big builder method chaining), but it is impossible for the compiler people to take care about this, unless you compile with an older rt.jar. This is the reason why since Java 7 the following message is printed when you compile with older target, but newer version: [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.x (and this warning message is the reason why OpenJDK people say: it's broken, you should compile with the version you want to release for; I am not sure why this message in Lucene is no longer printed, but this could be because of different warning settings). This just makes one statement from the Lucene Release TODO very important and I am glad that it's tested by the smoker (looking at the META-INF/manifest of our JAR files): "Build the code and javadocs, and run the unit tests: ant clean javadocs test. Make sure that you are actually using the minimum compiler version supported for the release. For example, 4.x releases are on Java6 so make sure that you use Java6 for the release workflow." Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf > Of Dawid Weiss > Sent: Monday, March 30, 2015 8:47 AM > To: dev@lucene.apache.org > Subject: Re: java 9 compiler issues with ByteBuffer covariant overrides > > Hi Robert, > > This was discussed on core-libs at some point, but I can't find the thread and > the outcome of that conversation right now (damn it). > > I believe the answer was that these covariant changes are forward- > compatible so that existing code works with 1.9 and if you're compiling with > backward compatibility in mind you should compile against the target JDK of > your choice. > > Dawid > > On Mon, Mar 30, 2015 at 4:19 AM, Robert Muir wrote: > > Hi, > > > > If I compile lucene with a java 9 compiler (using -source 1.8 -target > > 1.8 like our build does), then the resulting jar file cannot actually > > be used with a java 8 JVM. > > > > The reason is, in java 9 ByteBuffer.class got some new covariant overrides: > > e.g. ByteBuffer.java has position(int) that returns ByteBuffer, but > > this does not exist on java 8 (the position method is only in > > Buffer.java returning Buffer). > > > > This leads to an exception like this (I am sure there are other > > problems, its just the first one you will hit): > > > > Exception in thread "main" java.lang.NoSuchMethodError: > > java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; > > at > org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.(Byte > BufferIndexInput.java:414) > > at > org.apache.lucene.store.ByteBufferIndexInput.newInstance(ByteBufferInd > exInput.java:55) > > at > org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:21 > 6) > > at > org.apache.lucene.store.Directory.openChecksumInput(Directory.java:110) > > at > org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:268 > ) > > at > org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:359) > > at > org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:356) > > at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfo > s.java:574) > > at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfo > s.java:526) > > at > org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.ja > va:361) > > at > > org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.ja > > va:228) > > > > Is this expected behavior? Do we need to fix our build to also require > > a java 8 JDK on the developers machine, and set bootclasspath, or is > > -source/-target 1.8 supposed to "just work" without it lik
Re: java 9 compiler issues with ByteBuffer covariant overrides
Hi Robert, This was discussed on core-libs at some point, but I can't find the thread and the outcome of that conversation right now (damn it). I believe the answer was that these covariant changes are forward-compatible so that existing code works with 1.9 and if you're compiling with backward compatibility in mind you should compile against the target JDK of your choice. Dawid On Mon, Mar 30, 2015 at 4:19 AM, Robert Muir wrote: > Hi, > > If I compile lucene with a java 9 compiler (using -source 1.8 -target > 1.8 like our build does), then the resulting jar file cannot actually > be used with a java 8 JVM. > > The reason is, in java 9 ByteBuffer.class got some new covariant overrides: > e.g. ByteBuffer.java has position(int) that returns ByteBuffer, but > this does not exist on java 8 (the position method is only in > Buffer.java returning Buffer). > > This leads to an exception like this (I am sure there are other > problems, its just the first one you will hit): > > Exception in thread "main" java.lang.NoSuchMethodError: > java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; > at > org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.(ByteBufferIndexInput.java:414) > at > org.apache.lucene.store.ByteBufferIndexInput.newInstance(ByteBufferIndexInput.java:55) > at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:216) > at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:110) > at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:268) > at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:359) > at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:356) > at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:574) > at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:526) > at > org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:361) > at > org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:228) > > Is this expected behavior? Do we need to fix our build to also require > a java 8 JDK on the developers machine, and set bootclasspath, or is > -source/-target 1.8 supposed to "just work" without it like it did > before? > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
java 9 compiler issues with ByteBuffer covariant overrides
Hi, If I compile lucene with a java 9 compiler (using -source 1.8 -target 1.8 like our build does), then the resulting jar file cannot actually be used with a java 8 JVM. The reason is, in java 9 ByteBuffer.class got some new covariant overrides: e.g. ByteBuffer.java has position(int) that returns ByteBuffer, but this does not exist on java 8 (the position method is only in Buffer.java returning Buffer). This leads to an exception like this (I am sure there are other problems, its just the first one you will hit): Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; at org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.(ByteBufferIndexInput.java:414) at org.apache.lucene.store.ByteBufferIndexInput.newInstance(ByteBufferIndexInput.java:55) at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:216) at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:110) at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:268) at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:359) at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:356) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:574) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:526) at org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:361) at org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:228) Is this expected behavior? Do we need to fix our build to also require a java 8 JDK on the developers machine, and set bootclasspath, or is -source/-target 1.8 supposed to "just work" without it like it did before? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
