There is JIRA report already filed for this:
https://java.net/jira/browse/JERSEY-2646 <
https://java.net/jira/browse/JERSEY-2646>
It also refers to a detail explanation of the current approach:
https://java.net/projects/jersey/lists/users/archive/2014-09/message/2 <
https://java.net/projects/jersey/lists/users/archive/2014-09/message/2>
The above report was closed as invalid as it is not very likely that Jersey would switch back
to using the original Guava library. Although we could still consider a new feature, that
would allow Jersey code to optionally run against the original Guava classes, i do not think
such a feature would get implemented soon.
To solve your footprint issue you could actually use Jersey as is and switch to using the Jersey “provided” Guava
repackaged classes in your other code. This would only work if you do not rely upon 3rd party libraries depending on Guava.
If you do so, then you would need to repackage again.
Another option would be to file the new feature request as suggested above (optional com.google.guava support)
and consider contributing it to Jersey. It is not clear to me at the moment how to implement the feature.
The following options come to my mind at the moment, none of them seems as a great idea to me:
- introduce a new module, say jersey-guava-orig, that would contain classes statically delegating to the original guava code
(not sure you would want to maintain such a thing, maybe this could be generated)
- use some advanced byte-code manipulation technique to either update Jersey classes as they get loaded at runtime to rely on com.google.guava
or (re-)generate the original com.google..guava.* types on the fly from the repackaged versions
You would maybe come with someting better. All of the above seems ugly to me.
~Jakub
> On 06 Jan 2015, at 12:14, 张立鑫 <intelligentcodemail_at_gmail.com> wrote:
>
> yes,but i should import guava.a lot of double code, like asm guava
>
>
>
> 2015-01-06 18:06 GMT+08:00 Jakub Podlesak <jakub.podlesak_at_oracle.com <mailto:jakub.podlesak_at_oracle.com>>:
> The repackaged libraries should not be bigger than the original versions.
> Could you please explain a little bit more?
>
> Thanks,
>
> ~Jakub
>
>
> > On 24 Dec 2014, at 09:05, 张立鑫 <intelligentcodemail_at_gmail.com <mailto:intelligentcodemail_at_gmail.com>> wrote:
> >
> >
> > jersey deps library repackaged in jersey, but i need use maven and share library. now jersey too big size
>
>