graal support?

[janjangao]

I use jjwt generate token for my micronaut app，I use graalvm build native-image, when generate token, I get this error:

io.jsonwebtoken.lang.UnknownClassException: Unable to load class named [io.jsonwebtoken.impl.DefaultJwtBuilder] from the thread context, current, or system/application ClassLoaders. All heuristics have been exhausted. Class could not be found. Have you remembered to include the jjwt-impl.jar in your runtime classpath?

I already setting jjwt-impl.jar in build.gradle, but because of native-image has limitation with reflection, so dynamic class loading can not work, I follow the graal manual add reflection-config.json in META-INF and its working!

[ { "name" : "io.jsonwebtoken.impl.DefaultJwtBuilder", "allDeclaredFields" : true, "allPublicMethods" : true, "allDeclaredConstructors" : true } ]

so can we just put the graal config in jjwt-impl.jar to support graal native-image?

[lhazlewood]

We'd welcome a pull request for this, but it's low priority for the core JJWT team until 1.0 is released.

[stale]

This issue has been automatically marked as stale due to inactivity for 60 or more days. It will be closed in 7 days if no further activity occurs.

[MarkusKramer]

Only adding DefaultJwtBuilder will not be sufficient if you want to parse a JWT. I've got jjwt working in a Graal native image build now. Parsing a JWT can be done like this:

            DefaultJwtParserBuilder()
                .deserializeJsonWith(JacksonDeserializer())
                .build()
                .parse...

You'll also need some config files to get compression to work - which unfortunately you currently can't get rid of as it's always getting statically initialized even when not needed.

META-INF/native-image/someprojectname/resource-config.json

{
  "resources": {
    "includes": [
      {
        "pattern": "META-INF/services/io.jsonwebtoken.CompressionCodec"
      }
    ]
  }
}

META-INF/native-image/someprojectname/reflect-config.json

[
  {
    "name": "io.jsonwebtoken.impl.compression.GzipCompressionCodec",
    "methods": [
      {
        "name": "<init>",
        "parameterTypes": []
      }
    ]
  },
  {
    "name": "io.jsonwebtoken.impl.compression.DeflateCompressionCodec",
    "methods": [
      {
        "name": "<init>",
        "parameterTypes": []
      }
    ]
  }
]

These files could also be bundled with the jjwt artifact and then it would work more out of the box. Alternatively, it would be great if jjwt would use less dynamic classloading logic.

[lhazlewood]

Thanks for the update @MarkusKramer . Is it possible to declare DefaultJwtParserBuilder and DefaultJwtBuilder in resource-config.json as well, and then have it work 'out of the box' without having to use jjwt-impl in compile-scope?

Nothing in the impl module is guaranteed for backwards compatibility. If you directly use its classes as above, breaking changes could occur on future upgrades.

[MarkusKramer]

Yes, you can use Jwts.parserBuilder() if you add to reflect-config.json

  {
    "name": "io.jsonwebtoken.impl.DefaultJwtParserBuilder",
    "methods": [
      {
        "name": "<init>",
        "parameterTypes": []
      }
    ]
  },

Just tested with Graal. And similar for the builder and other classes.

When including theses configs in jjwt-impl it should work out of the box.
However... one key benefit of Graal is to get rid of unneeded code, and we're sort of preventing it this way. It would be better to have less reflection in jjwt, by Jwts doing normal class initialization that can be statically analyzed by tools. And DefaultJwtParserBuilder not initializing DefaultCompressionCodecResolver unless actually needed.

[lhazlewood]

A CompressionCodecResolver is always needed in case a zip header is encountered, but I understand your point around reflection.

We have discussed at times moving the impl package and its sub-packages into a single .jar and changing everything in there to package protected to prevent people from depending on those classes, but there needs to be some significant analysis to ensure nothing can 'leak' unexpectedly. It'll be a decent amount of work.

A reflect-config.json might be a better/faster stop-gap in the meantime however.

[stale]

This issue has been automatically marked as stale due to inactivity for 60 or more days. It will be closed in 7 days if no further activity occurs.

[lhazlewood]

Looks like significant work to support something like this will have to wait until after 1.0 - highest priority is to get JWE released.