Curiously , on my Catalina box, I don’t have JAVA_HOME set either I installed the jdk with this package…
% ll Desktop/OpenJDK8U-jdk_x64_mac_hotspot_8u252b09.pkg -rw-r--r--@ 1 en032339 staff 104023171 May 13 2020 Desktop/OpenJDK8U-jdk_x64_mac_hotspot_8u252b09.pkg This is what I see… % /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk1.8.0_251.jdk/Contents/Home % /Library/Java/JavaVirtualMachines/jdk1.8.0_251.jdk/Contents/Home/bin/java -version java version "1.8.0_251" Java(TM) SE Runtime Environment (build 1.8.0_251-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode) % /Library/Java/JavaVirtualMachines/jdk1.8.0_251.jdk/Contents/Home/bin/javac -version javac 1.8.0_251 In /usr/bin , is see symlinks… % ll | grep java$ lrwxr-xr-x 1 root wheel 74 May 12 2020 java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java en032339@C02CJMZ8MD6M bin % ll | grep javac$ lrwxr-xr-x 1 root wheel 75 May 12 2020 javac -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac Which curiously seem to be the exact same version… but this version convoluted as the this path is littered with symlinks too which seem to end up here /System/Library/Frameworks/JavaVM.framework/Versions/Current However, it still appears to be the same version… en032339@C02CJMZ8MD6M ~ % java -version java version "1.8.0_251" Java(TM) SE Runtime Environment (build 1.8.0_251-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode) % javac -version javac 1.8.0_251 How it got this way I’m not sure. I’m assuming it all occurred when I installed the *pkg file above. From: "o...@ocs.cz" <o...@ocs.cz> Reply-To: "users@groovy.apache.org" <users@groovy.apache.org> Date: Friday, January 29, 2021 at 9:57 AM To: "users@groovy.apache.org" <users@groovy.apache.org> Subject: Re: groovyc stopped to compile Java after Big Sur update P.S. On 29. 1. 2021, at 6:50 PM, o...@ocs.cz<mailto:o...@ocs.cz> wrote: Nevertheless, there's no JAVA_HOME at all on my Catalina either, and groovy compiles Java in there without a glitch. How comes? Hmmm... I wonder. Perhaps the groovy compiler is smart enough to call /usr/libexec/java_home itself if the JAVA_HOME variable is empty; it then gets the wrong value and fails. Makes sense. And also, is there a way to set the thing up properly without fixing the path in my build scripts? The java_home thing returns a completely wrong path without the -V switch: === 1 ocs ~> /usr/libexec/java_home /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home 2 ocs ~> === If it is indeed so, the question could be re-phrased “How to make the /usr/libexec/java_home tool to return the proper value?“ Note Java 8 is indeed the default; I completely forgot there used to be 13, which we can't use anyway: === 5 ocs ~> /usr/libexec/java_home /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home 6 ocs ~> java -version java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) 7 ocs ~> === Strangely enough, with Catalina on the same machine with both the Javas this was not a problem either. Weird. Thanks a lot, OC On 1/29/21, 8:47 AM, "o...@ocs.cz<mailto:o...@ocs.cz>" <o...@ocs.cz<mailto:o...@ocs.cz>> wrote: Hi there, I've got a project which uses both Groovy and Java sources. After Big Sur update -- without touching the project, it remained unchanged and does build perfectly on my other machine with a Catalina -- it reports “unable to locate the java compiler com.sun.tools.javac.Main, please change your classloader settings” and fails. I have absolutely no idea why and how should I “change my classloader settings” in this case? The project never changed, only the environment has (from Catalina to Big Sur), and it broke something :( Any idea what's the culprit and how to fix it? Thanks a lot! OC P.S. Here are details of the fail, it's very easy to repeat on the Big Sur machine: === 69 ocs /tmp> touch empty.java 70 ocs /tmp> /usr/local/groovy-2.4.21/bin/groovyc -j empty.java org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during semantic analysis: unable to locate the java compiler com.sun.tools.javac.Main, please change your classloader settings java.lang.ClassNotFoundException: unable to locate the java compiler com.sun.tools.javac.Main, please change your classloader settings at org.codehaus.groovy.tools.javac.JavacJavaCompiler.findJavac(JavacJavaCompiler.java:193) at org.codehaus.groovy.tools.javac.JavacJavaCompiler.compile(JavacJavaCompiler.java:53) at org.codehaus.groovy.tools.javac.JavaAwareCompilationUnit.gotoPhase(JavaAwareCompilationUnit.java:110) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:589) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at org.codehaus.groovy.tools.FileSystemCompiler.compile(FileSystemCompiler.java:71) at org.codehaus.groovy.tools.FileSystemCompiler.doCompilation(FileSystemCompiler.java:227) at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompile(FileSystemCompiler.java:160) at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompileWithErrorHandling(FileSystemCompiler.java:190) at org.codehaus.groovy.tools.FileSystemCompiler.main(FileSystemCompiler.java:174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:116) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:138) 1 error 71 ocs /tmp> java -version java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) 72 ocs /tmp> sw_vers ProductName: macOS ProductVersion: 11.1 BuildVersion: 20C69 73 ocs /tmp> === Perhaps worth mentioning a newer Groovy fails too, only with _considerably_ less friendly error report (bloody NPE is the worst thing ever): === 73 ocs /tmp> /usr/local/groovy-3.0.4/bin/groovyc -j empty.java org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during semantic analysis: java.lang.NullPointerException java.lang.NullPointerException at org.codehaus.groovy.tools.javac.JavacJavaCompiler.doCompileWithSystemJavaCompiler(JavacJavaCompiler.java:95) at org.codehaus.groovy.tools.javac.JavacJavaCompiler.compile(JavacJavaCompiler.java:66) at org.codehaus.groovy.tools.javac.JavaAwareCompilationUnit.gotoPhase(JavaAwareCompilationUnit.java:119) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:638) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:606) at org.codehaus.groovy.tools.FileSystemCompiler.compile(FileSystemCompiler.java:311) at org.codehaus.groovy.tools.FileSystemCompiler.doCompilation(FileSystemCompiler.java:240) at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompile(FileSystemCompiler.java:165) at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompileWithErrorHandling(FileSystemCompiler.java:205) at org.codehaus.groovy.tools.FileSystemCompiler.main(FileSystemCompiler.java:189) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:111) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:129) 1 error 74 ocs /tmp> ===
