eclipse-ee4j / eclipse-ee4j/jersey

[question] UriComponent URI decoding implementation

Open
#3,903 0 comments 0 reactions 0 assignees View on GitHub
performance
Dominant language
Java
Stars
730
Forks
382
PR merge metrics
No merged PRs in 30d

Description

I'm currently using Jersey's [`UriComponent`](https://github.com/eclipse-ee4j/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/uri/UriComponent.java) class for encoding and decoding request and response URIs, and I'm running into performance issues when decoding URIs with long query params.

It seems that in the implementation of [`UriComponent#decodeQueryParam`](https://github.com/eclipse-ee4j/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/uri/UriComponent.java#L565), you're making a call to `java.net.URLDecoder` for each individual key and value. After profiling and benchmarking repeated decodings using this method, it seems that not only does this library method call take up most of the CPU time, but it's also slower than other equivalent libraries, such as Apache commons and Spring web, for instance.

Also, I noticed that you already have your own manual implementations of `encode` and `decode` to percent-escape and percent-unescape URI strings. According to some online blog posts and forum discussions, it seems that manual implementations are potentially much faster than `java.net.URLDecoder`, which apparently has some inefficiencies in its implementation ([one example source](http://javarunner.blogspot.com/2007/06/urlencoderurldecoder-way-too-slow.html)).

_So my question is:_ why are you using this library when you already have your own decoder implementation that you could easily use for the raw query param keys and values? Is there a specific implementation/spec reason or requirement that I'm missing, or can your manual implementation be used instead?

As a side note, it may be worth it to look into the aforementioned Apache and Spring libraries, as well. I benchmarked your implementation using these libraries and they seemed to run faster than the `java.net` library.

Thanks

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.