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 <u...@thetaphi.de> 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 <rcm...@gmail.com> 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.<init>(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 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 > > > --------------------------------------------------------------------- > 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
