Support for Java1.6
I was hoping to use this library for JWT verification. Problem is many of our apps are on Java1.6. I briefly looked into what Java1.7 features this library uses and it appears to only use empty generic declarations (new HashMap<>()) and a few String switch statements.
Would you consider changing those to support Java1.6? I'd be happy to make the changes and submit a pull request if there is interest in this.
Comments (9)
-
-
reporter Yep, I just got there too. I have a branch with the one line change to the pom.xml. Would you consider merging it?
<target>1.6</target>
-
Yes, we'll consider merging it. The library is fairly stable now and I don't think we'll be needing classes from the new Java 7 API. Coding in 7 is a bit nicer, and we're now looking at 8 :) It's got such nice things as @NotNull annotations
-
reporter submitted pull request #14
-
Following the failed attempt to target 1.6, I would like to suggest forking the code and downgrading it to Java 1.6. I'm sorry, but we really don't want to downgrade the code to 1.6 in the master branch.
If you intend to maintain a 1.6 version of the library we'll put a note on the website in case other developers need that.
Thanks,
-
reporter Sure enough. I was using the eclipse compiler and m2e...it wasn't complaining about the source/target combination. I was able to reproduce by using mvn directly.
I was able to resolve by removing the
<source>1.7</source>
See pull request #15
-
reporter OK...lemme slow down and make sure I'm running
mvn clean
-
- changed status to resolved
Added support in release 3.3, should be on Maven Central later today.
-
I'm a bit confused here. What support was added to 3.3?
AFAICT the pom and the docs here still say it's "Java 7+" thanks.
Edit: I'd missed that jdk16 profile in the build.xml
So i cloned the repo 3.4-release (really you have to roll back one version so that it still says "3.4" rather than 3.5-SNAPSHOT). Then it can be built under jdk 7 (jdk6 is ok for building, but the javadoc creation fails) with
mvn install -P jdk16 -DskipTests
(The tests mostly pass but in my env i get Illegal key size Errors for 24-29 tests regardless of jdk. If there's some special crypto pack i'm supposed to install, i haven't).
$ javap -verbose -classpath target/nimbus-jose-jwt-3.4-jdk16.jar com.nimbusds.jose.Algorithm | grep major major version: 50
(there's a jar in there without the "-jdk16.jar" which is identical, but i'm using the jdk16 version for some visual distinction)
For my project i went with the approach of an "in project repository" basically like this (http://randomizedsort.blogspot.com/2011/10/configuring-maven-to-use-local-library.html)
Under cygwin with the build done in /c/java/nimbus-jose-jwt i went to my existing maven project directory and then did:
mkdir lib mvn install:install-file -Dfile=`cygpath -aw /c/java/nimbus-jose-jwt/target/nimbus-jose-jwt-3.4-jdk16.jar` -DpomFile=`cygpath -aw /c/java/nimbus-jose-jwt/pom.xml` -Dversion=3.4-jdk16 -DlocalRepositoryPath=`cygpath -aw lib`
To the pom.xml for the project i added
<repositories> <repository> <id>in-project</id> <name>In Project Repo</name> <releases> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>ignore</checksumPolicy> </releases> <url>file://${project.basedir}/lib</url> </repository> </repositories>
and in the dependencies section:
<dependency> <groupId>com.nimbusds</groupId> <artifactId>nimbus-jose-jwt</artifactId> <version>3.4-jdk16</version> </dependency>
The main thing about this that seems a little unclean is that i specify this "3.4-jdk16" version (and it works, at least on my machine w/ command line maven and with eclipse via "mvn eclipse:eclipse")) but the version in the ./lib/com/nimbusds/nimbus-jose-jwt/3.4-jdk16/nimbus-jose-jwt-3.4-jdk16.pom file (the renamed pom that gets installed in the project repo) still says it is version 3.4 internally. I don't know if this will cause problems.
If anyone has a cleaner way to achieve any/all of this i'd love to hear about it. (i'm not too well versed in maven version specifications / profiles etc)
- Log in to comment
We migrated to Java 1.7 after 1.6 reached its end of life.
If the API is still 1.6 compatible, and only the newer 1.7 syntax is made use of, wouldn't be more simple to instruct Maven to compile the library to 1.6 byte code?