search

moodysalem / java-phantomjs-wrapper

A Java wrapper around the PhantomJS binaries including a packaged HTML to PDF render script
MIT License
52 stars 25 forks source link

Java 7 Support? #6

Open natefoundry opened 7 years ago

natefoundry commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.