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

Make OkHttp work on Java < 7 #18

Closed
candrews opened this issue Sep 5, 2012 · 8 comments
Closed

Make OkHttp work on Java < 7 #18

candrews opened this issue Sep 5, 2012 · 8 comments

Comments

@candrews
Copy link
Contributor

candrews commented Sep 5, 2012

It appears that due to the dependency on DeflaterOutputStream(OutputStream out, boolean syncFlush), OkHttp must be compiled on Java 7 and will only run on Java 7 or Android.

Ideally: could okhttp use the syncFlush DeflaterOutputStream constructor if it's available, but if it's not, use some other means (perhaps jzlib) of accomplishing the same goals?

Less than ideally: use reflection as described by @swankjesse at https://code.google.com/p/android/issues/detail?id=14297#c2 so that the library can at least be compiled on Java < 7. This will also at least allow the use of animal-sniffer so that automated checks can be done at package time to ensure that only Java 5 APIs are used, raising confidence that the library will work at runtime.

@swankjesse
Copy link
Member

Aside from slight build inconvenience, is there any strong reason to support Java 6 or Java 5 ? As I understand it it's pretty easy to get a Java 7 VM for any Java platform that'll be running OkHttp.

@candrews
Copy link
Contributor Author

candrews commented Sep 5, 2012

I was thinking that there are many users (home and corporate) who are still on Java 6. At work, I've found that many companies are still on Java 5. So if okhttp works on those JVMs, it has a larger potential user base.

@swankjesse
Copy link
Member

I'm not interested in home users; Java on the desktop has been dead for a long time. Corporate users should be using Java 7 anyway; that's the only way to run Java securely. I'd prefer to worry about Java 5 and 6 only after we've fully conquered Java 7.

@candrews
Copy link
Contributor Author

candrews commented Sep 5, 2012

Makes sense. :-)

If someone (such as me!) submitted a merge request doing any of the above... would it be accepted?

@swankjesse
Copy link
Member

I don't want to depend on jzlib. Writing code to forbid SPDY on Java 5 and 6 would be okay, though I'm not yet in a point where I'm ready to merge pull requests. (The project still needs to be synced with upstream Android.)

@candrews
Copy link
Contributor Author

candrews commented Sep 5, 2012

Noted. I'll hold my contributions.

Also, Java < 7 compatibility would help application server users... those tend to still run on Java 6 it seems.

@swankjesse
Copy link
Member

Java 7 has been out for over a year. It's a free download and it fixes bugs and security holes in Java 6. If you want to live in the beautiful, cutting edge future with OkHttp, you need to use Java 7.

@swankjesse
Copy link
Member

Done!

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

No branches or pull requests

2 participants