-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Comments
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. |
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. |
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. |
Makes sense. :-) If someone (such as me!) submitted a merge request doing any of the above... would it be accepted? |
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.) |
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. |
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. |
Done! |
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.
The text was updated successfully, but these errors were encountered: