Minimum Java Version

[strokine]

It looks like the minimum JDK version is 1.6

<jdk.version>1.6</jdk.version>

But GzipCompressionCodec instantiates GZIPOutputStream with signature which is available only in Java 7:
https://github.com/jwtk/jjwt/blob/master/src/main/java/io/jsonwebtoken/impl/compression/GzipCompressionCodec.java#L65

new GZIPOutputStream(outputStream, true):
Java 6:
https://docs.oracle.com/javase/6/docs/api/java/util/zip/GZIPOutputStream.html

Java 7:
https://docs.oracle.com/javase/7/docs/api/java/util/zip/GZIPOutputStream.html

I think we should upgrade the minimum JDK version to 7

[pglezen]

You're probably right. If it is imperative that you work with JDK 6, I know I used JJWT with Java 6 late last Spring. So an older version of JJWT might work for you.

[lhazlewood]

@strokine I haven't looked at the GZIPOutputStream API in a little while, but I'm assuming it is backwards compatible such that we can just use it in a way that is compliant with JDK 6. Has anyone checked yet? If so, we can keep JDK 6 compatibility.

That said, it is a bit odd today that JDK 6 be supported by (m)any current open source projects. @pglezen do you see a strong reason to continue to support 6?

[pglezen]

The shop in which I worked that was using JDK 6 last Spring has since upgraded to JDK 7. IMHO, you have to weigh the burden of maintaining JDK 6 support with the following factors:

• most places have moved on to JDK 7
• earlier builds of JJWT do successfully build and run with JDK 6

So if some shop is adamant about JDK 6 support, they can simply download an earlier build of JJWT. It may not have all the bells, whistles, and security patches of the latest JJWT. But I feel it is fair to shift that burden to the JDK 6 shops and free JJWT developers (like you) from JDK 6 constraints.

Disclaimer: My biased perspective is largely driven by my role supporting IBM WebSphere Application Server customers. Such customers have a painless route to migrate from JDK 6 to JDK 7 using the managesdk tool included with their WAS installation. (Painless for WAS, but not necessarily painless for 3rd-party libraries.) Each shop will have to evaluate their own situation.

[strokine]

I use Java 8, but I've submitted the issue, just because, I've checked out the project and mvn install gives a compilation error, because it uses java version set by jdk.version property. Once, I've flipped the version to 7, everything worked fine.

[beders]

Does anybody know what the latest version that ran on Java 6 was?

[lhazlewood]

The latest 0.7 should work on JDK6 if you compile it yourself with JDK6. Just don't use the GZipOutputStream (zip JWT header) and you should be fine.

[beders]

It's the jackson library that is ruining the fun (they started to go Java 7 with 2.7+)
Trying 0.6.0 now.

[lhazlewood]

You don't need to do that I don't think - you can add an <exclusion> to the 0.7 dependency to exclude the one JJWT imports and re-define that as your own dependency. But whatever works :)

[beders]

Thanks for the quick feedback.
I'll try that.

Compiling 0.6 or 0.5.1 on a Mac with the latest Java 6 just proclaims:
src/main/java/io/jsonwebtoken/impl/DefaultJwsHeader.java:[22,8] java.util.Map cannot be inherited with different arguments: <> and <java.lang.String,java.lang.Object>
IntelliJ doesn't complain at all. I just can't build this with maven using the Java 6 SDK.
The gods are against me! :)

[lhazlewood]

Ah, yeah, I guess I couldn't remember any language discrepancies. I didn't think there were any, but this shows otherwise!

[lhazlewood]

Closing since JDK 7 is used currently. JDK8 as a minimum will be resolved via #308