sdkman.io ftw!
Best regards / Med venlig hilsen, Søren Berg Glasius Hedevej 1, Gl. Rye, 8680 Ry, Denmark Mobile: +45 40 44 91 88, Skype: sbglasius --- Press ESC once to quit - twice to save the changes. Den fre. 29. jan. 2021 kl. 19.53 skrev Nelson, Erick < erick.nel...@hdsupply.com>: > 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 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" <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> > === > > > > > > >
