You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "ocs@ocs.cz" <oc...@ocs.cz> on 2021/01/29 16:47:21 UTC
groovyc stopped to compile Java after Big Sur update
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>
===
Re: groovyc stopped to compile Java after Big Sur update
Posted by Søren Berg Glasius <so...@glasius.dk>.
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.Nelson@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: *"ocs@ocs.cz" <oc...@ocs.cz>
> *Reply-To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Date: *Friday, January 29, 2021 at 9:57 AM
> *To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Subject: *Re: groovyc stopped to compile Java after Big Sur update
>
>
>
> P.S.
>
>
>
> On 29. 1. 2021, at 6:50 PM, ocs@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, "ocs@ocs.cz" <oc...@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>
> ===
>
>
>
>
>
>
>
Re: groovyc stopped to compile Java after Big Sur update
Posted by "Nelson, Erick" <Er...@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: "ocs@ocs.cz" <oc...@ocs.cz>
Reply-To: "users@groovy.apache.org" <us...@groovy.apache.org>
Date: Friday, January 29, 2021 at 9:57 AM
To: "users@groovy.apache.org" <us...@groovy.apache.org>
Subject: Re: groovyc stopped to compile Java after Big Sur update
P.S.
On 29. 1. 2021, at 6:50 PM, ocs@ocs.cz<ma...@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, "ocs@ocs.cz<ma...@ocs.cz>" <oc...@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>
===
Re: groovyc stopped to compile Java after Big Sur update
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
P.S.
> On 29. 1. 2021, at 6:50 PM, ocs@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, "ocs@ocs.cz <ma...@ocs.cz>" <ocs@ocs.cz <ma...@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>
>> ===
>>
>>
>>
>
Re: groovyc stopped to compile Java after Big Sur update
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
Erick,
> On 29. 1. 2021, at 5:50 PM, Nelson, Erick <Er...@hdsupply.com> wrote:
> On big sur box, is java_home pointing to jre or jdk?
Neither.
I had to duckduckgo “java_home” first; I've never needed the thing before. It was empty — both on the Big Sur thing, and also on Catalina (where Groovy compiles Java sources perfectly). Based on the page https://explainjava.com/set-java-home-mac-os/ I have tried to set it up to what returns, /usr/libexec/java_home which did not work; nevertheless, eventually, doing it manually like this
===
89 ocs /tmp> /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
1.8.181.13 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
1.8.0_45 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
90 ocs /tmp> export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home"
91 ocs /tmp> /usr/local/groovy-2.4.21/bin/groovyc -j empty.java
92 ocs /tmp>
===
seemed to help indeed. Thanks!
Nevertheless, there's no JAVA_HOME at all on my Catalina either, and groovy compiles Java in there without a glitch. How comes? 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 ~>
===
Thanks a lot,
OC
>
> On 1/29/21, 8:47 AM, "ocs@ocs.cz" <oc...@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>
> ===
>
>
>
Re: groovyc stopped to compile Java after Big Sur update
Posted by "Nelson, Erick" <Er...@hdsupply.com>.
On big sur box, is java_home pointing to jre or jdk?
On 1/29/21, 8:47 AM, "ocs@ocs.cz" <oc...@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>
===