"fast-start" the delivery of gzip-compressed bodies, and support flushing of GZIPOutputStreams on JDK7+

[cemerick]

GZIPOutputStream.flush() is essentially a no-op under <= JDK6 given
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4813885. We weren't
calling it before anyway, but its JDK7 semantics are necessary when
compressing seq response bodies; otherwise, the middleware will require
complete consumption of the seq before a single byte hits the wire.
Without this change, gzipping of seq bodies that are truly lazy (e.g.
supporting server-sent events) is not practical; this patch therefore
also disables seq body support given pre-JDK7 GZIPOutputStream.flush()
functionality.

[amalloy]

Does defining this check at compile-time still work if this library ever gets AOTed? I remember some issues in clojure.core.reducers trying to auto-detect JDK7 in a similar way, and all it did was auto-detect what was present on the build machine. I'd be more comfortable defining this as a delay and then forcing it when needed, so it always runs on the client machine.

[cemerick]

Good points on both counts. I didn't even think of AOT. I'll update the PR shortly.

[cemerick]

Unless I'm having a dull moment, if the constructor choice is put into a macro, then AOT will again fix the choice to whatever suits the build environment, not the runtime environment. Does it really matter if a bum, unused ctor form is compiled under <=JDK6?

[amalloy]

Yeah, I think you're right: it's not possible to fix both of my
objections at the same time. It would be nice to do this in a macro
anyway; it won't fix the AOT issue, but it would emit useless code less
often. Still, I don't mind taking the PR as-is if you think that's not
worth the effort.

On 09/12/2013 05:26 PM, Chas Emerick wrote:

Unless I'm having a dull moment, if the constructor choice is put into
a macro, then AOT will again fix the choice to whatever suits the
build environment, not the runtime environment. Does it really matter
if a bum, unused ctor form is compiled under <=JDK6?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[cemerick]

Well, as-is doesn't make much sense, as then neither problem is addressed.

I personally think the AOT problem is more significant; that could actively prevent some people from using the library if they have a peculiar build/deployment setup. The ctor thing is just a dead code path, fundamentally benign.

I'll fix whichever one you like. it's your library. :-)

[amalloy]

Yeah, you're right. Leave the dead code, but fix the AOT problem by
making the def thing into a delay. Thanks!

On 09/13/2013 12:11 PM, Chas Emerick wrote:

Well, as-is doesn't make much sense, as then neither problem is addressed.

I personally think the AOT problem is more significant; that could
actively prevent some people from using the library if they have a
peculiar build/deployment setup. The ctor thing is just a dead code
path, fundamentally benign.

I'll fix whichever one you like. it's your library. :-)

—
Reply to this email directly or view it on GitHub
#3 (comment).

[cemerick]

Bumping before I forget… :-)

[amalloy]

Huh. Github didn't email me when you added that commit. I'll merge and release a new version in a sec.