Using Base64 instead of DatatypeConverter#318
Conversation
Replacing usages of `javax/xml/bind/DatatypeConverter` with ` java.util.Base64`
e555bff to
64f258a
Compare
| jdk: | ||
| - openjdk7 | ||
| - oraclejdk8 | ||
| - oraclejdk9 |
There was a problem hiding this comment.
Add oraclejdk10 and oraclejdk11 here would be good. We can allow failures for oraclejdk11 by adding the following configuration:
matrix:
allow_failures:
- jdk: oraclejdk11There was a problem hiding this comment.
I tried adding oraclejdk10 and oraclejdk11, but build failed on Travis when running tests against these JDKs with NPE (https://travis-ci.org/jwtk/jjwt/builds/398495426).
For now, I removed the above changes. If/when the current PR gets merged, we can issue a separate PR to add the oraclejdk10 and oraclejdk11 to Travis config
801ff37 to
64f258a
Compare
|
JDK 7 may be dropped in the 1.0 final release, but until then, I think we need to continue support for JDK 7. Based on this, are you willing to re-issue the PR and pull in the |
|
@lhazlewood I can do that. Thanks |
|
@azagniotov please disregard my previous comment - check out #333 for the latest on how we're trying to solve this. |
|
Closing in favor of #341. Thanks for your continued help and review on this @azagniotov ! |
This PR addresses issues #317 & #297 and #143 (points out a significant difference between the
DatatypeConverter&Base64)Replacing usages of
javax/xml/bind/DatatypeConverterwithjava.util.Base64Please note
This PR removes support for building the library against Java 7 as it leverages
java.util.Base64which was added in Java 8. I do not know what the maintainers ofjjwthave in mind in terms of sunsetting support for Java 7, so I am not sure if my PR is the right direction. If support for for Java 7 will be dropped, then the issue #308 will be addressed tooAs an alternative, the following PR #283 tries to solve this issue by adding a dependency on
jaxb-api, which brings inDatatypeConverterwithout dropping the Java 7 build support