On 23 November 2015 at 09:46, Michael Osipov <[email protected]> wrote: >> On Mon, 2015-11-23 at 10:08 +0100, Michael Osipov wrote: >> > > On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore <[email protected]> wrote: >> > > >> > > > On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov <[email protected]> >> > > > wrote: >> > > > >> > > > > Am 2015-11-21 um 19:52 schrieb Gary Gregory: >> > > > > >> > > > >> +1. >> > > > >> >> > > > >> I would not mind using Java 8 too. >> > > > >> >> > > > > >> > > > > Believe that is too early. We are using a company-wide, Eclipse >> > > > > RCP-based >> > > > > product which is on Eclipse 3.4/3.6 and still HttpClient 3.x. I >> > > > > highly >> > > > > doubt that the dev team will jump on e4 and Java 8 features. >> > > > > Java 7 is a good base line. >> > > > >> > > >> > > By the time, HC5 comes out, Java 9 might be out ;-) >> > > >> > > I think it is time to move to Java 8, which might also attract fresh >> > > blood >> > > to the project. >> > >> > Gary, >> > >> > if you have seen those screencaps from Devoxx in Belgium you would know >> > that Java 9 brings >> > the most tremendous changes since the inception of Java (citing Mark >> > Reinhold). This is >> > too much changes for just one release. >> > >> > Moreover, I highly against moving to Java 8 right now becuase too many >> > people have constraints >> > to move to a new major Java version. Withhelding them from upgrade to 5.0 >> > just because of that >> > would create a chicken-end-egg problem. >> > >> > Given that this project has only few active developers, we should rather >> > focus on onther issues. >> > >> > For instance, at Maven there are probably working ten developers, yet we >> > have chosen to stick >> > to Java 7 for broad compat. >> > >> > Michael >> > >> >> Folks >> >> I think it was probably a little more than year ago that Gradle folks >> said they might have to consider forking HttpClient if we had moved to >> Java 6 too soon. HC is a low level library. We risk losing a substantial >> user base if we get too carried away with new Java features. > > That is exactly the type of issue I was referring to. > > JMeter is one of the most prominent users and still uses Java 6. I don't want > JMeter to live with 4.x forever. Given that JMeter gave me a lot of freedom, > I want to give a lot back. >
JMeter trunk now requires Java 7 (see https://bz.apache.org/bugzilla/show_bug.cgi?id=57981) This was done because Java 6 was lacking some functionality that we needed, e.g. in keytool Note that JMeter is very different from a low-level library such as HC. It should generally be run on its own host, so requiring a later version of Java is not usually a problem (so long as the release is generally available). However, we have not yet required the use of Java 8, because there is no pressing need to do so. Requiring Java 8 for HC may cause problems for some users of JMeter, but there is an easy workround - just run JMeter using Java 8. This is possible because JMeter is a stand-alone app. This is not however possible in general for other applications that depend on HC; the hosts on which they have to run may not be upgradeable yet. >> I loathe having to go back to Java 7 from Java 8 every time work on >> HttpClient. Really. But let's revisit this decision in a few month time. >> We might be forced to upgrade due to HTTP/2 TLS requirements. > > If so, we should consider providing this as a separate, pluggable module > compiled with Java 8 while > the rest can happily work with Java 7. +1 > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
