Documented Java version requirement is 8, but release requires 11

Question

Documented Java version requirement is 8, but release requires 11

WilliamNoad opened this issue 5 years ago · 4 comments

Describe the bug
The documentation describes the minimum Java version as 8, however releases 2.0.2, 2.0.3 and 2.0.4 have been built using version 11.

My operational environments are limited to running Java 8 for the time being, requiring me to manually downgrade to release 2.0.0 before being able to run the tool.

To Reproduce

Create an AWS EC2 instance (e.g. t3.micro) running the current image of Amazon Linux 2.
Install the java-1.8.0-openjdk-devel package.
Execute the bin\install.sh script and following the onscreen instructions.
Run the okta-aws command line e.g.
okta-aws default sts get-caller-identity

Expected behavior
The expected result is that the command requests the user credentials.

The actual response is:

$ okta-aws default sts get-caller-identity                                                                                                   
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/okta/tools/WithOkta has been compiled by a more recent version of the Java Runtime (class file version 55.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:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

Screenshots
N/A

Additional context
This traceback was from using release 2.0.2, however I have tested it with the same failure mode for all releases to 2.0.4.

Answer 1 · 2019-09-15T02:31:09.000Z

Really hope this can be resolved. Is there any specific feature in Java 11 being used?

Answer 2 · 2019-09-24T09:24:19.000Z

Same problem. Getting CLI access via Okta is very quickly turning into nightmare for me. It's all so hacky and non-functional.

Answer 3 · 2019-09-24T14:37:27.000Z

@elice02 This is a community-supported project that no one from Okta works on. Please be kind to the maintainers as they're likely doing this in their free time.

Answer 4 · 2019-10-15T09:58:51.000Z

I did some additional digging myself, and noticed that the driver behind the move from Java 8 to Java 11 appear to be the use of the OpenJfx components. These libraries are only available for Java 11 and Java 13.

I haven't been able to determine what part of the Okta AWS tool is making use of these libraries, yet, but as this looks to be a primarily CLI based tool, the inclusion of GUI components seems a little odd to me.