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

Base64 encoding provider #47

Open
roytmana opened this issue Aug 2, 2016 · 3 comments
Open

Base64 encoding provider #47

roytmana opened this issue Aug 2, 2016 · 3 comments

Comments

@roytmana
Copy link

roytmana commented Aug 2, 2016

Hi @wstrange
It could be a bit far fetched but I am trying to reduce dependencies. since JDK8 has built in Base64 and many server environments also have some Base64 utilities does it make sense to make this dependency optional and allow configuring Authenticator with an implementation of your internal Base64 interface.
This way with httputils made optional your library will be a little sweet no dependencies library. otherwise bringing it int server environment may cause jar conflicts

@emcrisostomo
Copy link
Collaborator

Hi @roytmana,

This library still targets Java 7 and the main reason I'm doing so is because I see a lot of people still using it, especially on enterprise applications. Dropping Java 7 is certainly possible, but I'm not sure the pros (removing a 278K dependency with no transitive dependency) outweighs the cons: either dropping Java SE 7 (no authoritative statistics, but quick Google search suggest > 40% of the Java user base is running 7) or implementing an internal service interface to plug a Base64 codec.

@emcrisostomo
Copy link
Collaborator

Actually, I'm leaving this open and tagged for a future Java 8 update.

@emcrisostomo emcrisostomo reopened this Aug 3, 2016
@emcrisostomo emcrisostomo added this to the Update to Java 8 milestone Aug 3, 2016
@roytmana
Copy link
Author

roytmana commented Aug 3, 2016

Hi @emcrisostomo,

I do not really propose to drop jdk7 support but rather a pluggable provider for encoding so I can implement an alternative (JDK8 based or tomcat libraries based) provider and avoid importing the library.
It is not about the size of course but about avoiding a single purpose library like yours bringing in dependencies that may conflict with the main application dependencies. This library is pretty stable and small so I can live with it :-)

Thank you,
Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants