Skip to content
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

JwtParser to parse CharSequence instead of String? #328

Closed
zolyfarkas opened this issue Jun 13, 2018 · 6 comments · Fixed by #844
Closed

JwtParser to parse CharSequence instead of String? #328

zolyfarkas opened this issue Jun 13, 2018 · 6 comments · Fixed by #844
Assignees
Milestone

Comments

@zolyfarkas
Copy link

JwtParser parameters that get parsed are all String, can these be made to CharSequence? it would make this a bit more flexible...

@azagniotov
Copy link

azagniotov commented Jun 30, 2018

I am not sure I agree with having CharSequence type parameters in the public interfaces without a strong justification.

My main concern here is that implementations of CharSequence are not guaranteed to be immutable, while String is.

@lhazlewood
Copy link
Contributor

I don't understand the request exactly - can you show a code snippet example of what you're asking for?

@lhazlewood
Copy link
Contributor

Closing due to inactivity or follow up from OP.

@zolyfarkas
Copy link
Author

well somehow I missed the notifications for the followup questions... this awesome email spam filters in action...

the idea is when parsing from some source CharSequence is a bit more flexible... (String, StringBuilder ...)

for an example, in class Integer you have both:

public static int parseUnsignedInt(String s, int radix)

and:
public static int parseUnsignedInt(CharSequence s, int beginIndex, int endIndex, int radix)

in case on JWT, lets say the web token needs to be parsed out of a string like:

"Bearer [JWT token]"

I want tp avoid doing a substring() and allocate memory for no good reason.. having a CharSequence parsing variant I could simply do: parse(myString, "Bearer ".length(), myString.length())

The existing interfaces don't need to be changed....

@lhazlewood
Copy link
Contributor

Reopening, but I don't know when we'll get to it. This is low priority given the 1.0 feature set we need to support.

@lhazlewood lhazlewood reopened this Mar 24, 2019
@lhazlewood lhazlewood added this to the 1.0 milestone Mar 24, 2019
@lhazlewood
Copy link
Contributor

The IO Streams work commited via b687ca5 makes this much easier, so we can sneak it in for 0.12.0. I should have a PR shortly.

@lhazlewood lhazlewood modified the milestones: 1.0, 0.12.0 Sep 30, 2023
@lhazlewood lhazlewood self-assigned this Sep 30, 2023
lhazlewood added a commit that referenced this issue Sep 30, 2023
- Ensured Parser worked with CharSequence, InputStream and Reader, not just String
- Changed Deserializer#deserialize(InputStream) to deserialize(Reader)
- JwtParser now extends from Parser to support these additional methods.
lhazlewood added a commit that referenced this issue Sep 30, 2023
Closes #328

- Ensured Parser worked with CharSequence, InputStream and Reader, not just String
- Changed Deserializer#deserialize(InputStream) to deserialize(Reader) 
- JwtParser now extends from Parser to support these additional methods.
- Changed remaining JwtParser.parse* methods to accept CharSequence arguments instead of String args.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants