After a bit more thought, the build configuration for the compile step specifies a source and target level of Java 8.
Reading the docs for maven-compiler-plugin: it says it uses javax.tools.JavaCompiler of the java environment. For Java 11, the javac tool says: Cross-Compilation Options for javac By default, for releases prior to JDK 9, classes were compiled against the bootstrap classes of the platform that shipped with the javac command. But javac also supports cross-compiling, in which classes are compiled against bootstrap classes of a different Java platform implementation. It’s important to use the -bootclasspath and -extdirs options when cross-compiling. I'm guessing the maven-compiler-plugin may not use these options. So - I agree with your suggestion to use Java 8 when building. I did a scan of uimaj code to see if we make use of the changed methods for ByteBuffer and didn't find any; so I'm inclined to *not* redo RC1 at this time. Let me know if you think I should redo it. -Marshall On 11/7/2018 3:29 PM, Richard Eckart de Castilho wrote: > On 7. Nov 2018, at 16:45, Marshall Schor <[email protected]> wrote: >> Interesting... >> >> I'm thinking that to get our code base to work with Java 11, we'll need to >> scan >> our code for all uses of ByteBuffer, and if any of those uses calls the 7 >> changed methods, we'll need to fix those; is that your take? >> >> I did scan our code, and found some uses of ByteBuffer, but haven't yet >> explored >> further to see if we use these methods... > I have tried building UIMA v3.0.1 using JDK 8 and then built DKPro Core v2 > using > this version -> that seems to be working ok - no ByteBuffer problem in the > module > that previously failed. > > So I'd guess just because we *can* build on Java 11 doesn't mean we should. > Building on a proper JDK 8 solves the problem and also ensures that we would > not > accidentally use any APIs that were only introduced after Java 8. > > We could probably still introduce a cast to allow UIMA code built using JDK 11 > to work in a Java 8 project - but IMHO that would be an additional measure. I > think > it should not replace building our code with our target-level JDK. > > -- Richard
