-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move candidate io.jsonwebtoken.lang.* classes to the impl module #525
Comments
As a first pass, I wanted to see what the impact would be of moving the lang package into impl. After getting compile time errors due to usages within the api modules, I started moving things back. Turns out, most everything was needed just to get back to compiling properly: How about we make a |
Bummer. So the goal was to hide whatever we could from projects using JJWT that wasn't necessary in creating and parsing JWTs. If we have a That said, for 1.0, there are a lot of internal implementation details w.r.t. to making SignatureAlgorithm an interface (#493) that will result in us no longer needing many of the lang.* classes in the Along those same lines, the same is true of the Encoders and Decoders (Base64/Base64URL implementations) and probably a few others. Ideally, for 1.0, by the time we're done with everything related to api vs impl migration, the only things that should be in the |
This is probably going to be related to and impact #519 |
Due to old implementations (before JJWT was modularized), the
io.jsonwebtoken.lang
package in theapi
module contains a lot of classes and methods that aren't needed by JJWT users.For 1.0, as many of these classes and methods as possible should be moved to the
impl
module since they're almost exclusively used by JJWT implementation classes.Note that anything used by any of the extensions or in the
api
module itself would need to remain in theapi
module. But this number should be relatively minor.If this opens a can of worms, we can leave these classes alone, but per the open-closed principle, it'd be best to not expose anything that's not absolutely critical for using the
api
.Setting for the 1.0 milestone as semver dictates this can't be done without incrementing the major version number.
The text was updated successfully, but these errors were encountered: