Hi William, The gradle targetCompatability options is supposed to set the correct level of bytecode, but it seems that isn't working for you. The toolchain feature, however, does work by using one JDK to compile and a different JDK to run gradle. If you don't use the toolchain feature, the same JDK is used for both. I've usually needed that for a gradle plugin that only works in a different version of Java than the program will be deployed in.
If you use the toolchain feature, you don't use sourceCompatability or targetCompatability. Toolchains replace that earlier method, and aren't compatible with it. Here is one blog post that talks about toolchains: https://blog.gradle.org/java-toolchains If you use the source and target parameters, you might be able to get what you need with a little tweak to the java compile task (see https://stackoverflow.com/questions/27861658/how-specify-the-required-java-version-in-a-gradle-build). To summarize that: # in kotlin syntax, the groovy syntax is probably slightly different: java { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } tasks.withType<JavaCompile> { options.compilerArgs.addAll(arrayOf("--release", "8")) } But that's StackOverflow, so buyer beware. -- Carl Burke ----- Original Message ----- From: "* William" <william.full.m...@gmail.com> To: "users" <users@netbeans.apache.org> Sent: Wednesday, September 15, 2021 10:28:56 AM Subject: Re: Specify Java Platform? Good evening, Thanks to you both Carl and Scott. It looks like the alternative I 'want' will come from the toolchain facility once I figure it out. The examples I've looked at are probably very good for someone who has already worked on setting-up a toolchain. I am posting thou to point out the difference between what I asked for and what I seek as desirable. Firstly what I "want to do" (ideal scenario). It would be likely that toolchains will give me that, when I get on top of it. So I have direction. Toolchain and ... What I asked for wasn't what I "wanted" , however it will get me past my roadblock, so in any case that's good value. I asked for how to specify the JVM my built JAR, class, etc would run on. I'm trageting JVM 1.8 (or 8). The target environment(s) won't migrat off Java 8 for some time. That's a bit of a message for the JDK project actually. It took us years to get people to move from Java 7 to Java 8. I know because I put a target put a target on my forehead by making Java 8 a dependency (ooch). Got to maintain the legacy code. In a nut shell (by way of a bit of scant documentation) the *Java Platform *feature gives you what the label says, a "Java Develpment Platform". I picked Java 8 and my builds report using Java 8 to build. My logging reports we are using Java as the runtime. [image: image.png] [image: image.png] When you choose Java 16, the Java 16 JDK is used to build the target. I believe that's what I asked for earlier because at the end of the day I need to test using Java 8, not the build platform which is currently Java 16. And wiht the platform Java 8 option; I can run Netbeans under Java 16 with those benefits. But I can't get build improvements from Java 16, I must stick with Java 8 for build and to run. Not a bad balance. So I successfully ran my app. after building with the Java 8 platform, running on Java 8. [image: image.png] The paltform stuff works just fin in Netbeans 12. The not so good news. With the tool chain notion, I thought/hoped I could use any Java platform to build to a target platform. Cross compile with Java 16 targeting Java 8. After a few test that does not seem to be a practical option. That first thing: - JDK source JDK target Well that don't generate a Java 8 Jar file: - $ sdk use java 8.0.292.fx-zulu - $ java -jar ./XxxxxServlet.jar au.com.fourtel.xxxxx.XxxxxServlet $ java -jar ./ProtectionOfficerServlet.jar au.com.fourtel.fourams.po.ProtectionOfficerServlet Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: au/com/fourtel/fourams/po/ProtectionOfficerServlet has been compiled by a more recent version of the Java Runtime (class file version 60.0), this version of the Java *Runtime only recognizes class file versions up to 52.0* at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:757) That there error message: "[Java 8] *Runtime only recognizes class file versions up to 52.0*", means that Java is not cross-compiling to a targetCompatibility = 1.8, it is like a "niceness check" to make sure we are only using Java 8 code and behaviour but has to run in a compatible Java runtime (in this case version 60, from JDK 16). It makes sense, even if it is not what I "thought" was happening. Until this week, I thought I could run that Jar file targetCompatibility => 1.8 on a Java 8 platform ... No fuss, No muss, No problems. I can't. Therefore I need to ask, in case - If the Java compiler doesn't generate what I need to target... Can a toolchain feature help this use-case? - I'm willing to believe the other non Java-16 compilers can use the 60 class file version (thinking positive) - What is a toolchain confguration targeted to do where compilers are not actually compiling a set: 'targetCompatibility'? - Is/Are there Java controls or settings that actually can produce version 52 class files using a more up to date compiler (or tooling)? Kind of interesting for gradle to put an investment into a 'targetCompatibility' feature that the build tools don't/can deliver. Ironic? Best wishes, \_w_/ On Thu, 9 Sept 2021 at 23:28, Scott Palmer <swpal...@gmail.com> wrote: > It’s under Project Properties -> Build -> Compile: > You can also do fancy stuff with the Gradle script as Carl mentioned. > https://docs.gradle.org/current/userguide/toolchains.html > > Regards, > > Scott > > On Sep 8, 2021, at 4:54 AM, * William <william.full.m...@gmail.com> wrote: > > Hello all, > > I hope you are going well in your part of the world. In the past, with > the Gradle plugin it was possible to specify the Java runtime and libries > used when exercising and testing the program. > > <image.png> > > How may I do this with the current Netbeans 12 release? > > We are using gradle and I have a Java 8 target platform but when the > program runs we get class version errors: > > 17:20:57.411 DEBUG org.eclipse.jetty.servlet.ServletHolder - Servlet.init > org.glassfish.jersey.servlet.ServletContainer@1f53a5dc for > org.glassfish.jersey.servlet.ServletContainer-2049a9c1 > Sept 08, 2021 5:20:57 PM > org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener$ClassReaderWrapper > accept > WARNING: Unsupported class file major version 60 > > In this build we have ... > > - sourceCompatibility = '1.8' > - targetCompatibility = '1.8' > > aloha, \_w_/ ___________________________________ º http://www.facebook.com/will.2016
