Am 29.02.2016 um 14:00 schrieb Rémy Maucherat:
2016-02-28 14:09 GMT+01:00 Rainer Jung <rainer.j...@kippdata.de>:
I find it hard to judge between a) and b), because I don't know much about
the gap between only merging the connectors and merging anything but not
Servlet API. I think making HTTP/2 and also OpenSSL support in HTTPS
connectors available is important enough to warrant not waiting for the
final Servlet Spec / TC 9. The biggest other change I see is the removal of
BIO.
Concerning Java 7 vs. 8 it would be nice to allow the split as it was done
with web sockets in TC 7. But it is not critical. Java 7 public updates
ended 10 months ago. People who are not yet on TC 8 and who want or need to
stay on Java 7 can stick to TC 7.
People who need HTTP/2 should be prepared to use latest and greatest. For
them a switch to Java 8 should not really be a problem.
The problematic part is the people who just migrated to TC 8 during the
last 2 years and might still need to use Java 7 for some reasons. Those are
the ones that should guide the time we are willing to support 8 and 8.next
in parallel. So IMHO the time depends somewhat on the Java 7/8 result and
also the a)/b) decision (how compatible are 8 and 8.next) and also on the
timing (announcement of plan, first release of 8.next GA). 6 months is not
much for people who just moved to TC 8 if the update to 8.next involves
noticeable work on their side.
So the Java 7 issue could be resolved :) It's not really supported
anymore, but it's obvious that's the biggest concern for everyone.
The main other difference between a) and b) is that some items marked as
deprecated in 8 are removed in 9. I don't think it affects items that are
actually used a lot. Any problematic items can be restored easily if needed.
Personally, I think I prefer b) now, as a) would mean porting the
connectors with a lot of changes including behavior changes, and this could
have some compatibility issues that could be harder to detect.
Thanks for the explanation. Agreed.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
