Skip to content
This repository has been archived by the owner on Sep 22, 2021. It is now read-only.

Java 7 Support? #6

Open
natefoundry opened this issue Jun 8, 2017 · 3 comments
Open

Java 7 Support? #6

natefoundry opened this issue Jun 8, 2017 · 3 comments

Comments

@natefoundry
Copy link

natefoundry commented Jun 8, 2017

I have a big project I'd like to use your PhantomJS wrapper for that is currently on Java version 7. The maven artifact you distributed seems to be compiled using Java 8 bytecode, hence it doesn't work on a Java 7 JRE.

I noticed the code uses a few Java 8 language features. I forked your repository and created a version that works with Java 7. Would you be willing to create a distributed version for Java 7?

Also, I forked off of the latest version 2 release. The logging change was causing a dependency conflict on my project (I didn't dig too deep into why), but we could potentially create two pull requests to support version 2 and 3 if that works. The effort is pretty minimal.

Thanks!

@ghost
Copy link

ghost commented Jun 24, 2017

I would strongly disadvise to create a specific Java 7 build version. Java 7 is EOL. The correct way, in my opinion, would be for you to upgrade your project to Java 8. Having a personal fork for the time being until you made the upgrade seems legit.

What excatly is you dependency conflict with the logging?

@moodysalem
Copy link
Owner

I like those java 8 language features-is it possible to build a binary compatible with java 7 without changing any of the code?

I'm also curious about the logging dependency conflicts-you can run mvn dependency:tree -Dverbose to get a view of the conflicts

@ghost
Copy link

ghost commented Jun 24, 2017

Basically no. You can use Java 7 code on a JVM 8, but not the other way round. Using Java 8 features makes it necessary to target 1.8 which means that any lower JVM is out of scope.

Regarding the logger: I saw that since SLF4J 1.6.0 has a different handling in case no implementation has been found on the classpath:

since 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.
See: https://www.slf4j.org/manual.html#libraries

I would suggest to get rid of the logback implementation. Regardless of whether this is the dependency conflict here or not.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants