-
Notifications
You must be signed in to change notification settings - Fork 25
Java 7 Support? #6
Comments
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? |
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 |
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:
I would suggest to get rid of the logback implementation. Regardless of whether this is the dependency conflict here or not. |
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!
The text was updated successfully, but these errors were encountered: