Kotlin compiler has some confusing error messaging for unresolved classes. One developer's project compiles, and the other developers does not. They have the same code. Here is the error...
[ERROR] Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
class java.lang.AutoClosable, unresolved supertypes: Object
class com.mycompany.ProviderObjIdentity, unresolved supertypes: Object
I don't know where to start debugging this problem. There are no differences in the code for the projects, but I guess the two developers are using different JDKs. Maybe different versions of maven. Definitely different flavors of linux.
I'd be happy to provide any additional information, I just don't know what would be helpful.
this dev guy's setup is busted:
Kotlin: 1.0.4
sles SUSE Linux Enterprise Server 11 (x86_64)
Linux 3.0.76-0.11-default
mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 06:51:28-0700)
Maven home: /home/devguy1/apache-maven-3.0.5
Java version: 1.7.0, vendor: IBM Corporation
Java home: /usr/lib64/jvm/java-1.7.0-ibm-1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.0.76-0.11-default", arch: "amd64", family: "unix"
It looks like Kotlin's issue with IBM J9 JVM implementation reported as KT-14437 in the JB issue tracker. The fix is in work and most likely will be included in some upcoming Kotlin release. Meanwhile, you may want to use Oracle JDK as a workaround.
Related
Although the build was started using java version: 1.8.0_242, vendor: AdoptOpenJDK, I'm getting the warning -tag option is not supported on Java version < 1.4. When building with javadoc:jar, the build fails because of the custom tags.
This is a quite old build using maven-javadoc-plugin:2.10.4. I cannot just ramp it up to 3+, and 2.10.4 seems to be newest version of 2.10.
Any ideas?
This question doesn't mention the wrapper.
OS is Linux Mint 18.3.
So for this project I get the following from the wrapper:
mike#M17A ~/software projects/eclipse-workspace/TM_Engine_Exp $ ./gradlew -version
------------------------------------------------------------
Gradle 5.4.1
------------------------------------------------------------
Build time: 2019-04-26 08:14:42 UTC
Revision: 261d171646b36a6a28d5a19a69676cd098a4c19d
Kotlin: 1.3.21
Groovy: 2.5.4
Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM: 11.0.4 (Ubuntu 11.0.4+11-post-Ubuntu-116.04.1)
OS: Linux 4.4.0-53-generic amd64
From the OS I get the following (NB I know this is irrelevant!):
mike#M17A ~ $ groovy -version
WARNING: An illegal reflective access operation has occurred
...
Groovy Version: 2.5.8 JVM: 11.0.4 Vendor: Ubuntu OS: Linux
(NB the warning here occurs if you use a JDK > 8: there's nothing you can do about it currently).
And I get the following for the system's Gradle version (again irrelevant):
mike#M17A ~ $ gradle -version
WARNING: An illegal reflective access operation has occurred
...
------------------------------------------------------------
Gradle 4.8.1
------------------------------------------------------------
...
Groovy: 2.4.12
...
But my build.gradle contains the following dependency currently:
apply plugin: 'groovy'
...
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.5.7'
...
My environment variable is:
GROOVY_HOME=/home/mike/.sdkman/candidates/groovy/current
I'm not sure how this came to be set. The files there are almost certainly configured to use 2.5.8, as far as I can work out.
So my question is: how is the wrapper choosing to use 2.5.4 and where am I going the find these Groovy language files?
Also, presumably the version in the dependency section of build.gradle applies only to my testing and building files (i.e. written by me in Groovy), and has nothing to do with Gradle's own build actions and other tasks?
NB I'm tempted to uninstall my system Gradle and my system Groovy, since they just confuse the issue, and just rely on using the wrapper. Is this a sensible idea?
Gradle comes bundled with Groovy and does not look at what other versions you have installed on your system. This is why you are seeing different Groovy versions across different Gradle versions. You cannot change this version as it is part of Gradle and likely won't work with any other versions. If you are curious, you can look in the "lib" folder in your Gradle distribution to see all third-party libraries to Gradle, including Groovy - just don't go fiddling around with them.
As you mention, having declared a compile dependency to Groovy in your build script makes that particular version used when compiling. This is generally the only thing you should care about. (By the way, compile is deprecated, and you should use implementation.)
I am not sure what your goal is, but I would highly recommend only using the Gradle wrapper scripts, which means you can uninstall the system installation of Gradle if you like. You can ignore the Groovy version on your system (or uninstall it if you are not using it elsewhere).
I have a Jetson Tx2 which is Ubuntu Linux ARM64. I can't seem to find a 'binary' distribution for this. Is my only option to get the source for Maven 3.3.9, build that and then build Maven 3.5 using the 3.3.9 version?
My ultimate goal is to get apache pulsar installed on this same platform.
Thanks,
Mike
Maven is distributed with native Jansi support in the form of dynamic link libraries for Freebsd 32/64, Linux 32/64. Windows 32/64 and Osx. This is the only dependency to native code I am aware of.
That is, you don't need to build Maven, you just have to download a 'binary' archive such as this one, and to extract it - I am assuming here you already have a JDK for Aarch64 Linux installed.
I am using Antlr4 to parse language.
I also use maven to build my target JAR.
It all works fine with JDK 1.7, but my parser tool should run as a part of a Java 8 based system. I tried to compile it as Java 1.8 but got excpetion that 1.8 is not supported.
Is there a solution?
regards,
id
Java 8 has been supported since ANTLR release 4.2.
Source: Release notes for ANTLR 4
I'm actually trying to compile some native code, but that I think that has to wait for a moment. Please consider the following as building up to resolving Native builds with Maven-NAR-pluggin.
We have 64 bit windows machines currently which are quite capable of also compiling 32 bit software. (yes I know, still waiting for the 128 bit)
How do we configure Maven pluggins / POM to compile both?
aka override the architecture as provided from the JRE that was found in JAVA_HOME
C:\Data\dev\zlib\minizip>mvn -X compile
+ Error stacktraces are turned on.
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_31
Java home: C:\Program Files\Java\jdk1.6.0_31\jre
Default locale: en_AU, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
c:\Data\dev\zlib\miniunzip>mvn -X compile
+ Error stacktraces are turned on.
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_20
Java home: C:\Program Files (x86)\Java\jdk1.6.0_20\jre
Default locale: en_AU, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
We may also have a need to compile some modules to different JRE versions due to being a loaded library used in JRE 1.3/1.4/1.5/1.6
Is it possible to configure Maven POM to have profile differences or build differences based on the JRE version we are compiling to, or do we have to have 4 POM?
Is it possible to configure Maven to Run tests using an alternate JRE to that executing the Maven build?